Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id F03C1C0032; Mon, 6 Nov 2023 18:45:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id BDF01416C4; Mon, 6 Nov 2023 18:45:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org BDF01416C4 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=hq1Wh1RT X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey5Pmh6JFagy; Mon, 6 Nov 2023 18:45:34 +0000 (UTC) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by smtp4.osuosl.org (Postfix) with ESMTPS id 5B35A416AD; Mon, 6 Nov 2023 18:45:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5B35A416AD Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-7ad1236c419so146287039f.0; Mon, 06 Nov 2023 10:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699296333; x=1699901133; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dZl3lzHZInKtAi2NjPJMIVkdZskf/y818ugurj1WdGA=; b=hq1Wh1RTApt/PP9kMH3Dr+i/inevOCTOlqRD9wJwESAbx917JzfEu6q7TM9v9p+AFW TZl65t7PHadJtcfcoWImhtT3PCxiBVyJu6o6U/F0tvOLHx7P2Fs0yNg9YB5Qymg2psJy 0W9z8PQpCMoT54c7eVFqe0ULdaTy2ThEmHnxbybY2r2TQMUYpi+ufRuqESMpGLIVJ+Ab A9tx8i01Hu0BEDUX03mTMcEfkDDILfks+E18dt1+6CfwsUy/r1oWtzPaPW7TucsjPVzO e7TTPbkBEPPhjmYnQVLOsCuqucpUCQclUrfgInj9VJevaLf2tvE5FTXfHoEyDxmyvrZu vAOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699296333; x=1699901133; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dZl3lzHZInKtAi2NjPJMIVkdZskf/y818ugurj1WdGA=; b=pySCwE3uV085YVIhKojtTkyIfqt0LB+3saZHqRdBBsh/tkPdSi50yApaqXqMUFp5a5 ZoVw5YOOZBohjQUo+sik7L+vJheNwme8Q3ljuD6oeK+EJ+2ts+xSYMXrLMY4+6Si2x9w f6Zf3oEi+ZIHFSIdXBelC5oM3FclBZs8Yf3KbJ3i6AXu1PZ0gS3tjOh/Xlzz1n/IbG8I I4MvR5anffn/J7zvhOj8v0kOZ9jvqP+3HNUDmCguDb3ZaIkSFJIL2IoeInRVrcsvk0gE puKIV8h/s8DPmtQfDpw8Vu94dNr/+fuDz+4/V/xuKy+2m+kHwOiUUZVZME4xgIdZ9wvu 665g== X-Gm-Message-State: AOJu0YyDwOTUaJC7A02x3nkkpZiqHTrdWXVlA4eJnNlQXTynZfsJsj/4 JGjkW3a8hSCEcSVpEYBVyFui+EEUzttHn+/pGUs= X-Google-Smtp-Source: AGHT+IF9S4SZj1vl/4+GqKF+kVDndMommwPHfHgj7z3H/pj+dImSS9QN0LFkV1U2TKCcQDcsLZbo8BjcuIvRq5KN2nA= X-Received: by 2002:a05:6e02:219d:b0:359:4b3b:530d with SMTP id j29-20020a056e02219d00b003594b3b530dmr678702ila.7.1699296333198; Mon, 06 Nov 2023 10:45:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Mon, 6 Nov 2023 18:45:21 +0000 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="0000000000004efd90060980427e" X-Mailman-Approved-At: Tue, 07 Nov 2023 11:42:54 +0000 Cc: Bitcoin Protocol Discussion , security@ariard.me, "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: Mon, 06 Nov 2023 18:45:36 -0000 --0000000000004efd90060980427e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I think you are misunderstanding a key point to my OP_Expire proposal: because > the ability to spend the preimage branch of the HTLC goes away when the refund > branch becomes available, replacing cycling or any similar technique becomes > entirely irrelevant. > The situation where Carol prevents Bob from learning about the preimage in time > simply can't happen: either Carol collects the HTLC with knowledge of the > preimage, by spending it in a transaction mined prior to the expiration time > and ensuring that Bob learns the preimage from the blockchain itself. Or the > HTLC expires and Bob can use the refund branch at his leisure. I think I understand the semantic of the OP_Expire proposal overall correctly, however I'm not sure it prevents replacing cycling or any similar adversarial technique, as the forwarding node might be the attacker in some scenario. Consider the following: you have Alice, Bob, Caroll sharing lightning channels. Alice forwards a HTLC of 1 BTC to Caroll by the intermediary of Bob. On the Bob-Caroll link, the HTLC expires at block 100. According to OP_Expire semantics, Caroll shouldn't be able to claim the htlc-preimage spends on the Bob-Caroll link, after block 100. However, this situation offers the ability to Bob the routing node to steal HTLC payment between Alice and Caroll. Once the HTLC is committed on the Bob-Caroll link, Caroll releases the preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob does _not_ send back his signature for the updated channel state. Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC output with the preimage. Her commitment transaction propagation in network mempools is systematically "replaced cycled out" by Bob. At block 100, Caroll cannot claim the payment sent to her by Alice. Bob claims the htlc-refund path on the Bob-Caroll link and claims the htlc-preimage path on the Alice-Bob link, as such making a gain of 1 BTC. If Caroll is a lightning mobile client, it is easy for Bob to claim publicly that the lack of success in signature exchange to update channels state is a liveliness mistake of her own. Assuming this advanced scenario is correct, I'm not sure the OP_Expire proposal is substantially fixing all the adversarial replacement cycling situations. Best, Antoine Le sam. 4 nov. 2023 =C3=A0 07:26, Peter Todd a =C3=A9c= rit : > On Fri, Nov 03, 2023 at 05:25:24AM +0000, Antoine Riard wrote: > > > To be clear, are you talking about anchor channels or non-anchor > channels? > > > Because in anchor channels, all outputs other than the anchor outputs > > provided > > > for fee bumping can't be spent until the commitment transaction is > mined, > > which > > > means RBF/CPFP isn't relevant. > > > > I think the distinction is irrelevant here as pre-anchor channel if I > have > > one spendable HTLC output spend and I gain knowledge of my counterparty > > commitment transaction from networks mempools, the spend is malleable a= nd > > can be used as a CPFP. If you assume anchor channels, you have 2 anchor > > outputs as long both parties have balance outputs or pending HTLCs. > > > > Though pre-anchor, legacy channels the counterparty commitment > transaction > > will have to be attached with a fee under min mempool fee for the > > replacement cycling to happen, and let network congestion happen. > > I think you are misunderstanding a key point to my OP_Expire proposal: > because > the ability to spend the preimage branch of the HTLC goes away when the > refund > branch becomes available, replacing cycling or any similar technique > becomes > entirely irrelevant. > > The situation where Carol prevents Bob from learning about the preimage i= n > time > simply can't happen: either Carol collects the HTLC with knowledge of the > preimage, by spending it in a transaction mined prior to the expiration > time > and ensuring that Bob learns the preimage from the blockchain itself. Or > the > HTLC expires and Bob can use the refund branch at his leisure. > > > I think the more interesting case is a future world with package relay > > deployed at the p2p level and anchor output on the lightning-side. Here > the > > most advanced replacement as illustrated in the test can happen (where > > commitment has an anchor output - see L125). > > Again, with OP_Expire, whether or not package relay or anything similar > exists > is irrelevant. Replacement cycling is totally useless because there is a > defined time window in which the HTLC can be spent with the preimage, aft= er > which only the refund branch can be used. > > Indeed, with OP_Expire Lightning nodes will no longer need to monitor > mempools > for preimages at all. If the preimage is used, it is guaranteed to end up > in > the chain, and the Lightning node is guaranteed to see it provided they > have > access to up-to-date blockchain data. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > --0000000000004efd90060980427e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I think you are misunderstanding a key point to my OP= _Expire proposal: because
> the ability to spend the preimage branch = of the HTLC goes away when the refund
> branch becomes available, rep= lacing cycling or any similar technique becomes
> entirely irrelevant= .

> The situation where Carol prevents Bob from learning about th= e preimage in time
> simply can't happen: either Carol collects t= he HTLC with knowledge of the
> preimage, by spending it in a transac= tion mined prior to the expiration time
> and ensuring that Bob learn= s the preimage from the blockchain itself. Or the
> HTLC expires and = Bob can use the refund branch at his leisure.

I thin= k I understand=C2=A0the semantic of the OP_Expire proposal overall correctl= y, however I'm not sure it prevents replacing cycling or any similar ad= versarial technique, as the forwarding node might be the attacker in some s= cenario.

Consider the following: you have Alice, B= ob, Caroll sharing lightning channels.

Alice forwa= rds a HTLC of 1 BTC to Caroll by the intermediary of Bob.

On the Bob-Caroll link, the HTLC expires at block 100.
According to OP_Expire semantics, Caroll shouldn't be able= to claim the htlc-preimage spends on the Bob-Caroll link, after block 100.=

However, this situation offers the ability to Bob= the routing node to steal HTLC payment between Alice and Caroll.

Once the HTLC is committed on the Bob-Caroll link, Caroll r= eleases the preimage off-chain to Bob with an `update_fulfill_htlc` message= , though Bob does _not_ send back his signature for the updated channel sta= te.

Some blocks before 100, Caroll goes on-chain t= o claim the inbound HTLC output with the preimage. Her commitment transacti= on propagation in network mempools is systematically "replaced=C2=A0cy= cled out" by Bob.

