But that was a bug in the software arithmetic, not intended behavior. I'm not saying you can't make this argument, it's not nothing, but it's very weak. It wasn't changing bitcoin's rules, only changing the software to actually enforce those rules. Destroying coins does change those rules, even if the original ruleset didn't anticipate a new context in which the effects of the rules get altered.
If there was a way to move private keys from pre-Q to post-Q (as there might be for BIP32) for these coins, then we wouldn't have an argument, because then you would preserve the intended rules through the context change. But that's not logically possible, and even worse the context change is not perfectly unambiguous; it would have to be, in that hypothetical.
Replies (3)
Thus it's a fascinating conundrum.
The rules are ultimately what people want them to be.
The flip side of "you can't confiscate coins" is "anyone can choose to reject coins with certain characteristics."
There are countless cases of protocols upgrading their security over time and users of those protocols rejecting interactions with other users who refused to upgrade their security.
That's not a conundrum at all. Permissionlessness dictates that both are true: you can't force anyone to use their coins in a particular way, and it also dictates you can't *stop* people using their coins in a particular way.
Forced upgrades to security are a valid way of doing this if users don't have an expectation of autonomy. Bitcoin users do, and must, have that expectation.
No auto-updates.
Also, rational economic interest dictates against your proposal, because it destroys bitcoin's value.
The voluntary nature of the protocol also dictates that anyone can choose to reject transactions with characteristics they deem dangerous / insecure.
I think you'll find your final claim to be controversial because some see it as value destruction while some see it as value preservation.
