path: root/9b/f1e3151156c8bcb4a0a06d2cfa51a9838322b4

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 02A1FC0032;
 Fri,  3 Nov 2023 05:25:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id C6DB14357E;
 Fri,  3 Nov 2023 05:25:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C6DB14357E
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=nShnSXD9
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id C1W79Kiu0RxT; Fri,  3 Nov 2023 05:25:36 +0000 (UTC)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com
 [IPv6:2607:f8b0:4864:20::d29])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 739DF40017;
 Fri,  3 Nov 2023 05:25:36 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 739DF40017
Received: by mail-io1-xd29.google.com with SMTP id
 ca18e2360f4ac-7aca968a063so63574439f.0; 
 Thu, 02 Nov 2023 22:25:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1698989135; x=1699593935;
 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=gVKLaYxdOab+rJB4hFcMeun7X5mq1kP+a/G5fKzSRTU=;
 b=nShnSXD9DlIMNaY9AEpwAF1pYcCB6SSlfurcsnxPQulKYD53ISvxss4rm8YK1U+V5B
 D33w9hLGbF7NPzl5xXbsIKm3J2VzE4D49YeazpU/9sWhvTNP2dnnrJ/27U996tB2TAgW
 dqucIJ8SZBUgwF6agLQ2GhvkoyO059S+N+/NuswoNyreuvRMuSRCEjk0auzlHMc5PPdH
 acl92Ob0dPV0x6TEzUkhktj6pmf8QaO5HjczfGukKLURTy7GsqpXg+IcaTLGHnEvHtba
 VSschiPaHDrhTr2UatsM9zZYjVlSwNWFw8RgC1EXWQMipnjK1b9bqfEW5a0H/BBlT+EN
 s+vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1698989135; x=1699593935;
 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=gVKLaYxdOab+rJB4hFcMeun7X5mq1kP+a/G5fKzSRTU=;
 b=ZL4I/mEExjo50aIT5RahbR8R8+WUCP+8mnLqtSjoDtnCFXuHsmVES38CfVaECi55re
 SCT8AvGCcgIqREZ+Z/3YuSo6sYUTPQSgN4mOBJYpWITt33Jmz2xKPKo8HvNHRDEYdwvQ
 yPhpEecwcOCN//PbqHWur7vLc0JawpxOIKkeq53KNJuLMUyFhDaHkBm00/ZR9w40fblq
 sguhqgc3W/15AJ94F9qSbZZj0hEFP6kTZoJLwZKI6G2h/OXePlqKVQ45ls/FcBEldEux
 pMC2+OHFoHCh6iWAQ2YK4LtyAqww7aIIvohOOpmjy3YDwJu5BNz9xhTf8cBtWjML4c/e
 qbmg==
X-Gm-Message-State: AOJu0Yz3XQ4nzaUhTcun69qi2jfNU9RT6dsiJt7Ixp19SxGs+0vhWn3y
 gwQlrhRKg4qcS7g17btdw107+oyxhv5i+ezei4M=
X-Google-Smtp-Source: AGHT+IHyHpezRZY5eWaKAaIIbkBzn2lu6J1en0SYcXmUYSD7CHfULW1BofFRoLCiU7AJ46MDyKpblK+mhixchYIQg0Y=
X-Received: by 2002:a05:6602:2b91:b0:79f:d4e6:5175 with SMTP id
 r17-20020a0566022b9100b0079fd4e65175mr26460892iov.16.1698989135241; Thu, 02
 Nov 2023 22:25:35 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ZTMWrJ6DjxtslJBn@petertodd.org>
 <CALZpt+GQ9g-uwAGYogdaJcinVHRxs4=67hML78KbramJg=davA@mail.gmail.com>
 <ZUNBHsw2BldPLvPc@petertodd.org>
In-Reply-To: <ZUNBHsw2BldPLvPc@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 3 Nov 2023 05:25:24 +0000
Message-ID: <CALZpt+GBcqquPtf0YB07Rcy2OS0kUhv86s6g=69VrfSE72cYJQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000e2260b060938bbad"
X-Mailman-Approved-At: Fri, 03 Nov 2023 09:41:01 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 security@ariard.me, "lightning-dev\\\\@lists.linuxfoundation.org"
 <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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2023 05:25:41 -0000

