path: root/53/adb11897c9fbbecfd442de7f23ecde70ced75e

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 69AF5C0032;
 Fri,  3 Nov 2023 05:28:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 363B040017;
 Fri,  3 Nov 2023 05:28:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 363B040017
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=S9hZVZ8x
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 UjIjubtWXYKe; Fri,  3 Nov 2023 05:28:06 +0000 (UTC)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com
 [IPv6:2607:f8b0:4864:20::333])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 93A2B41AE1;
 Fri,  3 Nov 2023 05:28:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 93A2B41AE1
Received: by mail-ot1-x333.google.com with SMTP id
 46e09a7af769-6ce2fc858feso924094a34.3; 
 Thu, 02 Nov 2023 22:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1698989285; x=1699594085;
 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=0ag4+Iwsn/OAzMz3nPidWiGfZyV522zysq1dS6UVx64=;
 b=S9hZVZ8x3KHVjNTLeQZBJ1YaEMNLdWhvkwJg5GOe9MCODWTzyHhtZRdNj94nLNlVsQ
 AT3CB4bPbvVgKim+KhZ2JZYmsf8zscWrBbuBefOiynMyPLIDy9gc61BPEXd+2EXg6RW9
 fCHEiIRUp6ChWb/AbFhnfrV8DipvCnwROP/Th3WXzbhM4E+r+F/GxhXUvF037gh4fhGf
 Z2nEdidHFOFR9fZLegpmi2Qmmg51hQ9jM3wrcl6jNdmH+9KEDLl5+wagENx/rILkjOsR
 51zvy/xDdnY47gOdbGIq9i4VT6KucmP/Fau2Yo1E8PPOnH3BWLGoL1d11eHIg5dkBpex
 TSgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1698989285; x=1699594085;
 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=0ag4+Iwsn/OAzMz3nPidWiGfZyV522zysq1dS6UVx64=;
 b=t49OqqaSe8AXS07Rr2ptmVqs51Ao1tQ3/H+aRuuX2G7TAFwtEtM0NEoZMIa4h5AncX
 KnTgGrQiJErjEIkYbpPpQ2zPDQvOeHR/WpVeSoOHV4zYcLfWvm2zBksKdOqp5cTeVHhH
 VeTQrpfBfQT7tZg8jpqFsIxfx/awDKUMQqc4SXMHkTpbvWwMR3Ag6IsljGEQ3Y2xrIxQ
 fOJHeBxyJZhN+UbhdyY2hBThACW7vNKdB+vXBrYTuJ+NDs++2VsBJeIuLlpRcldeku1s
 b3jRw0lbkFjuBbTDG526I7Z+ZIrvHq/3O51d7HROZ75jZJDdQxUd6I1MRWvjXYe5Cqai
 5hRw==
X-Gm-Message-State: AOJu0YzT658B8nL/hj/fU/2a5GhfSQZ+rfvDh0kMTnZk4agFUOd20ePI
 WimPXt+x+5PhAcsafpAQs5epBazoJ7EL3xcW9CU=
X-Google-Smtp-Source: AGHT+IFuqr/lZKSGLGu6AaebLBq/5Z6ufyXfZp7PYWb9G+ttWy0cSKAhbbgX7J2dCICIwjc/TuUvmuKDravWbHClq4s=
X-Received: by 2002:a05:6808:2013:b0:3b5:84b0:6bea with SMTP id
 q19-20020a056808201300b003b584b06beamr4040546oiw.22.1698989285582; Thu, 02
 Nov 2023 22:28:05 -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>
 <CAGyamEXYJN0qGKzWPsN8-T1URqmeTbUH7JJjwuFKMHByCwEG3A@mail.gmail.com>
In-Reply-To: <CAGyamEXYJN0qGKzWPsN8-T1URqmeTbUH7JJjwuFKMHByCwEG3A@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 3 Nov 2023 05:27:54 +0000
Message-ID: <CALZpt+EhE=06bg8eph0bJ+bGvoJFSCEkXwmegbUNQcLSr_ACuw@mail.gmail.com>
To: Matt Morehouse <mattmorehouse@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d82dfd060938c462"
X-Mailman-Approved-At: Fri, 03 Nov 2023 09:41:01 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>, security@ariard.me
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:28:11 -0000

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

> The idea with package relay is that commitment transaction fees will
> be zero and that fees will always be paid via CPFP on the anchor
> output.

Yes, even if multiple commitment transactions are pre-signed with a RBF
range of more than zero, an attacker can always select the lowest fees
pre-signed states and adjust in consequence the CPFP paid, and then evict
out the bumping CPFP.

Le jeu. 2 nov. 2023 =C3=A0 17:07, Matt Morehouse <mattmorehouse@gmail.com> =
a
=C3=A9crit :

