From dave at dtrt.org Sat Oct 21 08:58:32 2023 From: dave at dtrt.org (David A. Harding) Date: Fri, 20 Oct 2023 22:58:32 -1000 Subject: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely In-Reply-To: References: Message-ID: On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote: > The basic problem here is after the HTLC-timeout path becomes > spendable, the > HTLC-preimage path remains spendable. That's bad, because in this case > we want > spending the HTLC-preimage - if possible - to have an urgency attached > to it to > ensure that it happens before the previous HTLC-timeout is mined. > > So, why can't we make the HTLC-preimage path expire? If the goal is to ensure the HTLC-preimage should be mined before an upstream HTLC-timeout becomes mineable, then I don't think a consensus change is required. We can just make the HTLC-preimage claimable by anyone some time after the HTLC-timeout becomes mineable. For example, imagine that Alice offers Bob an HTLC with a timeout at block t+200. Bob offers Carol an HTLC with a timeout at block t+100. The Bob-Carol HTLC script looks like this: If # Does someone have the preimage? Hash EqualVerify If # Carol has the preimage at any time CheckSig Else # Anyone else has the preimage after t+150 CLTV EndIf Else # Bob is allowed a refund after t+100 CheckSigVerify CLTV EndIf In English: - At any time, Carol can spend the output by releasing the preimage - After t+100, Bob can spend the output - After t+150, anyone with the preimage can spend the output Let's consider this in the wider context of the forwarded payment Alice->Bob->Carol: - If Carol attempts to spend the output by releasing the preimage but pays too low of a feerate to get it confirmed by block t+100, Bob can spend the output in block t+101. He then has 99 blocks to settle (revoke) the Alice-Bob HTLC offchain. - If Carol releases the preimage to the network in general but prevents Bob from using it (e.g. using a replacement cycling attack), anyone who saw the preimage can take Carol's output at t+150 and, by doing so, will put the preimage in the block chain where Bob will learn about it. He'll then have 49 blocks to settle (revoke) the Alice-Bob HTLC offchain. - (All the normal cases when the HTLC is settled offchain, or where onchain operations occur in a timely manner) I think that adequately satisfies the concern about the effect on LN from replacement cycling. Looking at potential complications: - If all miners acted together[1], they are incentivized to not mine Carol's preimage transaction before t+150 because its fees are less than the HTLC value they can receive at t+150. I think this level of miner centralization would result in a general failure for LN given that miners could be any LN user's counterparty (or bribed by a user's counterparty). E.g., stuff like this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017997.html - To allow anyone with the preimage to spend the output after t+150, they need to know the script. For taproot, that means the t+150 tapleaf script needs to follow a standard (e.g. a BOLT) and that any internal merkle nodes needed to connect it to the taproot commitment need to be shown in Carol's preimage transaction (or inferable from it or other data). - Classic RBF pinning of the t+150 transaction to prevent it from confirming by block t+200 might be an issue. E.g., including it in a 400,000 weight low-feerate transaction. - Full RBF might be required to ensure the t+150 transaction isn't sent with a low feerate and no opt-in signal. Deployment considerations: - No changes are required to full nodes (no consensus change required) - No changes are required to mining Bitcoin nodes[2] - At least one well-connected Bitcoin relay node will need to be updated to store preimages and related data, and to send the preimage claim transactions. Data only needs to be kept for a rolling window of a few thousand blocks for the LN case, bounding storage requirements. No changes are required to other relaying Bitcoin nodes - LN nodes will need to update to new HTLC scripts, but this should be doable without closing/re-opening channels. Both anchor and non-anchor channels can continue to be used Compared to OP_EXPIRE: - OP_EXPIRE requires consensus and policy changes; this does not - OP_EXPIRE does not depend on special software; this depends on at least one person running special software Although this proposal is an alternative to Peter's proposal and is primarily inspired by his idea, it's also a variation on a previous suggestion of mine: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html -Dave [1] Perhaps under block censorship threat from a mining majority or a sub-majority performing selfish mining. [2] Although miners may want to consider running code that allows them to rewrite any malleable transactions to pay themselve