Thread

Perhaps whoever posted that should be corrected, then. Also noteworthy: there are transactions from before bip16 with outputs that match the bip16 template, like this one:

The Mempool Open Source Project®

Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.

And some of them were spent, including that one:

The Mempool Open Source Project®

Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.

Per BIP16, I think they should be treated as simple hashlocks, i.e. if they have a redeemscript, it should not be evaluated, as bip16 wasn't active yet. But block explorers like mempoolspace display these txs as if they are P2SH spends, i.e. they DO evaluate their redeemscript. (See screenshot.) I suspect that's a bug.

I looked into it further, and it looks like the codebase actually does confiscate those outputs. For the sale of "simplicity," it applies the p2sh rules to all transactions in all blocks (including pre-P2SH blocks) except ones occurring in one specific block that they made a single exception for. Thus, the other exceptional outputs are now unspendable. Source:

GitHub

bitcoin/src/validation.cpp at 13891a8a685d255cb13dd5018e3d5ccc18b07c34 · bitcoin/bitcoin

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

Interesting, I think you're right, but it goes against the BIP16 definition. So, it seems bip16 is NON confiscatory but the code implementation IS. But I wasn't always like that, it seems Gavin started with a timestamp:

GitHub

Remove -bip16 and -paytoscripthashtime command-line arguments · bitcoin/bitcoin@8f188ec

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

But that variable (nBIP16SwitchTime) is now gone from the code. Interesting, I would like to have the time to investigate this further.

Even bip16 seems to create a confiscation deadline. It says all txs created after the deadline should have the new rules applied to them. So the ~5 people who previously used hash160 hashlocks would have to move those utxos before the deadline or else their outputs would become unspendable. Which is exactly what happened; one such output was already moved, the rest did not move and became unspendable.

Seems like it sets a precedent for setting confiscation deadlines in new bips