From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 23 Jul 2024 17:44:21 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sWQ7A-0004qp-A0 for bitcoindev@gnusha.org; Tue, 23 Jul 2024 17:44:21 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e03623b24ddsf12841197276.1 for ; Tue, 23 Jul 2024 17:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721781854; x=1722386654; 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=YsxOR4CbZVuNS/6iM5WnFcU4tHnPxTeUuqYveRvJJrs=; b=aUd+JQag1OXyLJ5lHBnVFKMxnznafx756KnHFuUmDWKMfhcRiEPaxr/H7hrX9so5wJ 6mt813pNiCZ9lEAogpv5a29L3pLS4kbcAwkk/zjQAq/qV+Uvgg4JFg97b8C+ffgahJ/b Ya0hlJ9c6p2R/rA9TnG099GdqKVkHbSm3oZTplsZSaFZJuwWsEwY8Dxh3X2tzDlt+n6T WjAMaSlRjQMD0HmTjxeadp2wHQqxncvTUt68zP7qHNbWdzU4tFWsMID727pZdnd0c155 OhuYNPByzzMw1yaiSPsA5C+O/y8Z88wsrntiQKrIXMFhsH1EUuu2w2g76uHHD+ntaI0u gTxQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721781854; x=1722386654; 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=YsxOR4CbZVuNS/6iM5WnFcU4tHnPxTeUuqYveRvJJrs=; b=nqy380CQouhY1hRhMBk5aSA/hlzjdm78M4pbKPbf2hqzE5HxgCVUu0Rlb8SYhqgolv UJuT/rM0pOprlCUX3QbQmD/dt9tRI9GcZwJobcvAqzLlwATMo/lkpgycSfCfr+6MO32i WYM98q7DARRUxS6FREBpCkm/5/1kFLxsNdSC4bXQmZ94d/eVv5oI3ITm8ttPN6QFUGF+ hKHE+mAagsHGdDAXEbwedMj4aHi+ieJLAN3nxCXiQHQeZm0EEpUeiTKw/h3Z5nzxYcta HF3jvt5IvjbtrzykHsLa3T6w2U2X6hclYWmmyDr1gWKcvWZ+QDN8OtWd7M20XTOO9U64 am0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721781854; x=1722386654; 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=YsxOR4CbZVuNS/6iM5WnFcU4tHnPxTeUuqYveRvJJrs=; b=JY0LZsRaPWNeJzGnruyVqIyvPDExx6d7APhHbDtFEwFZ16ejuioGso+U7A+YzV5EWF l185DBQGPnUkPkvwr8YNoE1vi8OzNqDwl1ZV2ZJRm3tDtRvJiBxuHZVxJeshKewHvjMD SnOrtoTZJXT678P8TVI5jsq+Yk+0V85wV+Vh9OPr+6gL3X6Y2/uzDKRxV8xByvG244Rb BdRQURfKnk5QzwVjYBpygfAXYzbUfn9bX1Rk4+5P7a0QJpWUGQuIvkgEx89l4bjj25k9 1sXAvB9c2lV0p8M7cja2xARObYItBEAE5S911fKaOoEU70XaJ5UzCmgc+lUvEb2AWbwG bIOg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWoUBa2AJPD+Je17qfxaqavfDPypyA7WUOdoMF1a+kjpTGlGMTKNJT/NEyCSNd1m6JD0wMfq5ZXOC/Le7aBtuZx2l0Ul4w= X-Gm-Message-State: AOJu0YzM/6FqYCs2ARxSGlbLJOPgK0s/DM8ggi3xli+B4AwniwVc5xmK hXRv/craA2FqhNV+35Jsdp0rhL5pbduf+nmmYUDihp7UqGrKL0Ny X-Google-Smtp-Source: AGHT+IENnT/cHlVJfc+16hQKqP/EHh3uitV+o1Me6PjwIf8naSdjCmUx8SJZFMWnwr4QxcLM0jiLfg== X-Received: by 2002:a05:6902:18ca:b0:e0b:9b5:8667 with SMTP id 3f1490d57ef6-e0b09b58b46mr1593037276.53.1721781853876; Tue, 23 Jul 2024 17:44:13 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:f912:0:b0:e03:6457:383f with SMTP id 3f1490d57ef6-e05fdb408a3ls9188561276.1.-pod-prod-09-us; Tue, 23 Jul 2024 17:44:12 -0700 (PDT) X-Received: by 2002:a05:690c:38b:b0:62d:a29:537e with SMTP id 00721157ae682-66a663575camr9266777b3.4.1721781852700; Tue, 23 Jul 2024 17:44:12 -0700 (PDT) Received: by 2002:a05:690c:2d11:b0:66a:8967:a513 with SMTP id 00721157ae682-66a8967cffams7b3; Tue, 23 Jul 2024 17:41:09 -0700 (PDT) X-Received: by 2002:a05:6902:725:b0:e03:c033:1ce3 with SMTP id 3f1490d57ef6-e087006043amr315354276.4.1721781668270; Tue, 23 Jul 2024 17:41:08 -0700 (PDT) Date: Tue, 23 Jul 2024 17:41:08 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com> 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_1207384_2090839681.1721781668039" 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_1207384_2090839681.1721781668039 Content-Type: multipart/alternative; boundary="----=_Part_1207385_1806703419.1721781668039" ------=_Part_1207385_1806703419.1721781668039 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter, > An irony here is that rebroadcasting makes most "free" relay attacks=20 *more* > expensive, not less. sdaftuar had some correct points, like avoiding=20 bandwidth > spikes. But for any "free" relay attack based on broadcasting conflicting > transactions at different fee-rates, where the higher fee-rate=20 transaction is > not mined, you get a better attack if the higher fee-rate transaction=20 falls out > of node mempools, allowing the lower fee-rate conflict to be broadcast=20 again. >=20 > If rebroadcasters ensure that nodes have the higher fee-rate tx, all you= =20 can do > to "reset" the attack is either get your UTXO(s) mined. Or use an even=20 higher > fee-rate. Without rebroadcasting, you can wait for the expiry period to b= e > reached. I read again my review comments on that PR, and what I noticed at the time= =20 is how automatic rebroadcasting might provoke "free" relay attacks among a set of mempools with different sizes. If you have mempool A at 100 MB and=20 mempool B at 400 MB, assuming the top 100 MB of feerate is of same quality, the=20 full diff of 300 MB of transaction-relay bandwidth is wasted between peers A and B. A= n attacker can still have to chain transactions to bypass bip133 fee filters. So yes, I think rebroadcasting can be a benefice in face of some "free"=20 relay attacks, though far from most and it might worsen if you consider mempool= =20 sizes asymmetries. > Not just miners: any node running with mempoolfullrbf=3D1 is going to was= te=20 less > bandwidth if someone actually does this attack. If a majority of miners wouldn't run `mempoolfullrbf=3D1`, I think it would= =20 have been a good empirical point that it doesn't increase average block income= =20 (and=20 apart of any DoS vector for contracting protocols / multi-party=20 applications). In such world where a majority of miners are running with=20 `mempoolfullrbf=3D1`, yes the attack is a bandwidth waste at any `mempoolfullrbf=3D1` /=20 `mempoolfullrbf=3D0` transaction-relay partitions. > RBF is way underused in protocols in general. And there have probably bee= n > literally millions of dollars wasted on fees spent by inefficient CPFP > solutions when RBF (via pre-signed transactions) could have been used=20 instead. > This financial figure will only get higher as Lightning gets more=20 adoption. It > also limits Lightning in mass failure scenarios: every byte saved while= =20 force > closing a channel is room that could be used to force close another=20 channel. This is correct that with each CPFP we have block chain space weight wasted= . I'm not going to say that RBF is a perfect solution for lightning and other= =20 off-chain use-cases, as you have some other limitations (never took time to do a full= =20 public=20 write-up here). Though yes it improves significantly lightning in mass=20 failure scenarios to have the most compact fee-bumping for commitment in a world=20 where block size is limited. > I have to disagree here. The nature of protocols like Lightning is there= =20 is a > maximum amount that it's worth attempting to pay to get a transaction=20 mined to > perform some action. There also a deadline to perform that action. >=20 > For example, an HTLC has a clear expiry time and value. *Even if* you=20 have no > idea what fee-rates are needed to get a transaction mined, you can simply= =20 do > repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate= =20 that > spends the entire value of the HTLC. As long as you do in fact have=20 uncensored > access to miner mempools - as long as you haven't been sybil attacked -= =20 this > approach will do about as well as is possible, modulo pinning attacks. So= =20 our > job is now to simply fix the pinning attacks with better RBF policy. "As long as you do in fact have uncensored access to miner mempools". This= =20 is the caveat to highlight as an attacker can batch pinning effect by targetin= g unrelated channels and occupying the same place in common mempools.=20 Unrelated channels have a limited fee-bumping budget to dedicate to fixed-amount=20 HTLCs. Such observation was spotted a while back in an old email post of mine on= =20 advanced pinning vectors (dubbed "network-aware pinning") [0] [0]=20 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.ht= ml This is correct that one can always have access to miner mempools, while=20 completely disregarding the public transaction-relay network, though here we're=20 talking about a different security model for lightning. We considered on the=20 lightning-side that approach to solve pinnings in the past here [1]. [1] https://github.com/lightning/bolts/issues/783 > IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper=20 introduced > in LND v0.18 does. Face with, eg, high blockspace demand the sum total of= =20 LND > RBF sweepers will result in the most valuable HTLCs and similar things=20 being > mined, while less valuable transactions don't (ignoring pinning of=20 course). > That's fine! That's the best we can do given a limited blockspace. Doesn't work if you consider more advanced pinning vectors like "network=20 aware pinnings". > Traditional cryptography literature is not relevant here, as it's based= =20 on the > difficulty of mathematical problems, not economics; the security of L2 > protocols is based on economics. Traditional cryptography litterature not only based on the difficulty of=20 mathematical problems, though also on computational hardness assumptions e.g "assume no= =20 one can efficiently find a preimage collison for 80-bits hash". That L2 protocol security is based on economics (and physics) doesn't waiwe= =20 to do the analytical work on the ressources assumptions beared on attacker to=20 pragmatically determine if an attack is realistic or not (though I don't think deep=20 methodological considerations alter the crux of the conversation about "free relay"=20 attacks here). Best, Antoine ots hash: 79f97742d76e6f349f2a881d8acc6afc8623d897472533272390ed9183baa5c5 Le lundi 22 juillet 2024 =C3=A0 16:15:12 UTC+1, Peter Todd a =C3=A9crit : > On Sat, Jul 20, 2024 at 07:10:53PM -0700, Antoine Riard wrote: > >=20 > > Hi Dave, > >=20 > > Thanks for your thoughtful answer (even if its wasn't addressed to me= =20 > > primarly). > >=20 > > > I cannot imagine what would make you think that protocol developers a= re > > > not concerned about attacks that could drive large numbers of relay > > > nodes off the network for a cost easily affordable to any well-funded > > > adversary. > >=20 > > From my experience code reviewing the wallet / mempool re-broadcast of= =20 > few > > years ago, free tx-relay / bandwidth waste attacks were far to be=20 > > understood=20 > > or plainly weighted by some contributors of a newer generations,=20 > including=20 > > by > > the own champion of the proposal. The proposal was finally abandonned= =20 > when a > > more senior dev came up with quantitative analysis of code changes [0]. > >=20 > > [0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-85156310= 5 > > An irony here is that rebroadcasting makes most "free" relay attacks *mor= e* > expensive, not less. sdaftuar had some correct points, like avoiding=20 > bandwidth > spikes. But for any "free" relay attack based on broadcasting conflicting > transactions at different fee-rates, where the higher fee-rate transactio= n=20 > is > not mined, you get a better attack if the higher fee-rate transaction=20 > falls out > of node mempools, allowing the lower fee-rate conflict to be broadcast=20 > again. > > If rebroadcasters ensure that nodes have the higher fee-rate tx, all you= =20 > can do > to "reset" the attack is either get your UTXO(s) mined. Or use an even=20 > higher > fee-rate. Without rebroadcasting, you can wait for the expiry period to b= e > reached. > > > > In this case, you've found a specific instance (full-RBF vs signaled > > > RBF) of a well-known general problem (optional policies leading to > > > mempool inconsistencies, allowing free relay) and appear to be arguin= g > > > that devs don't care about free relay because they refused to reverse= a > > > previous decision (to not change the RBF configuration default) that= =20 > has > > > been hotly debated multiple times. > >=20 > > I think what is more interesting and noteworhty in the whole line of=20 > > reaosning > > of Peter with the present disclosure is how much the adversial effect i= s=20 > > favor > > by the supermajority of miners running `mempoolfullrbf` [1]. > >=20 > > [1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316 > > Not just miners: any node running with mempoolfullrbf=3D1 is going to was= te=20 > less > bandwidth if someone actually does this attack.=20 > > > Under those conditions, where it took 9 years for the bitcoin core=20 > project=20 > > to disclosre > > some vulnerabilitires, personally I'm more likely to understand that th= e=20 > > bitcoin core project > > is under-staffed is competent experts to keep public disclosure in=20 > > reasonable timeframe (-- at > > least equivalent to the kernel world), and as corollorary to fully=20 > evaluate=20 > > technical proposal > > with all its strength and weaknesses. > >=20 > > Saying an "already overdiscussed issues that gets nobody closer to=20 > > fundamental solutions" is > > insulting for Peter, honestly. > > Indeed. You'd think solid evidence, trivially verifiable by anyone, that= =20 > almost > all miners had adopted full-rbf would be enough. Instead that evidence=20 > doesn't > even receive any acknowledgement. > > > As an offchain protocol developers which has been involved in the=20 > majority=20 > > of technical conversations, > > implementations and deployment of the "anchor output" upgrade, I believ= e=20 > on=20 > > the long-term CPFP-style fee-bumping > > of contract protocol, including lighting, is not the most robust=20 > technical=20 > > solutions. I think anyone can check > > in the bitcoin optech anchor output glossary the numerous=20 > vulnerabilities=20 > > that have plagued this fee-bumping=20 > > solutions over the past years. > > RBF is way underused in protocols in general. And there have probably bee= n > literally millions of dollars wasted on fees spent by inefficient CPFP > solutions when RBF (via pre-signed transactions) could have been used=20 > instead. > This financial figure will only get higher as Lightning gets more=20 > adoption. It > also limits Lightning in mass failure scenarios: every byte saved while= =20 > force > closing a channel is room that could be used to force close another=20 > channel. > > > I already reviewed some parts of cluster mempool. Fundamentally,=20 > economical=20 > > mempool pinnings for second-layers (bip125 absolute > > fee) with pre-signed time-sensitive transactions arises from a world=20 > where=20 > > there is (a) an asynchronicity of mempools and (b) one > > cannot guess feerates at block + 1 (-- let's say in a deterministic=20 > fashion=20 > > as understood by traditional cryptographic litterature > > when doing cryptanalysis). Better RBF policies won't solve that,=20 > including=20 > > RBFr. > > I have to disagree here. The nature of protocols like Lightning is there= =20 > is a > maximum amount that it's worth attempting to pay to get a transaction=20 > mined to > perform some action. There also a deadline to perform that action. > > For example, an HTLC has a clear expiry time and value. *Even if* you hav= e=20 > no > idea what fee-rates are needed to get a transaction mined, you can simply= =20 > do > repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate= =20 > that > spends the entire value of the HTLC. As long as you do in fact have=20 > uncensored > access to miner mempools - as long as you haven't been sybil attacked -= =20 > this > approach will do about as well as is possible, modulo pinning attacks. So= =20 > our > job is now to simply fix the pinning attacks with better RBF policy. > > IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper=20 > introduced > in LND v0.18 does. Face with, eg, high blockspace demand the sum total of= =20 > LND > RBF sweepers will result in the most valuable HTLCs and similar things=20 > being > mined, while less valuable transactions don't (ignoring pinning of course= ). > That's fine! That's the best we can do given a limited blockspace. > > Traditional cryptography literature is not relevant here, as it's based o= n=20 > the > difficulty of mathematical problems, not economics; the security of L2 > protocols is based on economics. > > --=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/db52123b-c5ec-4d6e-94c5-5a36bce186b7n%40googlegroups.com. ------=_Part_1207385_1806703419.1721781668039 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter,

