image
Luke Dashjr's avatar Luke Dashjr
Don't let the bad actors trick you into thinking Bitcoin Core 30 allows you to re-enable the datacarrier limit: 1) Along with unlimiting the default, they also broke it further. datacarriersize=83 now (as of Core 30) allows for 83 outputs totalling 830 bytes of spam, instead of just 92 bytes of spam (9 bytes of which couldn't be arbitrary) as in Core 29 and earlier. 2) datacarriersize is marked as deprecated, and explicitly planned to be removed in a future release (likely silently, since "it's already deprecated"). 3) Core never fixed the Inscription exploits (CVE-2023-50428 and CVE-2024-34149) which allow spammers to bypass the datacarriersize limit. The only way forward now is a mass migration to Knots. Not the way I wanted things to go, but Core has given us no other choice. Once this is resolved, we should avoid putting all our eggs in one basket, and encourage the creation and use of multiple clients.
View quoted note →

Replies (6)

21seasons's avatar
21seasons 6 months ago
Because we have been filtering, idiots are now making things worse by stuffing data in unspendable taproot outputs (which we have to store on our UTXO sets INDEFINITELY!). If we remove the filter, there might be a change that these actors would stuff their shit on OP_RETURN which can be pruned and we wouldn't need to store their shit forever. That's definitely an improvement. Also this would reduce miner centralization which is improvement as well πŸ‘
↑