path: root/cc/561660895d7da7a281a544a907aacc6abde9fd

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 <bitcoindev+bncBC3PT7FYWAMRBXE4QG2QMGQEDN7KIYY@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <db52123b-c5ec-4d6e-94c5-5a36bce186b7n@googlegroups.com>
In-Reply-To: <Zp52WDL4hV16CbKV@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
 <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com>
 <Zp52WDL4hV16CbKV@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_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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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,<br /><br />&gt; An irony here is that rebroadcasting makes most "=
free" relay attacks *more*<br />&gt; expensive, not less. sdaftuar had some=
 correct points, like avoiding bandwidth<br />&gt; spikes. But for any "fre=
e" relay attack based on broadcasting conflicting<br />&gt; transactions at=
 different fee-rates, where the higher fee-rate transaction is<br />&gt; no=
t mined, you get a better attack if the higher fee-rate transaction falls o=
ut<br />&gt; of node mempools, allowing the lower fee-rate conflict to be b=
roadcast again.<br />&gt; <br />&gt; If rebroadcasters ensure that nodes ha=
ve the higher fee-rate tx, all you can do<br />&gt; to "reset" the attack i=
s either get your UTXO(s) mined. Or use an even higher<br />&gt; fee-rate. =
Without rebroadcasting, you can wait for the expiry period to be<br />&gt; =
reached.<br /><br />I read again my review comments on that PR, and what I =
noticed at the time is<br />how automatic rebroadcasting might provoke "fre=
e" relay attacks among a set<br />of mempools with different sizes. If you =
have mempool A at 100 MB and mempool<br />B at 400 MB, assuming the top 100=
 MB of feerate is of same quality, the full diff<br />of 300 MB of transact=
ion-relay bandwidth is wasted between peers A and B. An<br />attacker can s=
till have to chain transactions to bypass bip133 fee filters.<br /><br />So=
 yes, I think rebroadcasting can be a benefice in face of some "free" relay=
<br />attacks, though far from most and it might worsen if you consider mem=
pool sizes<br />asymmetries.<br /><br />&gt; Not just miners: any node runn=
ing with mempoolfullrbf=3D1 is going to waste less<br />&gt; bandwidth if s=
omeone actually does this attack.<br /><br />If a majority of miners wouldn=
't run `mempoolfullrbf=3D1`, I think it would have<br />been a good empiric=
al point that it doesn't increase average block income (and <br />apart of =
any DoS vector for contracting protocols / multi-party applications).<br />=
<br />In such world where a majority of miners are running with `mempoolful=
lrbf=3D1`,<br />yes the attack is a bandwidth waste at any `mempoolfullrbf=
=3D1` / `mempoolfullrbf=3D0`<br />transaction-relay partitions.<br /><br />=
&gt; RBF is way underused in protocols in general. And there have probably =
been<br />&gt; literally millions of dollars wasted on fees spent by ineffi=
cient CPFP<br />&gt; solutions when RBF (via pre-signed transactions) could=
 have been used instead.<br />&gt; This financial figure will only get high=
er as Lightning gets more adoption. It<br />&gt; also limits Lightning in m=
ass failure scenarios: every byte saved while force<br />&gt; closing a cha=
nnel is room that could be used to force close another channel.<br /><br />=
This is correct that with each CPFP we have block chain space weight wasted=
.<br />I'm not going to say that RBF is a perfect solution for lightning an=
d other off-chain<br />use-cases, as you have some other limitations (never=
 took time to do a full public <br />write-up here). Though yes it improves=
 significantly lightning in mass failure<br />scenarios to have the most co=