> An irony here is that rebroadcasting makes most "= free" relay attacks *more*
> expensive, not less. sdaftuar had some= correct points, like avoiding bandwidth
> spikes. But for any "fre= e" relay attack based on broadcasting conflicting
> transactions at= different fee-rates, where the higher fee-rate transaction is
> no= t mined, you get a better attack if the higher fee-rate transaction falls o= ut
> of node mempools, allowing the lower fee-rate conflict to be b= roadcast again.
>
> If rebroadcasters ensure that nodes ha= ve the higher fee-rate tx, all you can do
> to "reset" the attack i= s either get your UTXO(s) mined. Or use an even higher
> fee-rate. = Without rebroadcasting, you can wait for the expiry period to be
> = reached.

I read again my review comments on that PR, and what I = noticed at the time is
how automatic rebroadcasting might provoke "fre= e" relay attacks among a set
of mempools with different sizes. If you = have mempool A at 100 MB and mempool
B at 400 MB, assuming the top 100= MB of feerate is of same quality, the full diff
of 300 MB of transact= ion-relay bandwidth is wasted between peers A and B. An
attacker can s= till have to chain transactions to bypass bip133 fee filters.

So= yes, I think rebroadcasting can be a benefice in face of some "free" relay=
attacks, though far from most and it might worsen if you consider mem= pool sizes
asymmetries.

> Not just miners: any node runn= ing with mempoolfullrbf=3D1 is going to waste less
> bandwidth if s= omeone actually does this attack.

If a majority of miners wouldn= 't run `mempoolfullrbf=3D1`, I think it would have
been a good empiric= al point that it doesn't increase average block income (and
apart of = any DoS vector for contracting protocols / multi-party applications).
=
In such world where a majority of miners are running with `mempoolful= lrbf=3D1`,
yes the attack is a bandwidth waste at any `mempoolfullrbf= =3D1` / `mempoolfullrbf=3D0`
transaction-relay partitions.

= > RBF is way underused in protocols in general. And there have probably = been
> literally millions of dollars wasted on fees spent by ineffi= cient CPFP
> solutions when RBF (via pre-signed transactions) could= have been used instead.
> This financial figure will only get high= er as Lightning gets more adoption. It
> also limits Lightning in m= ass failure scenarios: every byte saved while force
> closing a cha= nnel is room that could be used to force close another channel.

= This is correct that with each CPFP we have block chain space weight wasted= .
I'm not going to say that RBF is a perfect solution for lightning an= d other off-chain
use-cases, as you have some other limitations (never= took time to do a full public
write-up here). Though yes it improves= significantly lightning in mass failure
scenarios to have the most co= mpact fee-bumping for commitment in a world where
block size is limite= d.

