Inverse CLTV: only spendable up to block X
2144 sats \ 3 comments \ @C_Otto 31 Dec 2023 bitcoin
Do you know of any discussion regarding the following opcode? I believe this could be helpful when dealing with timeouts happening in the lightning network, potentially saving onchain fees and/or avoiding onchain transactions.
With CLTV you can specify "this output is only spendable after block X", and I'd like to having something along the lines of "this output can only be spent before block X".
I already see issues with chain reorgs, as transactions cannot be copied over to a longer chain. It also makes template construction more complex (validation steps have to be repeated?).
write
preview
related posts
0 sats \ 2 replies \ @C_Otto OP 31 Dec 2023
OP_BEFOREBLOCKVERIFY https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html
reply
10 sats \ 1 reply \ @C_Otto OP 31 Dec 2023
Alright, the chain reorg argument is much stronger than I thought. It's important for transactions to remain valid once they were valid, otherwise dependent transactions possibly created by other people (who are not aware of the limitation) might get removed retroactively. Furthermore, being able to do chain reorgs without huge complications helps Bitcoin's resilience against network splits, censoring attempts, etc.
reply
1599 sats \ 0 replies \ @petertodd 31 Dec 2023
I recently proposed this opcode as OP_Expire for use in lightning channels: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022042.html
While reorgs are a concern, that problem can be easily avoided by making the outputs of expiration-using transactions unspendable for a period of time. Similar to how you can't spend coinbase outputs in blocks immediately.
reply