mpact fee-bumping for commitment in a world where<br />block size is limite=
d.<br /><br />&gt; I have to disagree here. The nature of protocols like Li=
ghtning is there is a<br />&gt; maximum amount that it's worth attempting t=
o pay to get a transaction mined to<br />&gt; perform some action. There al=
so a deadline to perform that action.<br />&gt; <br />&gt; For example, an =
HTLC has a clear expiry time and value. *Even if* you have no<br />&gt; ide=
a what fee-rates are needed to get a transaction mined, you can simply do<b=
r />&gt; repeated RBF bumps at higher and higher fee-rates, ending at a fee=
-rate that<br />&gt; spends the entire value of the HTLC. As long as you do=
 in fact have uncensored<br />&gt; access to miner mempools - as long as yo=
u haven't been sybil attacked - this<br />&gt; approach will do about as we=
ll as is possible, modulo pinning attacks. So our<br />&gt; job is now to s=
imply fix the pinning attacks with better RBF policy.<br /><br />"As long a=
s you do in fact have uncensored access to miner mempools". This is<br />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<br />channels have a limited fee-bumping budget to dedicate to fixe=
d-amount HTLCs.<br /><br />Such observation was spotted a while back in an =
old email post of mine on advanced<br />pinning vectors (dubbed "network-aw=
are pinning") [0]<br /><br />[0] https://lists.linuxfoundation.org/pipermai=
l/bitcoin-dev/2020-June/018011.html<br /><br />This is correct that one can=
 always have access to miner mempools, while completely<br />disregarding t=
he public transaction-relay network, though here we're talking about<br />a=
 different security model for lightning. We considered on the lightning-sid=
e that<br />approach to solve pinnings in the past here [1].<br /><br />[1]=
 https://github.com/lightning/bolts/issues/783<br /><br />&gt; IIUC, this R=
BF fee-bumping approach is exactly what the RBF sweeper introduced<br />&gt=
; in LND v0.18 does. Face with, eg, high blockspace demand the sum total of=
 LND<br />&gt; RBF sweepers will result in the most valuable HTLCs and simi=
lar things being<br />&gt; mined, while less valuable transactions don't (i=
gnoring pinning of course).<br />&gt; That's fine! That's the best we can d=
o given a limited blockspace.<br /><br />Doesn't work if you consider more =
advanced pinning vectors like "network aware pinnings".<br /><br />&gt; Tra=
ditional cryptography literature is not relevant here, as it's based on the=
<br />&gt; difficulty of mathematical problems, not economics; the security=
 of L2<br />&gt; protocols is based on economics.<br /><br />Traditional cr=
yptography litterature not only based on the difficulty of mathematical<br =
/>problems, though also on computational hardness assumptions e.g "assume n=
o one can<br />efficiently find a preimage collison for 80-bits hash".<br /=
><br />That L2 protocol security is based on economics (and physics) doesn'=
t waiwe to do the<br />analytical work on the ressources assumptions beared=
 on attacker to pragmatically<br />determine if an attack is realistic or n=
ot (though I don't think deep methodological<br />considerations alter the =
crux of the conversation about "free relay" attacks here).<br /><br />Best,=
<br />Antoine<br />ots hash: 79f97742d76e6f349f2a881d8acc6afc8623d897472533=
272390ed9183baa5c5<br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" =
class=3D"gmail_attr">Le lundi 22 juillet 2024 =C3=A0 16:15:12 UTC+1, Peter =
Todd a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;">On Sat, Jul 20, 2024 at 07:10:53PM -0700, Antoine Riard wrote:
<br>&gt;=20
<br>&gt; Hi Dave,
<br>&gt;=20
<br>&gt; Thanks for your thoughtful answer (even if its wasn&#39;t addresse=
d to me=20
<br>&gt; primarly).
<br>&gt;=20
<br>&gt; &gt; I cannot imagine what would make you think that protocol deve=
lopers are
<br>&gt; &gt; not concerned about attacks that could drive large numbers of=
 relay
<br>&gt; &gt; nodes off the network for a cost easily affordable to any wel=
l-funded
<br>&gt; &gt; adversary.
<br>&gt;=20
<br>&gt; From my experience code reviewing the wallet / mempool re-broadcas=
t of few
<br>&gt; years ago, free tx-relay / bandwidth waste attacks were far to be=
=20
<br>&gt; understood=20
<br>&gt; or plainly weighted by some contributors of a newer generations, i=
ncluding=20
<br>&gt; by
<br>&gt; the own champion of the proposal. The proposal was finally abandon=
ned when a
<br>&gt; more senior dev came up with quantitative analysis of code changes=
 [0].
<br>&gt;=20
<br>&gt; [0] <a href=3D"https://github.com/bitcoin/bitcoin/pull/21061#issue=
comment-851563105" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/b=
itcoin/pull/21061%23issuecomment-851563105&amp;source=3Dgmail&amp;ust=3D172=
1867919334000&amp;usg=3DAOvVaw3Nm201IiiVNYRYitzaz3Tt">https://github.com/bi=
tcoin/bitcoin/pull/21061#issuecomment-851563105</a>
<br>
<br>An irony here is that rebroadcasting makes most &quot;free&quot; relay =
attacks *more*
<br>expensive, not less. sdaftuar had some correct points, like avoiding ba=
ndwidth
<br>spikes. But for any &quot;free&quot; relay attack based on broadcasting=
 conflicting
<br>transactions at different fee-rates, where the higher fee-rate transact=
ion is
<br>not mined, you get a better attack if the higher fee-rate transaction f=
alls out
<br>of node mempools, allowing the lower fee-rate conflict to be broadcast =
again.
<br>
<br>If rebroadcasters ensure that nodes have the higher fee-rate tx, all yo=
u can do
<br>to &quot;reset&quot; the attack is either get your UTXO(s) mined. Or us=
e an even higher
<br>fee-rate. Without rebroadcasting, you can wait for the expiry period to=
 be
<br>reached.
<br>
<br>&gt; &gt; In this case, you&#39;ve found a specific instance (full-RBF =
vs signaled
<br>&gt; &gt; RBF) of a well-known general problem (optional policies leadi=
ng to
<br>&gt; &gt; mempool inconsistencies, allowing free relay) and appear to b=
e arguing
<br>&gt; &gt; that devs don&#39;t care about free relay because they refuse=
d to reverse a
<br>&gt; &gt; previous decision (to not change the RBF configuration defaul=
t) that has
<br>&gt; &gt; been hotly debated multiple times.
<br>&gt;=20
<br>&gt; I think what is more interesting and noteworhty in the whole line =
of=20
<br>&gt; reaosning
<br>&gt; of Peter with the present disclosure is how much the adversial eff=
ect is=20
<br>&gt; favor
<br>&gt; by the supermajority of miners running `mempoolfullrbf` [1].
<br>&gt;=20
<br>&gt; [1] <a href=3D"https://github.com/bitcoin/bitcoin/pull/28132#issue=
-1817178316" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"htt=
ps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/bitcoin/=
pull/28132%23issue-1817178316&amp;source=3Dgmail&amp;ust=3D1721867919335000=
&amp;usg=3DAOvVaw3efAWWFPqii8NJ6hLz6C5v">https://github.com/bitcoin/bitcoin=
/pull/28132#issue-1817178316</a>
<br>
<br>Not just miners: any node running with mempoolfullrbf=3D1 is going to w=
aste less
<br>bandwidth if someone actually does this attack.=20
<br>
<br>&gt; Under those conditions, where it took 9 years for the bitcoin core=
 project=20
<br>&gt; to disclosre
<br>&gt; some vulnerabilitires, personally I&#39;m more likely to understan=
d that the=20
<br>&gt; bitcoin core project
<br>&gt; is under-staffed is competent experts to keep public disclosure in=
=20
<br>&gt; reasonable timeframe (-- at
<br>&gt; least equivalent to the kernel world), and as corollorary to fully=
 evaluate=20
<br>&gt; technical proposal
<br>&gt; with all its strength and weaknesses.
<br>&gt;=20
<br>&gt; Saying an &quot;already overdiscussed issues that gets nobody clos=
er to=20
<br>&gt; fundamental solutions&quot; is
<br>&gt; insulting for Peter, honestly.
<br>
<br>Indeed. You&#39;d think solid evidence, trivially verifiable by anyone,=
 that almost