--000000000000e2260b060938bbad
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 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 and
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 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).

Best,
Antoine

Le jeu. 2 nov. 2023 =C3=A0 06:26, Peter Todd <pete@petertodd.org> a =C3=A9c=
rit :

> On Thu, Nov 02, 2023 at 05:24:36AM +0000, Antoine Riard wrote:
> > Hi Peter,
> >
> > > So, why can't we make the HTLC-preimage path expire? Traditionally,
> we've
> > tried
> > > to ensure that transactions - once valid - remain valid forever. We d=
o
> > this
> > > because we don't want transactions to become impossible to mine in th=
e
> > event of
> > > a large reorganization.
> >
> > I don't know if reverse time-lock where a lightning spending path becom=
es
> > invalid after a block height or epoch point solves the more advanced
> > replacement cycling attacks, where a malicious commitment transaction
> > itself replaces out a honest commitment transaction, and the
> > child-pay-for-parent of this malicious transaction is itself replaced o=
ut
> > by the attacker, leading to the automatic trimming of the malicious
> > commitment transaction.
>
> 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.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--000000000000e2260b060938bbad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; To be clear, are you talking about anchor channels or=
 non-anchor channels?<br>&gt; Because in anchor channels, all outputs other=
 than the anchor outputs provided<br>&gt; for fee bumping can&#39;t be spen=
t until the commitment transaction is mined, which<br>&gt; means RBF/CPFP i=
sn&#39;t relevant.<br><div><br></div><div>I think the distinction is irrele=
vant here as pre-anchor channel if I have one spendable HTLC output spend a=
nd I gain knowledge of my counterparty commitment transaction from networks=
 mempools, the spend is malleable and can be used as a CPFP. If you assume =
anchor channels, you have 2 anchor outputs as long both parties have balanc=
e outputs or pending HTLCs.</div><div><br></div><div>Though pre-anchor, leg=
acy channels the counterparty commitment transaction will have to be attach=
ed with a fee under min mempool fee for the replacement cycling to happen, =
and let network congestion happen.</div><div><br></div><div>I think the mor=
e interesting case is a future world=C2=A0with package relay deployed at th=
e 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).</div><div><br></div><div>Best,</div><div>Antoin=
e</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">Le=C2=A0jeu. 2 nov. 2023 =C3=A0=C2=A006:26, Peter Todd &lt;<a href=
=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; a =C3=A9crit=C2=
=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex">On Thu, Nov 02, 2023 at 05:24:36AM +0000, An=
toine Riard wrote:<br>
&gt; Hi Peter,<br>
&gt; <br>
&gt; &gt; So, why can&#39;t we make the HTLC-preimage path expire? Traditio=
nally, we&#39;ve<br>
&gt; tried<br>
&gt; &gt; to ensure that transactions - once valid - remain valid forever. =
We do<br>
&gt; this<br>
&gt; &gt; because we don&#39;t want transactions to become impossible to mi=
ne in the<br>
&gt; event of<br>
&gt; &gt; a large reorganization.<br>
&gt; <br>
&gt; I don&#39;t know if reverse time-lock where a lightning spending path =
becomes<br>
&gt; invalid after a block height or epoch point solves the more advanced<b=
r>
&gt; replacement cycling attacks, where a malicious commitment transaction<=
br>
&gt; itself replaces out a honest commitment transaction, and the<br>
&gt; child-pay-for-parent of this malicious transaction is itself replaced =
out<br>
&gt; by the attacker, leading to the automatic trimming of the malicious<br=
>
&gt; commitment transaction.<br>
<br>
To be clear, are you talking about anchor channels or non-anchor channels?<=
br>
Because in anchor channels, all outputs other than the anchor outputs provi=
ded<br>
for fee bumping can&#39;t be spent until the commitment transaction is mine=
d, which<br>
means RBF/CPFP isn&#39;t relevant.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>

--000000000000e2260b060938bbad--