> I have to disagree here. The nature of protocols like Li= ghtning is there is a
> maximum amount that it's worth attempting t= o pay to get a transaction mined to
> perform some action. There al= so a deadline to perform that action.
>
> For example, an = HTLC has a clear expiry time and value. *Even if* you have no
> ide= a what fee-rates are needed to get a transaction mined, you can simply do> repeated RBF bumps at higher and higher fee-rates, ending at a fee= -rate that
> spends the entire value of the HTLC. As long as you do= in fact have uncensored
> access to miner mempools - as long as yo= u haven't been sybil attacked - this
> approach will do about as we= ll as is possible, modulo pinning attacks. So our
> job is now to s= imply fix the pinning attacks with better RBF policy.

"As long a= s you do in fact have uncensored access to miner mempools". This is
th= e caveat to highlight as an attacker can batch pinning effect by targeting<= br />unrelated channels and occupying the same place in common mempools. Un= related
channels have a limited fee-bumping budget to dedicate to fixe= d-amount HTLCs.

Such observation was spotted a while back in an = old email post of mine on advanced
pinning vectors (dubbed "network-aw= are pinning") [0]

[0] https://lists.linuxfoundation.org/pipermai= l/bitcoin-dev/2020-June/018011.html

This is correct that one can= always have access to miner mempools, while completely
disregarding t= he public transaction-relay network, though here we're talking about
a= different security model for lightning. We considered on the lightning-sid= e that
approach to solve pinnings in the past here [1].