At block 100, Caroll cannot= claim the payment sent to her by Alice.

Bob claim= s the htlc-refund path on the Bob-Caroll link and claims the htlc-preimage = path on the Alice-Bob link, as such making a gain of 1 BTC.

<= /div>
If Caroll is a lightning mobile client, it is easy for Bob to cla= im publicly that the lack of success in signature exchange to update channe= ls state is a liveliness mistake of her own.

Assum= ing this advanced scenario is correct, I'm not sure the OP_Expire propo= sal is substantially fixing all the adversarial replacement cycling situati= ons.

Best,
Antoine

Le=C2=A0sam. 4 n= ov. 2023 =C3=A0=C2=A007:26, Peter Todd <pete@petertodd.org> a =C3=A9crit=C2=A0:
On Fri, Nov 03, 2023 at 05:25:24AM +0000, Antoine Riard wrote:
> > To be clear, are you talking about anchor channels or non-anchor = channels?
> > Because in anchor channels, all outputs other than the anchor out= puts
> provided
> > for fee bumping can't be spent until the commitment transacti= on is mined,
> which
> > means RBF/CPFP isn't relevant.
>
> I think the distinction is irrelevant here as pre-anchor channel if I = have
> one spendable HTLC output spend and I gain knowledge of my counterpart= y
> commitment transaction from networks mempools, the spend is malleable = and
> can be used as a CPFP. If you assume anchor channels, you have 2 ancho= r
> outputs as long both parties have balance outputs or pending HTLCs. >
> Though pre-anchor, legacy channels the counterparty commitment transac= tion
> will have to be attached with a fee under min mempool fee for the
> replacement cycling to happen, and let network congestion happen.

I think you are misunderstanding a key point to my OP_Expire proposal: beca= use
the ability to spend the preimage branch of the HTLC goes away when the ref= und
branch becomes available, replacing cycling or any similar technique become= s
entirely irrelevant.

The situation where Carol prevents Bob from learning about the preimage in = time
simply can't happen: either Carol collects the HTLC with knowledge of t= he
preimage, by spending it in a transaction mined prior to the expiration tim= e
and ensuring that Bob learns the preimage from the blockchain itself. Or th= e
HTLC expires and Bob can use the refund branch at his leisure.

> I think the more interesting case is a future world with package relay=
> deployed at the p2p level and anchor output on the lightning-side. Her= e the
> most advanced replacement as illustrated in the test can happen (where=
> commitment has an anchor output - see L125).

Again, with OP_Expire, whether or not package relay or anything similar exi= sts
is irrelevant. Replacement cycling is totally useless because there is a defined time window in which the HTLC can be spent with the preimage, after=
which only the refund branch can be used.

Indeed, with OP_Expire Lightning nodes will no longer need to monitor mempo= ols
for preimages at all. If the preimage is used, it is guaranteed to end up i= n
the chain, and the Lightning node is guaranteed to see it provided they hav= e
access to up-to-date blockchain data.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--0000000000004efd90060980427e--