Stealing people's coins is a red line
I find myself in a surprising position: I agree with @nvk. Here's what he posted on X:
UTXOs are sacred. We don't fork to steal them. We don't fork to expire them. We don't fork cancel them.This is the slippery slope.This is the hill worth dying on.
I strongly agree with this statement. It's something that I've argued as evidence that things like BIP 110 and The Cat are not serious proposal.
Surely @supertestnet is not going to come along and tell me that there is a soft fork that I am actively enforcing with my node which confiscated utxos...
Did BIP 16 makes some coins unspendable?
Super recently posted about this Stack Exchange question on X:
The BIP turned a particular "hashlock" locking script pattern (OP_HASH160 OP_DATA_20 20-byte-value OP_EQUAL) into a "magical" bytecode pattern which, after authenticating an input's top stack element against the hash then also executes it using Script VM.The BIP references 1 historical transaction that spent from an output that matched the pattern:These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) [1]. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. [2]. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).which made me wonder - are there other, unspent, historical hashlock outputs which may have been made unspendable (if they weren't already) by introduction of the P2SH feature?
The answer to this question is provided by the same person who asked it:
Even before BIP-0016 activation, there were some outputs that matched the P2SH pattern. Only one of them was spent before activation, and the rest have likely been made unspendable by the BIP-0016 upgrade since spending them would have to satisfy consensus rules not enforced when they were created. Total amount locked in those outputs was 0.044 BTC.
And they also provide a handy table of the utxos they believe were made unspendable by BIP 16.
Table 1: Outputs matching the locking script pattern OP_HASH160 OP_DATA_20 value_20 OP_EQUAL, extracted from blocks 0 to 173805.
| Block Height | TXID | Output Index | Satoshi Amounts | Locking Script | Status |
|---|---|---|---|---|---|
| 170052 | 9C08A4D78931342B37FD5F72900FB9983087E6F46C4A097D8A1F52C74E28EAF6 | 1 | 400000 | a91419a7d869032368fd1f1e26e5e73a4ad0e474960e87 | Spent |
| 170054 | B0539A45DE13B3E0403909B8BD1A555B8CBE45FD4E3F3FDA76F3A5F52835C29D | 1 | 400000 | a914e8c300c87986efa84c37c0519929019ef86eb5b487 | Unspent |
| 170434 | D0636198EA55FADEE5B4CCC07C85012DB7D07C2D25790B3AEC770C86617801C0 | 1 | 1000000 | a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87 | Unspent |
| 170442 | 9AB59E2D4BE16C470160EB9B9A9D9799EAF29AF0461AEA131E748659D806FA1A | 0 | 1000000 | a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87 | Unspent |
| 170442 | 658FC92061F1C4125D5CD1034EB8A1F09BFEBD32A988D855EB7EE63689759A21 | 0 | 1000000 | a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87 | Unspent |
| 170556 | 510B5A44935109E249A704C2900AA9D8303166062E81D2AC852C965B6266DCEE | 0 | 1000000 | a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87 | Unspent |
Super also found another Stack Exchange question about when the first BIP 16 spend occurred and which was answered by the same user:
Before P2SH activation, they could be spent as just hashlock contracts. After P2SH activation, they could only be spent if the hash preimage also happened to be a redeem script that would pass execution.The TXO created in block 170052 was actually spent in block 170060 as hashlock, not P2SH, because P2SH rules weren't active at the time.
If all of this feels too confusing, just think about it
So was it a mistake or was it intentional?
Ever-helpful, Super comes to the conclusion that freezing these five utxos (one utxo was specifically exempted) was indeed intentional.
Super found a note in Bitcoin Core that says:
// BIP16 didn't become active until Apr 1 2012 (on mainnet, and
// retroactively applied to testnet)
// However, only one historical block violated the P2SH rules (on both
// mainnet and testnet).
// Similarly, only one historical block violated the TAPROOT rules on
// mainnet.
// For simplicity, always leave P2SH+WITNESS+TAPROOT on except for the two
// violating blocks.
Intention doesn't even matter: if you run anything greater than Core v 0.6.0, you are actively preventing five utxos from being spent
Super argues that it is inconsistent to be against confiscation in one case but to be totally fine for it in another case.
For those wondering how this relates to the spam debate, some people on the Core side like to say they oppose any attempts to disable the utxos of spammers because confiscation is unconscionable. But their node is actively keeping old utxos unspendable too
He also says:
If the best counter you've got is "it happened 13 years ago and there's a chance it was by accident" then I'll remind you that the confiscatory rule is still in your node right now. You can eliminate it if confiscation violates your principles. You can't claim ignorance.
The nuances
Vojtěch Strnad (who also edited the original Stack Exchange question) replied to Super with some nuance about these five utxos:
There is a major difference, the outputs made unspendable by P2SH were anyone-can-spend before (i.e. weren't secured by a signature) and so had no ownership guarantees to begin with. Also we're talking about 0.044 BTC at 2012 prices, less than a single dollar.
I suspect it does not much matter whether the intent of the original PR was to confiscate those five utxos or not. I do, however, recognize that there may be a difference along the lines Vojtěch describes: freezing nyone can spend outputs may be less problematic than freezing outputs secured by private keys. But Super's point is pretty strong: there are five utxos that are actively considered unspendable by everyone running the post segwit Bitcoin code.
This makes it difficult for people like nvk and me to say "UTXOs are sacred, they are a red line." If that is true, why aren't we making a fuss about the utxos that were frozen by BIP 16?
Super makes a good point here:
If you think it's okay to maintain that confiscatory rule to avoid bad consequences, maybe show a little grace toward those who want to add a new confiscatory rule to eliminate different bad consequences.
I still do not feel that confiscating people's utxos should be treated lightly or accepted as a reasonable course in changes to block validation rules; however, I can't deny that I run a node that has confiscated 5 utxos worth .044 BTC.
IsSuperMajority()for MASF was done for BIP-30 (0.7) and everything before that wasn't really decentrally "activated". I think that this is when Gavin first proposed code for it, but maybe I've missed something. This was the "novel" mechanism when I started looking deeper into Bitcoin code.