Delivery-date: Tue, 23 Jul 2024 17:44:21 -0700
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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