From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D5B79C0032 for ; Sat, 21 Oct 2023 09:08:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B1C5B60B16 for ; Sat, 21 Oct 2023 09:08:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B1C5B60B16 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RTnm7otBPLg for ; Sat, 21 Oct 2023 09:08:17 +0000 (UTC) Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [IPv6:2607:fe70:0:3::d]) by smtp3.osuosl.org (Postfix) with ESMTPS id AC7A661360 for ; Sat, 21 Oct 2023 09:08:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org AC7A661360 Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id D6CA32801D10; Sat, 21 Oct 2023 01:58:32 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Sat, 21 Oct 2023 01:58:32 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 20 Oct 2023 22:58:32 -1000 From: "David A. Harding" To: Peter Todd , Bitcoin Protocol Discussion In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.10 Message-ID: X-Sender: dave@dtrt.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 7e27.653392b8.45ba1.0 Cc: "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2023 09:08:21 -0000 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