[1]= https://github.com/lightning/bolts/issues/783

> IIUC, this R= BF fee-bumping approach is exactly what the RBF sweeper introduced
>= ; in LND v0.18 does. Face with, eg, high blockspace demand the sum total of= LND
> RBF sweepers will result in the most valuable HTLCs and simi= lar things being
> mined, while less valuable transactions don't (i= gnoring pinning of course).
> That's fine! That's the best we can d= o given a limited blockspace.

Doesn't work if you consider more = advanced pinning vectors like "network aware pinnings".

> Tra= ditional cryptography literature is not relevant here, as it's based on the=
> difficulty of mathematical problems, not economics; the security= of L2
> protocols is based on economics.

Traditional cr= yptography litterature not only based on the difficulty of mathematical
problems, though also on computational hardness assumptions e.g "assume n= o one can
efficiently find a preimage collison for 80-bits hash".

That L2 protocol security is based on economics (and physics) doesn'= t waiwe to do the
analytical work on the ressources assumptions beared= on attacker to pragmatically
determine if an attack is realistic or n= ot (though I don't think deep methodological
considerations alter the = crux of the conversation about "free relay" attacks here).

Best,=
Antoine
ots hash: 79f97742d76e6f349f2a881d8acc6afc8623d897472533= 272390ed9183baa5c5

