From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
Date: Tue, 23 Jul 2024 17:41:08 -0700 (PDT) [thread overview]
Message-ID: <db52123b-c5ec-4d6e-94c5-5a36bce186b7n@googlegroups.com> (raw)
In-Reply-To: <Zp52WDL4hV16CbKV@petertodd.org>
[-- Attachment #1.1: Type: text/plain, Size: 13034 bytes --]
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 "free" relay attack based on broadcasting conflicting
> transactions at different fee-rates, where the higher fee-rate
transaction is
> not mined, you get a better attack if the higher fee-rate transaction
falls 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 you
can do
> to "reset" the attack is 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 "free" 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 transaction-relay bandwidth is wasted between peers A and B. An
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"
relay
attacks, though far from most and it might worsen if you consider mempool
sizes
asymmetries.
> Not just miners: any node running with mempoolfullrbf=1 is going to waste
less
> bandwidth if someone actually does this attack.
If a majority of miners wouldn't run `mempoolfullrbf=1`, I think it would
have
been a good empirical 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
`mempoolfullrbf=1`,
yes the attack is a bandwidth waste at any `mempoolfullrbf=1` /
`mempoolfullrbf=0`
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 inefficient CPFP
> solutions when RBF (via pre-signed transactions) could have been used
instead.
> This financial figure will only get higher as Lightning gets more
adoption. 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
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
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 compact fee-bumping for commitment in a world
where
block size is limited.
> I have to disagree here. The nature of protocols like Lightning is there
is a
> maximum amount that it's worth attempting to pay to get a transaction
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
have no
> idea 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 you haven't been sybil attacked -
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.
"As long as you do in fact have uncensored access to miner mempools". This
is
the caveat to highlight as an attacker can batch pinning effect by targeting
unrelated channels and occupying the same place in common mempools.
Unrelated
channels have a limited fee-bumping budget to dedicate to fixed-amount
HTLCs.
Such observation was spotted a while back in an old email post of mine on
advanced
pinning vectors (dubbed "network-aware pinning") [0]
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.html
This is correct that one can always have access to miner mempools, while
completely
disregarding the public transaction-relay network, though here we're
talking about
a different security model for lightning. We considered on the
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
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 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 blockspace.
Doesn't work if you consider more advanced pinning vectors like "network
aware pinnings".
> Traditional 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 cryptography litterature not only based on the difficulty of
mathematical
problems, though also on computational hardness assumptions e.g "assume no
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 not (though I don't think deep
methodological
considerations alter the crux of the conversation about "free relay"
attacks here).
Best,
Antoine
ots hash: 79f97742d76e6f349f2a881d8acc6afc8623d897472533272390ed9183baa5c5
Le lundi 22 juillet 2024 à 16:15:12 UTC+1, Peter Todd a écrit :
> On Sat, Jul 20, 2024 at 07:10:53PM -0700, Antoine Riard wrote:
> >
> > Hi Dave,
> >
> > Thanks for your thoughtful answer (even if its wasn't addressed to me
> > primarly).
> >
> > > I cannot imagine what would make you think that protocol developers are
> > > 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.
> >
> > From my experience code reviewing the wallet / mempool re-broadcast of
> few
> > years ago, free tx-relay / bandwidth waste attacks were far to be
> > understood
> > or plainly weighted by some contributors of a newer generations,
> including
> > by
> > the own champion of the proposal. The proposal was finally abandonned
> when a
> > more senior dev came up with quantitative analysis of code changes [0].
> >
> > [0] https://github.com/bitcoin/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
> bandwidth
> spikes. But for any "free" relay attack based on broadcasting conflicting
> transactions at different fee-rates, where the higher fee-rate transaction
> is
> not mined, you get a better attack if the higher fee-rate transaction
> falls 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 you
> can do
> to "reset" the attack is 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.
>
> > > 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 arguing
> > > that devs don't care about free relay because they refused to reverse a
> > > previous decision (to not change the RBF configuration default) that
> has
> > > been hotly debated multiple times.
> >
> > I think what is more interesting and noteworhty in the whole line of
> > reaosning
> > of Peter with the present disclosure is how much the adversial effect is
> > favor
> > by the supermajority of miners running `mempoolfullrbf` [1].
> >
> > [1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316
>
> Not just miners: any node running with mempoolfullrbf=1 is going to waste
> less
> bandwidth if someone actually does this attack.
>
> > Under those conditions, where it took 9 years for the bitcoin core
> project
> > to disclosre
> > some vulnerabilitires, personally I'm more likely to understand that the
> > bitcoin core project
> > is under-staffed is competent experts to keep public disclosure in
> > reasonable timeframe (-- at
> > least equivalent to the kernel world), and as corollorary to fully
> evaluate
> > technical proposal
> > with all its strength and weaknesses.
> >
> > Saying an "already overdiscussed issues that gets nobody closer to
> > 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
> > of technical conversations,
> > implementations and deployment of the "anchor output" upgrade, I believe
> on
> > the long-term CPFP-style fee-bumping
> > of contract protocol, including lighting, is not the most robust
> technical
> > solutions. I think anyone can check
> > in the bitcoin optech anchor output glossary the numerous
> vulnerabilities
> > that have plagued this fee-bumping
> > solutions over the past years.
>
> RBF is way underused in protocols in general. And there have probably been
> literally millions of dollars wasted on fees spent by inefficient CPFP
> solutions when RBF (via pre-signed transactions) could have been used
> instead.
> This financial figure will only get higher as Lightning gets more
> adoption. 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
> channel.
>
> > I already reviewed some parts of cluster mempool. Fundamentally,
> economical
> > mempool pinnings for second-layers (bip125 absolute
> > fee) with pre-signed time-sensitive transactions arises from a world
> where
> > there is (a) an asynchronicity of mempools and (b) one
> > cannot guess feerates at block + 1 (-- let's say in a deterministic
> fashion
> > as understood by traditional cryptographic litterature
> > when doing cryptanalysis). Better RBF policies won't solve that,
> including
> > RBFr.
>
> I have to disagree here. The nature of protocols like Lightning is there
> is a
> maximum amount that it's worth attempting to pay to get a transaction
> 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 have
> no
> idea 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 you haven't been sybil attacked -
> 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
> 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 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 blockspace.
>
> Traditional 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.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
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 email 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.
[-- Attachment #1.2: Type: text/html, Size: 15454 bytes --]
next prev parent reply other threads:[~2024-07-24 0:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:56 Peter Todd
2024-07-18 23:04 ` [bitcoindev] " Antoine Riard
2024-07-19 1:05 ` Peter Todd
2024-07-19 13:52 ` Antoine Riard
2024-07-19 14:38 ` Peter Todd
2024-07-19 23:58 ` Antoine Riard
2024-07-20 0:46 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-21 2:06 ` Antoine Riard
2024-07-21 20:17 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-22 1:59 ` 'Anonymous User' via Bitcoin Development Mailing List
2024-07-24 0:44 ` Antoine Riard
2024-07-24 0:35 ` Antoine Riard
2024-07-19 12:41 ` /dev /fd0
2024-07-19 23:56 ` Antoine Riard
2024-07-20 5:57 ` /dev /fd0
2024-07-20 15:08 ` Peter Todd
2024-07-21 2:13 ` Antoine Riard
2024-07-21 6:16 ` /dev /fd0
2024-07-21 2:12 ` Antoine Riard
2024-07-19 18:26 ` [bitcoindev] " Murch
2024-07-20 14:10 ` Peter Todd
2024-07-20 6:41 ` David A. Harding
2024-07-20 15:03 ` Peter Todd
2024-07-20 15:30 ` Peter Todd
2024-07-21 15:35 ` David A. Harding
2024-07-21 20:25 ` Peter Todd
2024-07-24 0:38 ` Antoine Riard
2024-07-21 2:10 ` Antoine Riard
2024-07-22 15:10 ` Peter Todd
2024-07-24 0:41 ` Antoine Riard [this message]
2024-07-22 11:45 ` [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Peter Todd
2024-07-22 16:43 ` David A. Harding
2024-07-22 20:06 ` Peter Todd
2024-07-22 22:08 ` David A. Harding
2024-07-23 11:29 ` Peter Todd
2024-07-24 0:42 ` Antoine Riard
2024-07-22 17:13 ` [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=db52123b-c5ec-4d6e-94c5-5a36bce186b7n@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox