Delivery-date: Thu, 15 Aug 2024 21:47:31 -0700
Sender: bitcoindev@googlegroups.com
Date: Thu, 15 Aug 2024 21:45:16 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <04a22956-b722-4f6c-b8d5-0f8905359721n@googlegroups.com>
In-Reply-To: <ZqlBKVXBKKIurBPk@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
 <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com>
 <4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.org>
 <ZqlBKVXBKKIurBPk@petertodd.org>
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
 of Full-RBF In Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_27274_1705358906.1723783516668"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_27274_1705358906.1723783516668
Content-Type: multipart/alternative; 
	boundary="----=_Part_27275_343673669.1723783516668"

------=_Part_27275_343673669.1723783516668
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

> It is not.
>=20
> I've actually *accidentally* exploited this type of pinning vector a few=
=20
times
> in Lighting channels by simply force closing them at times when fee-rates=
=20
were
> high. I've even twice managed to delay the force close of a channel by=20
testing
> out justice transactions by broadcasting a low fee-rate, revoked=20
commitment,
> which the counterparty node did not notice. Instead, the channel just=20
stayed
> in limbo for a few days until the node finally got in a normal force-clos=
e
> using the non-revoked state after fees reduced. In both cases, both=20
endpoints
> were LND using compact block filters (I was running both nodes in these=
=20
tests).
> IIUC the LND compat block filter implementation does not track mempool
> transactions, so it only notices revoked commitment transactions when the=
y
> appear in blocks (notice how this means that the lack of package relay=20
will
> render LND's fee-bumping code potentially useless if the conflicting=20
commitment
> transaction is equal or greater fee/fee-rate).
>=20
> I haven't tried fully exploiting this particular scenario by maximizing=
=20
the
> number of HTLCs in flight; I was just trying out stuff manually. Someone
> should.
>=20
> It should be relatively easy to automate this class type of attack by=20
simply
> picking opportunities for it based on fee rates. It's quite common for fe=
e
> spikes to cause conditions where you can easily predict that fees won't g=
o
> below certain levels for many blocks in the future, multiple days even.=
=20
Your
> claim that "estimating feerates correctly for over 144 blocks in a row=20
sounds
> difficult" is very wrong.

After reading Dave description of the "loophole pinning" attack, which is a
re-formalization of my gitub comment on one of the TRUC PR, I'm not entirel=
y
sure, we're describing the same exploitation scenario. Finely evaluating th=
e
viability of an attack, before the attack scheme and attacker capabilities=
=20
are
fleshed out is a bit premature...

