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"
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
Precedence: list

--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--