> On Thu, Nov 2, 2023 at 6:27=E2=80=AFAM Peter Todd via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > 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
> do
> > > this
> > > > because we don't want transactions to become impossible to mine in
> the
> > > event of
> > > > a large reorganization.
> > >
> > > I don't know if reverse time-lock where a lightning spending path
> becomes
> > > 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
> out
> > > 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.
>
> IIUC, Antoine is talking about a cycling attack of the commitment
> transaction itself, not the HTLC transactions.  It seems possible for
> future (ephemeral) anchor channels in a world with package relay.
>
> The idea with package relay is that commitment transaction fees will
> be zero and that fees will always be paid via CPFP on the anchor
> output.
>
> Consider this scenario:  Mallory1 -> Alice -> Mallory2.
> Mallory2 claims an HTLC from Alice off chain via the preimage.  Alice
> attempts to claim the corresponding HTLC from Mallory1, but Mallory1
> refuses to cooperate.  So Alice publishes her commitment transaction
> along with a CPFP on the anchor output.  Mallory1 publishes her
> competing commitment transaction with a higher CPFP fee on the anchor
> output, thereby replacing Alice's package in the mempool.  Mallory1
> then replacement-cycles the anchor output child transaction, causing
> her commitment transaction to lose its CPFP and the package feerate to
> go to zero, which is below the minimum relay fee.  Thus, Mallory1's
> commitment transaction is also evicted from the mempool.  Mallory1
> repeats this process every time Alice broadcasts her commitment, until
> the HTLC timeout expires.  At that point the preimage path becomes
> unspendable, and Mallory1 can claim the HTLC via timeout at her
> leisure.
>
> >
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt; The idea with package relay is that commitment transa=
ction fees will<br>&gt; be zero and that fees will always be paid via CPFP =
on the anchor<br>&gt; output.<br><div><br></div><div>Yes, even if multiple =
commitment transactions are pre-signed with a RBF range of more than zero, =
an attacker can always select the lowest fees pre-signed states and adjust =
in consequence the CPFP paid, and then evict out the bumping CPFP.</div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0jeu. 2 nov. 2023 =C3=A0=C2=A017:07, Matt Morehouse &lt;<a href=3D"mai=
lto:mattmorehouse@gmail.com">mattmorehouse@gmail.com</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:r=
gb(204,204,204);padding-left:1ex">On Thu, Nov 2, 2023 at 6:27=E2=80=AFAM Pe=
ter Todd via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On Thu, Nov 02, 2023 at 05:24:36AM +0000, Antoine Riard wrote:<br>
&gt; &gt; Hi Peter,<br>
&gt; &gt;<br>
&gt; &gt; &gt; So, why can&#39;t we make the HTLC-preimage path expire? Tra=
ditionally, we&#39;ve<br>
&gt; &gt; tried<br>
&gt; &gt; &gt; to ensure that transactions - once valid - remain valid fore=
ver. We do<br>
&gt; &gt; this<br>
&gt; &gt; &gt; because we don&#39;t want transactions to become impossible =
to mine in the<br>
&gt; &gt; event of<br>
&gt; &gt; &gt; a large reorganization.<br>
&gt; &gt;<br>
&gt; &gt; I don&#39;t know if reverse time-lock where a lightning spending =
path becomes<br>
&gt; &gt; invalid after a block height or epoch point solves the more advan=
ced<br>
&gt; &gt; replacement cycling attacks, where a malicious commitment transac=
tion<br>
&gt; &gt; itself replaces out a honest commitment transaction, and the<br>
&gt; &gt; child-pay-for-parent of this malicious transaction is itself repl=
aced out<br>
&gt; &gt; by the attacker, leading to the automatic trimming of the malicio=
us<br>
&gt; &gt; commitment transaction.<br>
&gt;<br>
&gt; To be clear, are you talking about anchor channels or non-anchor chann=
els?<br>
&gt; Because in anchor channels, all outputs other than the anchor outputs =
provided<br>
&gt; for fee bumping can&#39;t be spent until the commitment transaction is=
 mined, which<br>
&gt; means RBF/CPFP isn&#39;t relevant.<br>
<br>
IIUC, Antoine is talking about a cycling attack of the commitment<br>
transaction itself, not the HTLC transactions.=C2=A0 It seems possible for<=
br>
future (ephemeral) anchor channels in a world with package relay.<br>
<br>
The idea with package relay is that commitment transaction fees will<br>
be zero and that fees will always be paid via CPFP on the anchor<br>
output.<br>
<br>
Consider this scenario:=C2=A0 Mallory1 -&gt; Alice -&gt; Mallory2.<br>
Mallory2 claims an HTLC from Alice off chain via the preimage.=C2=A0 Alice<=
br>
attempts to claim the corresponding HTLC from Mallory1, but Mallory1<br>
refuses to cooperate.=C2=A0 So Alice publishes her commitment transaction<b=
r>
along with a CPFP on the anchor output.=C2=A0 Mallory1 publishes her<br>
competing commitment transaction with a higher CPFP fee on the anchor<br>
output, thereby replacing Alice&#39;s package in the mempool.=C2=A0 Mallory=
1<br>
then replacement-cycles the anchor output child transaction, causing<br>
her commitment transaction to lose its CPFP and the package feerate to<br>
go to zero, which is below the minimum relay fee.=C2=A0 Thus, Mallory1&#39;=
s<br>
commitment transaction is also evicted from the mempool.=C2=A0 Mallory1<br>
repeats this process every time Alice broadcasts her commitment, until<br>
the HTLC timeout expires.=C2=A0 At that point the preimage path becomes<br>
unspendable, and Mallory1 can claim the HTLC via timeout at her<br>
leisure.<br>
<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; <a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank"=
>https://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd=
.org" rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000d82dfd060938c462--