Le lundi 22 juillet 2024 =C3=A0 16:15:12 UTC+1, Peter = Todd a =C3=A9crit=C2=A0:
On Sat, Jul 20, 2024 at 07:10:53PM -0700, Antoine Riard wrote:
>=20
> Hi Dave,
>=20
> Thanks for your thoughtful answer (even if its wasn't addresse= d to me=20
> primarly).
>=20
> > I cannot imagine what would make you think that protocol deve= lopers are
> > not concerned about attacks that could drive large numbers of= relay
> > nodes off the network for a cost easily affordable to any wel= l-funded
> > adversary.
>=20
> From my experience code reviewing the wallet / mempool re-broadcas= t of few
> years ago, free tx-relay / bandwidth waste attacks were far to be= =20
> understood=20
> or plainly weighted by some contributors of a newer generations, i= ncluding=20
> by
> the own champion of the proposal. The proposal was finally abandon= ned when a
> more senior dev came up with quantitative analysis of code changes= [0].
>=20
> [0] https://github.com/bi= tcoin/bitcoin/pull/21061#issuecomment-851563105

An irony here is that rebroadcasting makes most "free" relay = attacks *more*
expensive, not less. sdaftuar had some correct points, like avoiding ba= ndwidth
spikes. But for any "free" relay attack based on broadcasting= conflicting
transactions at different fee-rates, where the higher fee-rate transact= ion is
not mined, you get a better attack if the higher fee-rate transaction f= alls out
of node mempools, allowing the lower fee-rate conflict to be broadcast = again.

If rebroadcasters ensure that nodes have the higher fee-rate tx, all yo= u can do
to "reset" the attack is either get your UTXO(s) mined. Or us= e an even higher
fee-rate. Without rebroadcasting, you can wait for the expiry period to= be
reached.

