<p>Yes, that could happen. However it is also possible to inspect the blockchain for such outputs, and none exist that weren't known to be for testing.</p>

CC BY-SA 4.0
2024-02-13T17:15:26.060Z
Looks like there might have been a handful, but were these all known at the time? https://bitcoin.stackexchange.com/questions/115803/did-the-p2sh-bip-0016-make-some-bitcoin-unspendable
yonson
CC BY-SA 4.0
2024-02-13T05:03:14.940Z
2024-02-13T05:03:14.940Z
Ava Chow
<p>I think this question is effectively asking what happens if you try to pre-empt future soft fork rules and broadcast a transaction which can only be spent after a future soft fork lays out the rules for spending that output(s). Today such an output would be anyone-can-spend on broadcasting so it would be the complete opposite of being locked up forever. But at the time of the P2SH soft fork (2012) it would have been locked up forever unless the transaction constructor was able to perfectly pre-empt the future rules for spending the output. Any slight mistake when attempting to pre-empt those future rules could have resulted in them being locked up forever so it wouldn't have been advisable to try this.</p>

CC BY-SA 4.0
2024-02-13T17:22:03.787Z
I was thinking the opposite, where a user creates a script which is unintentionally restricted by a future softfork.
yonson
CC BY-SA 4.0
2024-02-13T13:10:30.960Z
2024-02-13T13:10:30.960Z
Michael Folkson
<p>The basic script for a lightning network HTLC output has a conditional branch which requires a user to know a preimage of a hash. It also requires the user to give a valid signature, but it got me thinking, what if before P2SH was a thing (back in the day) a user created a locking script which just so happens to match the P2SH template? For whatever reason, the user only intended to lock the bitcoin with a &quot;spender must know the preimage of this hash&quot; requirement. But this preimage is not a bitcoin script itself, so can't be executed even though it matches the P2SH template. Do P2SH-knowing nodes lock this bitcoin forever?</p>

<p2sh><soft-fork><output-script><preimage>
What if someone locks some bitcoin with a script which only requires a user to know a preimage, but it matches the p2sh template?
yonson
# What if someone locks some bitcoin with a script which only requires a user to know a preimage, but it matches the p2sh template?

(Asked by: username_0 on 2024-02-13)

The basic script for a lightning network HTLC output has a conditional branch which requires a user to know a preimage of a hash. It also requires the user to give a valid signature, but it got me thinking, what if before P2SH was a thing (back in the day) a user created a locking script which just so happens to match the P2SH template? For whatever reason, the user only intended to lock the bitcoin with a "spender must know the preimage of this hash" requirement. But this preimage is not a bitcoin script itself, so can't be executed even though it matches the P2SH template. Do P2SH-knowing nodes lock this bitcoin forever?

**Tags:** p2sh, soft-fork, output-script, preimage


---

## 2 answers

### Answer by username_1 on 2024-02-13. Score: 1

Yes, that could happen. However it is also possible to inspect the blockchain for such outputs, and none exist that weren't known to be for testing.

> **Comments:**
> **username_0**: Looks like there might have been a handful, but were these all known at the time? https://bitcoin.stackexchange.com/questions/115803/did-the-p2sh-bip-0016-make-some-bitcoin-unspendable  

---

### Answer by username_2 on 2024-02-13. Score: 0

I think this question is effectively asking what happens if you try to pre-empt future soft fork rules and broadcast a transaction which can only be spent after a future soft fork lays out the rules for spending that output(s). Today such an output would be anyone-can-spend on broadcasting so it would be the complete opposite of being locked up forever. But at the time of the P2SH soft fork (2012) it would have been locked up forever unless the transaction constructor was able to perfectly pre-empt the future rules for spending the output. Any slight mistake when attempting to pre-empt those future rules could have resulted in them being locked up forever so it wouldn't have been advisable to try this.

> **Comments:**
> **username_0**: I was thinking the opposite, where a user creates a script which is unintentionally restricted by a future softfork.  

---

