pull down to refresh
I would argue that the mechanism being introduced is this soft-fork-to-stop-spam pattern. It puts the decision of which transactions should be valid up to frequent and recurring debate.
I believe it is encapsulated in this exchange:
When BIP 110 expires, what do its advocates expect to happen? From my conversations with them, it seems that they expect either 1) another soft fork or 2) another soft fork.
In the case of 1) where they manage to get most bitcoiners and miners on board, they need another fork to make it all permanent, and then more forks when spammers embed data in new ways. In the case of 2) where they do not get support, they seem interested in trying again and floating a different fork to "fix the spam."
While this is not a mechanism in bitcoin's block validation rules that allows anyone to veto transactions, it creates a system where Bitcoiners must decide which transactions are "spammy" and to be stopped from happening and which ones are "real." Already, BIP 110 is setting up two such occasions in as many years (deciding whether to run BIP 110, and then deciding whether to run whatever comes next when it expires).
I’m not interested in defending this particular approach.
Would you feel differently if it was just a straightforward permanent reduction in arbitrary data storage?
No. Because I don't see how we can have a "permanent" reduction in arbitrary data storage. People will just figure out other hacky ways to embed arbitrary data. So I don't see the point in chasing. I think the block size limit and the fee market are adequate to address this problem.
What if someone proposed expanding arbitrary data limits?
Do you mean expand the block size limit? I don't think I'd run that.
Is that the only bound on data storage? I thought some fields had maximum values.
If that last part is accurate then we are talking about more than just a change to one of the parameters.
Is this introducing a mechanism that allows a particular third party to veto transactions?