<br>all miners had adopted full-rbf would be enough. Instead that evidence =
doesn&#39;t
<br>even receive any acknowledgement.
<br>
<br>&gt; As an offchain protocol developers which has been involved in the =
majority=20
<br>&gt; of technical conversations,
<br>&gt; implementations and deployment of the &quot;anchor output&quot; up=
grade, I believe on=20
<br>&gt; the long-term CPFP-style fee-bumping
<br>&gt; of contract protocol, including lighting, is not the most robust t=
echnical=20
<br>&gt; solutions. I think anyone can check
<br>&gt; in the bitcoin optech anchor output glossary the numerous vulnerab=
ilities=20
<br>&gt; that have plagued this fee-bumping=20
<br>&gt; solutions over the past years.
<br>
<br>RBF is way underused in protocols in general. And there have probably b=
een
<br>literally millions of dollars wasted on fees spent by inefficient CPFP
<br>solutions when RBF (via pre-signed transactions) could have been used i=
nstead.
<br>This financial figure will only get higher as Lightning gets more adopt=
ion. It
<br>also limits Lightning in mass failure scenarios: every byte saved while=
 force
<br>closing a channel is room that could be used to force close another cha=
nnel.
<br>
<br>&gt; I already reviewed some parts of cluster mempool. Fundamentally, e=
conomical=20
<br>&gt; mempool pinnings for second-layers (bip125 absolute
<br>&gt; fee) with pre-signed time-sensitive transactions arises from a wor=
ld where=20
<br>&gt; there is (a) an asynchronicity of mempools and (b) one
<br>&gt; cannot guess feerates at block + 1 (-- let&#39;s say in a determin=
istic fashion=20
<br>&gt; as understood by traditional cryptographic litterature
<br>&gt; when doing cryptanalysis). Better RBF policies won&#39;t solve tha=
t, including=20
<br>&gt; RBFr.
<br>
<br>I have to disagree here. The nature of protocols like Lightning is ther=
e is a
<br>maximum amount that it&#39;s worth attempting to pay to get a transacti=
on mined to
<br>perform some action. There also a deadline to perform that action.
<br>
<br>For example, an HTLC has a clear expiry time and value. *Even if* you h=
ave no
<br>idea what fee-rates are needed to get a transaction mined, you can simp=
ly do
<br>repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate=
 that
<br>spends the entire value of the HTLC. As long as you do in fact have unc=
ensored
<br>access to miner mempools - as long as you haven&#39;t been sybil attack=
ed - this
<br>approach will do about as well as is possible, modulo pinning attacks. =
So our
<br>job is now to simply fix the pinning attacks with better RBF policy.
<br>
<br>IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper int=
roduced
<br>in LND v0.18 does. Face with, eg, high blockspace demand the sum total =
of LND
<br>RBF sweepers will result in the most valuable HTLCs and similar things =
being
<br>mined, while less valuable transactions don&#39;t (ignoring pinning of =
course).
<br>That&#39;s fine! That&#39;s the best we can do given a limited blockspa=
ce.
<br>
<br>Traditional cryptography literature is not relevant here, as it&#39;s b=
ased on the
<br>difficulty of mathematical problems, not economics; the security of L2
<br>protocols is based on economics.
<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=3D1721867919335000&amp;usg=3DAOvVaw0=
3GvowAH1cPtXEa1Xh3Cbq">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=3D1721867919335000&amp;usg=3DAOvVaw2WGoiushBrcM=
Wvt2Jx_5mB">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/db52123b-c5ec-4d6e-94c5-5a36bce186b7n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/db52123b-c5ec-4d6e-94c5-5a36bce186b7n%40googlegroups.com</a>.=
<br />

------=_Part_1207385_1806703419.1721781668039--

------=_Part_1207384_2090839681.1721781668039--