From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 15 Aug 2024 21:47:31 -0700 Received: from mail-yb1-f191.google.com ([209.85.219.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1seos6-000202-A3 for bitcoindev@gnusha.org; Thu, 15 Aug 2024 21:47:30 -0700 Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e1169005d9asf2865796276.0 for ; Thu, 15 Aug 2024 21:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1723783644; x=1724388444; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=81MLUyHghGvJCAs4WewTICMKmehHNcK8okBmwlIuxvI=; b=bd1BsBOzI5/UgGvA4aiOUaySP2Granw7p+e4IvVjOFizhhhnLNKtwHJ5qnfXFQdOah M+ls1OJl0G0mESUG0Hok150hGn4A6d5vIDTb0UAjsLrOWblwqUDHK9tgKiWf3msoFvnR P+dntb3SrPflk6vG+LFUP32ZoAgOsNWKN3tg20bsrB+d5eJcpgMFBU+tC6NI+YGsZhaC z6r0EvAIJC6F+vHKiv4v8sLPPveIc0Ws9QMs177VdR9oFa3UaCEZSUxssY1ql0iWdEtl VUjMoFiZLKKRhd0RL/s2lv0Nu3usIFnzjzoRlzya3RAINgqi3gcw3AMoPQEb/YrHMtro jqOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723783644; x=1724388444; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=81MLUyHghGvJCAs4WewTICMKmehHNcK8okBmwlIuxvI=; b=HQPS3vJrZryjYF2LbVXIQvFmlfQW8sWVcs2w64RoYEhyR1HqHiKo7MMMKc/AJBilkp X+ixQt1hQ4jN3jDbeGYXrKCWa/PknKgOppYxogUu4PBOTVMY5wSDiN7/HIpiL+kgvKBb CgU1MC+bjEBEer6GJtJ+yamS4LzhVgRfmu/gHQA8aaf/XQF3ZF4taGo4FQyRK/iuK8by Z3uwrIQvxyOkFR7tvWx3PLHT2hTz3JpqHbLv1tPPvK0atmK77yLE+sLY/ivCWAyy3PsU CjGfxApcYDHOYqDdez8QBbeE4M08kpXCeZ9S6uDUlMPJqbpOVNP3n/9zo/FsA7NChGRq XqQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723783644; x=1724388444; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=81MLUyHghGvJCAs4WewTICMKmehHNcK8okBmwlIuxvI=; b=txo+qtQqWV68hJPeTR8koTJP4GXrjCjsQs1+s848Nslcc2lXJGIRrn/CmL0DrpyD8w C4ZfV8Q4phLyiE/ckANKnx0yWhFoK1SLPoJY3ng87vpsI3Iop+hZ3ylVLgpFQgbPAcP1 7+jGa4Wbqpj0AtPU62kXClOndEYXivlZmVwpVjYb9YDCXXl5XcEoaJxJrRDZO7Xr/Wy0 QUox9oDiV9usQ4UGUxUtT/pnS2sv+zH0oKD9H1Vt6YKBQC8m9lM6xuGshzSkhpZgAq5G pJ2fNUmGF1x2z9v2otxOYeUQcnEzgGXcUZ+SOMNKrE7SMzq+LwPCVNEa9lq+nfptEKaf iD/A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVFbZK38bfWlsK038JaIuMf2QCgGvID0fjQbbHsbdhSLFCcbARooUo8P7FdW/ymHTUDHnyiQOJNqlW9ifGOmYhUwYa+aCE= X-Gm-Message-State: AOJu0YwX12vUbDj1coIA+6m8pfCgdXiVoznJfU0a1Cuz1pLuKQqnGmg8 /O0Y3WQ7WwOIHRKo50Qf2ZLFgV19oHHzMkcTBLl37Q6tv2Fphxif X-Google-Smtp-Source: AGHT+IGNpOCSG04nJo5Qk0WFjkjjm+4I5ImnaM2FcHVy2BSKwnO9+nN4G2u5yEuTKTWO90h3UzweDQ== X-Received: by 2002:a05:6902:723:b0:e11:5d18:2ade with SMTP id 3f1490d57ef6-e1180ef8200mr2536602276.29.1723783643731; Thu, 15 Aug 2024 21:47:23 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:18cd:b0:e0b:3363:5986 with SMTP id 3f1490d57ef6-e116beadad1ls56951276.1.-pod-prod-08-us; Thu, 15 Aug 2024 21:47:22 -0700 (PDT) X-Received: by 2002:a25:9708:0:b0:e0e:a784:2957 with SMTP id 3f1490d57ef6-e1180e55b80mr10309276.1.1723783642525; Thu, 15 Aug 2024 21:47:22 -0700 (PDT) Received: by 2002:a05:690c:f0d:b0:627:7f59:2eee with SMTP id 00721157ae682-6ad370aa13dms7b3; Thu, 15 Aug 2024 21:45:17 -0700 (PDT) X-Received: by 2002:a25:ef4b:0:b0:e11:5da7:337 with SMTP id 3f1490d57ef6-e1180e5b5b8mr12654276.3.1723783516911; Thu, 15 Aug 2024 21:45:16 -0700 (PDT) Date: Thu, 15 Aug 2024 21:45:16 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <04a22956-b722-4f6c-b8d5-0f8905359721n@googlegroups.com> In-Reply-To: References: <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com> <4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.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" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_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,

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

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

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

If there is a lightni= ng node on mainnet of yours that your formally authorize
me to test so= me pinning attacks, I could try a demo. Alternatively, I can
setup a L= N node + full-node on some long-running infrastructure, if you wish
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.

O= n the last observation, I agree with you that is a class type of attack tha= t
one could automate by leveraging fee-estimation algorithms.
Best,
Antoine
ots hash: a958c5bf1a5af3f3fd2b3788b201b95707621c= fecc9b1478075a0da4d8c5c0a5

Le mardi 30 juillet 2024 =C3=A0 20:58:08 UTC= +1, Peter Todd a =C3=A9crit=C2=A0:
On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Ha= rding wrote:
> Given the first point and the last point, I'm not sure how via= ble the
> attack is (but, as I said, I'm not sure I understand it). Est= imating or
> manipulating feerates correctly for over 144 blocks in a row sound= s
> 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 times
in Lighting channels by simply force closing them at times when fee-rat= es were
high. I've even twice managed to delay the force close of a channel= by testing
out justice transactions by broadcasting a low fee-rate, revoked commit= ment,
which the counterparty node did not notice. Instead, the channel just = stayed
in limbo for a few days until the node finally got in a normal force-cl= ose
using the non-revoked state after fees reduced. In both cases, both end= points
were LND using compact block filters (I was running both nodes in these= tests).
IIUC the LND compat block filter implementation does not track mempool
transactions, so it only notices revoked commitment transactions when t= hey
appear in blocks (notice how this means that the lack of package relay = will
render LND's fee-bumping code potentially useless if the conflictin= g commitment
transaction is equal or greater fee/fee-rate).

I haven't tried fully exploiting this particular scenario by maximi= zing the
number of HTLCs in flight; I was just trying out stuff manually. Someon= e
should.

It should be relatively easy to automate this class type of attack by s= imply
picking opportunities for it based on fee rates. It's quite common = for fee
spikes to cause conditions where you can easily predict that fees won&#= 39;t go
below certain levels for many blocks in the future, multiple days even.= Your
claim that "estimating feerates correctly for over 144 blocks in a= row sounds
difficult" is very wrong.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

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