pull down to refresh
That’s different because it introduces a new party to the validation process who is outside of the network.
I’m not anything like an expert on code improvements but when an upgrade includes things designed to remove vulnerabilities aren’t those reductions in what someone can do with bitcoin?
I will also admit to not being an expert on code improvements, but as far as I have learned, rule changes designed to address vulnerabilities (or upgrades in general) have never targeted things that were commonly being done with bitcoin transactions.
In the case of the inflation bug in 2010, someone clearly expected to be able to create more bitcoin than 21 million. The soft fork that changed this certainly was a reduction in what that person thought they could do with bitcoin.
However, I don't think such a case is very much like the case we are dealing with now regarding spam.
In general, I suspect (without much real evidence, I'll admit) that vulnerability fixes in Bitcoin have usually confined themselves to altering code to return to expected behavior.
This, I believe, is where BIP 110 proponents would say spam is not part of the expected behavior of bitcoin. I agree with this. However, I don't think spam is going to be pinned down to any one kind of transaction. And I think the transaction types they want to prevent are part of expected behavior.
Bitcoin has many kinds of transactions. How are we supposed to decide when one kind of transaction is being abused enough to warrant stopping everyone from using Bitcoin in that way?
That’s different because it introduces a new party to the validation process who is outside of the network.
As far as I can tell, introducing a new party to the validation process that is outside the network is exactly the plan: "spam" will be determined by some third party called "the community" or which only includes people who are "not spammers" and who are "good bitcoiners" -- all of which is entirely subjective.
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?
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.
This is how I think about it:
Everyone agreed that a certain set of transaction types could be included in a valid block.
One group of people has decided they don't like the transactions a different group is using, and are advocating a change to what can go in a valid block so that such transactions can no longer be included in a block.
My understanding of most changes to block validation rules is that they have been designed not to remove previous ways of transacting. BIP 110 is a significant departure from this philosophy in that it's only purpose is to remove previous ways of transacting.
How would this process look different if it was a government entity pushing for a rule change that made blocks with txs containing OFAC-banned addresses invalid?