Especially, when you're saying few more lines after that you have tried to
fully exploit this scenario with HTLCs in flights, and all other attempts
were more accidental and without being sure the LND software correctly
implements RBF, including the rule 5 penalty computation at all time (you'r=
e
observing yourself the limitations of LND's fee-bumping code).

If there is a lightning node on mainnet of yours that your formally=20
authorize
me to test some pinning attacks, I could try a demo. Alternatively, I can
setup a LN node + full-node on some long-running infrastructure, if you wis=
h
to try the scenario on your side. Though, as observed by Dave there is no
lightning code written yet to opt-in into TRUC transactions.

On the last observation, I agree with you that is a class type of attack=20
that
one could automate by leveraging fee-estimation algorithms.

Best,
Antoine
ots hash: a958c5bf1a5af3f3fd2b3788b201b95707621cfecc9b1478075a0da4d8c5c0a5

Le mardi 30 juillet 2024 =C3=A0 20:58:08 UTC+1, Peter Todd a =C3=A9crit :

> On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Harding wrote:
> > Given the first point and the last point, I'm not sure how viable the
> > attack is (but, as I said, I'm not sure I understand it). Estimating or
> > manipulating feerates correctly for over 144 blocks in a row sounds
> > difficult. Counterparties being able to deprive Mallory of profit seems
> > like a major weakness.
>
> It is not.
>
> I've actually *accidentally* exploited this type of pinning vector a few=
=20
> times
> in Lighting channels by simply force closing them at times when fee-rates=
=20
> were
> high. I've even twice managed to delay the force close of a channel by=20
> testing
> out justice transactions by broadcasting a low fee-rate, revoked=20
> commitment,
> which the counterparty node did not notice. Instead, the channel just=20
> stayed
> in limbo for a few days until the node finally got in a normal force-clos=
e
> using the non-revoked state after fees reduced. In both cases, both=20
> endpoints
> were LND using compact block filters (I was running both nodes in these=
=20
> tests).
> IIUC the LND compat block filter implementation does not track mempool
> transactions, so it only notices revoked commitment transactions when the=
y
> appear in blocks (notice how this means that the lack of package relay wi=
ll
> render LND's fee-bumping code potentially useless if the conflicting=20
> commitment
> transaction is equal or greater fee/fee-rate).
>
> I haven't tried fully exploiting this particular scenario by maximizing t=
he
> number of HTLCs in flight; I was just trying out stuff manually. Someone
> should.
>
> It should be relatively easy to automate this class type of attack by=20
> simply
> picking opportunities for it based on fee rates. It's quite common for fe=
e
> spikes to cause conditions where you can easily predict that fees won't g=
o
> below certain levels for many blocks in the future, multiple days even.=
=20
> Your
> claim that "estimating feerates correctly for over 144 blocks in a row=20
> sounds
> difficult" is very wrong.
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/04a22956-b722-4f6c-b8d5-0f8905359721n%40googlegroups.com.

------=_Part_27275_343673669.1723783516668
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,<br /><br />&gt; It is not.<br />&gt; <br />&gt; I've actually *ac=
cidentally* exploited this type of pinning vector a few times<br />&gt; in =
Lighting channels by simply force closing them at times when fee-rates were=
<br />&gt; high. I've even twice managed to delay the force close of a chan=
nel by testing<br />&gt; out justice transactions by broadcasting a low fee=
-rate, revoked commitment,<br />&gt; which the counterparty node did not no=
tice. Instead, the channel just stayed<br />&gt; in limbo for a few days un=
til the node finally got in a normal force-close<br />&gt; using the non-re=
voked state after fees reduced. In both cases, both endpoints<br />&gt; wer=
e LND using compact block filters (I was running both nodes in these tests)=
.<br />&gt; IIUC the LND compat block filter implementation does not track =
mempool<br />&gt; transactions, so it only notices revoked commitment trans=
actions when they<br />&gt; appear in blocks (notice how this means that th=
e lack of package relay will<br />&gt; render LND's fee-bumping code potent=
ially useless if the conflicting commitment<br />&gt; transaction is equal =
or greater fee/fee-rate).<br />&gt; <br />&gt; I haven't tried fully exploi=
ting this particular scenario by maximizing the<br />&gt; number of HTLCs i=
n flight; I was just trying out stuff manually. Someone<br />&gt; should.<b=
r />&gt; <br />&gt; It should be relatively easy to automate this class typ=
e of attack by simply<br />&gt; picking opportunities for it based on fee r=
ates. It's quite common for fee<br />&gt; spikes to cause conditions where =
you can easily predict that fees won't go<br />&gt; below certain levels fo=
r many blocks in the future, multiple days even. Your<br />&gt; claim that =
"estimating feerates correctly for over 144 blocks in a row sounds<br />&gt=
; difficult" is very wrong.<br /><br />After reading Dave description of th=
e "loophole pinning" attack, which is a<br />re-formalization of my gitub c=
omment on one of the TRUC PR, I'm not entirely<br />sure, we're describing =
the same exploitation scenario. Finely evaluating the<br />viability of an =
attack, before the attack scheme and attacker capabilities are<br />fleshed=
 out is a bit premature...<br /><br />Especially, when you're saying few mo=
re lines after that you have tried to<br />fully exploit this scenario with=
 HTLCs in flights, and all other attempts<br />were more accidental and wit=
hout being sure the LND software correctly<br />implements RBF, including t=
he rule 5 penalty computation at all time (you're<br />observing yourself t=
he limitations of LND's fee-bumping code).<br /><br />If there is a lightni=
ng node on mainnet of yours that your formally authorize<br />me to test so=
me pinning attacks, I could try a demo. Alternatively, I can<br />setup a L=
N node + full-node on some long-running infrastructure, if you wish<br />to=
 try the scenario on your side. Though, as observed by Dave there is no<br =
/>lightning code written yet to opt-in into TRUC transactions.<br /><br />O=
n the last observation, I agree with you that is a class type of attack tha=
t<br />one could automate by leveraging fee-estimation algorithms.<br /><br=
 />Best,<br />Antoine<br />ots hash: a958c5bf1a5af3f3fd2b3788b201b95707621c=
fecc9b1478075a0da4d8c5c0a5<br /><br /><div class=3D"gmail_quote"><div dir=
=3D"auto" class=3D"gmail_attr">Le mardi 30 juillet 2024 =C3=A0 20:58:08 UTC=
+1, Peter Todd a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204)=
; padding-left: 1ex;">On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Ha=
rding wrote:
<br>&gt; Given the first point and the last point, I&#39;m not sure how via=
ble the
<br>&gt; attack is (but, as I said, I&#39;m not sure I understand it).  Est=
imating or
<br>&gt; manipulating feerates correctly for over 144 blocks in a row sound=
s
<br>&gt; difficult.  Counterparties being able to deprive Mallory of profit=
 seems
<br>&gt; like a major weakness.
<br>
<br>It is not.
<br>
<br>I&#39;ve actually *accidentally* exploited this type of pinning vector =
a few times
<br>in Lighting channels by simply force closing them at times when fee-rat=
es were
<br>high. I&#39;ve even twice managed to delay the force close of a channel=
 by testing
<br>out justice transactions by broadcasting a low fee-rate, revoked commit=
ment,
<br>which the counterparty node did not notice.  Instead, the channel just =
stayed
<br>in limbo for a few days until the node finally got in a normal force-cl=
ose
<br>using the non-revoked state after fees reduced. In both cases, both end=
points
<br>were LND using compact block filters (I was running both nodes in these=
 tests).
<br>IIUC the LND compat block filter implementation does not track mempool
<br>transactions, so it only notices revoked commitment transactions when t=
hey
<br>appear in blocks (notice how this means that the lack of package relay =
will
<br>render LND&#39;s fee-bumping code potentially useless if the conflictin=
g commitment
<br>transaction is equal or greater fee/fee-rate).
<br>
<br>I haven&#39;t tried fully exploiting this particular scenario by maximi=
zing the
<br>number of HTLCs in flight; I was just trying out stuff manually. Someon=
e
<br>should.
<br>
<br>It should be relatively easy to automate this class type of attack by s=
imply
<br>picking opportunities for it based on fee rates. It&#39;s quite common =
for fee
<br>spikes to cause conditions where you can easily predict that fees won&#=
39;t go
<br>below certain levels for many blocks in the future, multiple days even.=
 Your
<br>claim that &quot;estimating feerates correctly for over 144 blocks in a=
 row sounds
<br>difficult&quot; is very wrong.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1723869845122000&amp;usg=3DAOvVaw0=
Bw-iSvzWNJwUgsyoRzhoI">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1723869845122000&amp;usg=3DAOvVaw2f00vpl6Qan8=
aIXE9rwFCY">petertodd.org</a>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/04a22956-b722-4f6c-b8d5-0f8905359721n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/04a22956-b722-4f6c-b8d5-0f8905359721n%40googlegroups.com</a>.=
<br />

------=_Part_27275_343673669.1723783516668--

------=_Part_27274_1705358906.1723783516668--