Replies (2)

ive been running Core with pull request 28408 (match more datacarrying) for well over a year. before the discussion for the PR was closed, at taiwan bitdevs we applied this patch together as a way to show our attendees how datacarrier works (or more like why it was broken). some users even continue to use that version of Core in their nodes, even applying the patch up through v28/29. the users understand how arbitrary data still show up on blocks and still go through the process om their own. the patch itself works just fine, i dont see why datacarrier should be removed if it is working properly. i followed the recent mailing list discussion and i dont have any strong opinions on the implementations that choose to bypass existing restrictions. doesnt matter that much to me, but the PR you submitted removes a functionality node operators use and im a bit lost as to why. i dont buy that removing restrictions will reduce utxo bloat, intuitively it makes me think the situation would be made worse i dont have a random fancy whitepaper to kick off discussion like the ML, i can only ask whats wrong with fixing it <datacarrier>? on a positive note, at least theres acknowledgement that datacarrier is dysfunctional. best of luck with your endeavors to remove it, id even prefer that result compared to doing absolutely nothing.
sedited's avatar
sedited 8 months ago
The problem with the patch from the perspective of disallowing data embedding is that for it to be effective an overwhelming majority of nodes would have to upgrade to this patch. In the time where most nodes are not upgraded yet, the network will perform in a degraded manner, but data carrying transactions will still be relayed. If most nodes eventually upgrade, it is easy for the spammer to come up with a new script variation that is not covered by the current filter, which starts the entire game again. At the moment nodes upgrade very slowly. It usually takes years before a big majority of nodes upgrade to the newest version. You could argue that this is fine, and people will just be encouraged to update faster, but then you enter dangerous "auto-updating" teritory, which is against the core tenets of our project.