> > In this case, you've found a specific instance (full-RBF = vs signaled
> > RBF) of a well-known general problem (optional policies leadi= ng to
> > mempool inconsistencies, allowing free relay) and appear to b= e arguing
> > that devs don't care about free relay because they refuse= d to reverse a
> > previous decision (to not change the RBF configuration defaul= t) that has
> > been hotly debated multiple times.
>=20
> I think what is more interesting and noteworhty in the whole line = of=20
> reaosning
> of Peter with the present disclosure is how much the adversial eff= ect is=20
> favor
> by the supermajority of miners running `mempoolfullrbf` [1].
>=20
> [1] https://github.com/bitcoin/bitcoin= /pull/28132#issue-1817178316

Not just miners: any node running with mempoolfullrbf=3D1 is going to w= aste less
bandwidth if someone actually does this attack.=20

> Under those conditions, where it took 9 years for the bitcoin core= project=20
> to disclosre
> some vulnerabilitires, personally I'm more likely to understan= d that the=20
> bitcoin core project
> is under-staffed is competent experts to keep public disclosure in= =20
> reasonable timeframe (-- at
> least equivalent to the kernel world), and as corollorary to fully= evaluate=20
> technical proposal
> with all its strength and weaknesses.
>=20
> Saying an "already overdiscussed issues that gets nobody clos= er to=20
> fundamental solutions" is
> insulting for Peter, honestly.

Indeed. You'd think solid evidence, trivially verifiable by anyone,= that almost
all miners had adopted full-rbf would be enough. Instead that evidence = doesn't
even receive any acknowledgement.

> As an offchain protocol developers which has been involved in the = majority=20
> of technical conversations,
> implementations and deployment of the "anchor output" up= grade, I believe on=20
> the long-term CPFP-style fee-bumping
> of contract protocol, including lighting, is not the most robust t= echnical=20
> solutions. I think anyone can check
> in the bitcoin optech anchor output glossary the numerous vulnerab= ilities=20
> that have plagued this fee-bumping=20
> solutions over the past years.

RBF is way underused in protocols in general. And there have probably b= een
literally millions of dollars wasted on fees spent by inefficient CPFP
solutions when RBF (via pre-signed transactions) could have been used i= nstead.
This financial figure will only get higher as Lightning gets more adopt= ion. It
also limits Lightning in mass failure scenarios: every byte saved while= force
closing a channel is room that could be used to force close another cha= nnel.

> I already reviewed some parts of cluster mempool. Fundamentally, e= conomical=20
> mempool pinnings for second-layers (bip125 absolute
> fee) with pre-signed time-sensitive transactions arises from a wor= ld where=20
> there is (a) an asynchronicity of mempools and (b) one
> cannot guess feerates at block + 1 (-- let's say in a determin= istic fashion=20
> as understood by traditional cryptographic litterature
> when doing cryptanalysis). Better RBF policies won't solve tha= t, including=20
> RBFr.

I have to disagree here. The nature of protocols like Lightning is ther= e is a
maximum amount that it's worth attempting to pay to get a transacti= on mined to
perform some action. There also a deadline to perform that action.

For example, an HTLC has a clear expiry time and value. *Even if* you h= ave no
idea what fee-rates are needed to get a transaction mined, you can simp= ly do
repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate= that
spends the entire value of the HTLC. As long as you do in fact have unc= ensored
access to miner mempools - as long as you haven't been sybil attack= ed - this
approach will do about as well as is possible, modulo pinning attacks. = So our
job is now to simply fix the pinning attacks with better RBF policy.

IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper int= roduced
in LND v0.18 does. Face with, eg, high blockspace demand the sum total = of LND
RBF sweepers will result in the most valuable HTLCs and similar things = being
mined, while less valuable transactions don't (ignoring pinning of = course).
That's fine! That's the best we can do given a limited blockspa= ce.

Traditional cryptography literature is not relevant here, as it's b= ased on the
difficulty of mathematical problems, not economics; the security of L2
protocols is based on economics.

--=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/db52123b-c5ec-4d6e-94c5-5a36bce186b7n%40googlegroups.com.=
------=_Part_1207385_1806703419.1721781668039-- ------=_Part_1207384_2090839681.1721781668039--