From: Antoine Riard <antoine.riard@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
Date: Thu, 28 Mar 2024 19:13:38 +0000 [thread overview]
Message-ID: <CALZpt+H2B1pSbqNa9phxZMxHX+30AiDqX7TgiRjH4rtirLwb9g@mail.gmail.com> (raw)
In-Reply-To: <ZgV+Rk0m4azlbRZP@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 9582 bytes --]
Hi Peter,
Answering the latest 2 emails.
> Indeed, at this point I strongly suspect had I instead lobbied for a fix
> privately, given that one obvious mitigation is replace-by-fee-rate, I'd
> instead just get accused of nefarious behavior for not doing so openly.
I'll confirm publicly again that transaction-relay bandwidth DoS risks have
been
known or suspected by some senior developers for a while, including
sometimes
mentioned half-way on the Bitcoin Core GH repository years ago.
> Correct me if I'm wrong. But I don't believe that the
`dust_limit_satoshis`
> value can be changed on an existing channel.
> It *should* be possible to change on an existing channel, as the economic
dust
> limit is fee-rate dependent. But the protocol does not support that yet
IIUC.
This is correct, it cannot be changed once it has been negotiated at
opening flow.
Per-BOLT3 "Commitment Transaction Construction", the dust HTLCs are trimmed
and
the amount added to the commitment transaction absolute fee.
This ability can let you generate an ascending feerate range of commitment
transactions:
- state_1, size 1000 kb, 1 trimmed HTLC ~500 sats absolute fee
- state_2, size 900 kb, 2 trimmed HTLC ~1000 sats absolute fee
- state_3, size 800 kb, 3 trimmed HTLC ~1500 sats absolute fee
- etc
Non-dust HTLC fully materializing on the commitment transaction can be
added at wish to
adjust commitment transaction size if you're using a public channel used
for routing, without
the "honest interactivity" of your counterparty.
> There's also a convenience aspect to this: large mempools are convenient
for
> transaction senders, as it allows them to go off line after sending
> transactions that aren't going to be mined in the near future. If we had a
> world of purely always-online transaction senders, mempools could be
smaller.
Yes. This is a good question if a world of common size mempool for hobbyist
full-nodes can still be the network standard in the evolving world of today
where
re-broadcasting and pricing the next few blocks become more done by
transaction
issuers, evicting transactions without high odds to be mined in the near
future.
Said differently, Bitcoin clients with high-timevalue preferences for their
use-cases
are out-pricing Bitcoin clients with low-timevalue preferences from network
mempools.
> Modulo economic irrationalities with differently sized txs like the Rule
#6
> attack, the proof-of-UTXO is almost economically paid even when mempools
are
> partitioned because the bandwidth used by a given form of a transaction is
> limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of
nodes,
> and TxB to the other 50%, both spending the same txout, the total cost/KB
used
> in total would exactly the same... except that nodes have more than one
peer.
> This acts as an amplification fator to attacks depending on the exact
topology
> as bandwidth is wasted in proportion to the # of peers txs need to be
broadcast
> too. Basically, a fan-out factor.
> If the # of peers is reduced, the impact of this type of attack is also
> reduced. Of course, a balance has to be maintained.
Sure, proof-of-UTXO is imperfectly economically charged, however I think
you can
re-use the same proof-of-UTXO for each subset of Sybilled transaction-relay
peers.
And for sure, # peers and network topology can be leveraged as
amplification factors
for this class of "free-relay" attacks. Balance would have to be find
compared to worthiness
of carried-on transaction-relay traffic.
> Oh, and to expand on this discussion a bit... Assuming that LN
implementations
> did enable this type of attack, I'll point out that it's essentially
based on
> having incoming liquidity, which is not free. Either you paid for it by
paying
> someone to open channels to you. Or you operated a lightning node that
provided
> sufficiently attractive survice that people chose to open channels to you.
> Either way getting that incoming capacity cost you money, probably at
similar
> if not worse rates than just borrowing BTC.
Yes, note I used the term "allocated" in one of my previous emails, which I
concede
is not well-defined and it's indeed dependent on Lightning channel network
dynamics.
I'll leave as an exercise to the reader to find common liquidity management
asymmetries
in today's LN implementation to be leveraged as a discount vector for
"free-relay" bandwidth
attacks at the transaction-relay network-level.
Best,
Antoine
Le jeu. 28 mars 2024 à 14:27, Peter Todd <pete@petertodd•org> a écrit :
> On Wed, Mar 27, 2024 at 07:17:24PM +0000, Antoine Riard wrote:
> > > I don't believe the other attacks in this attack class are even
> possible
> > to
> > fix. We just have to live with the fact that a degree of free relay is
> > always
> > going to be possible.
> >
> > See comments under proof-of-UTXO ownership as plausible mitigations.
> >
> > In anway, I think this is not the type of fixes we can land in a covert
> > fashion given the
> > order of magnitude of engineering effort and potential tx-relay network
> > impact.
>
> Indeed, at this point I strongly suspect had I instead lobbied for a fix
> privately, given that one obvious mitigation is replace-by-fee-rate, I'd
> instead just get accused of nefarious behavior for not doing so openly.
>
> > > Can you explain in more detail how exactly you'd pull that off? Are you
> > aware
> > of LN implementations that actually create feerate ascending LN states?
> >
> > I think you can create feerates ascending LN states with today's LN
> > implementations by playing with BOLT2's `dust_limit_satoshis`.
> > State 1 has 1 dust HTLC trimmed, state 2 has 2 dust HTLCs trimmed, ...
> > State N has N dust HTLCs trimmed.
>
> Correct me if I'm wrong. But I don't believe that the `dust_limit_satoshis`
> value can be changed on an existing channel.
>
> It *should* be possible to change on an existing channel, as the economic
> dust
> limit is fee-rate dependent. But the protocol does not support that yet
> IIUC.
>
> > > Imagine if the mempool size was 1TB, an amount larger than the entire
> BTC
> > > blocksize to date. I think that example helps make it obvious that with
> > such an
> > > enormous mempool, there *must* be free relay attacks, because it's
> simply
> > > impossible for all broadcast transactions to even get mined.
> >
> > I think there is an interesting distinction that can be made between
> > mempool size
> > ressources dedicated to increase block template efficiency and minimum
> > mempool size
> > to just ensure you have good BIP152 compact block validation time.
> > Obviously if you're
> > aiming for the first, you're incentivized to offer "free-relay" bandwidth
> > to your peers and
> > increase your view of the ongoing transaction traffic.
>
> There's also a convenience aspect to this: large mempools are convenient
> for
> transaction senders, as it allows them to go off line after sending
> transactions that aren't going to be mined in the near future. If we had a
> world of purely always-online transaction senders, mempools could be
> smaller.
>
> > > All the existing replacement mechanisms _are_ basically a proof-of-UTXO
> > > ownership, because they're transactions spending UTXOs. The only
> question
> > is
> > > the details of how that proof works.
> >
> > Yeah somehow it's correct that any replacement mechanisms encompass a
> > proof-of-UTXO
> > ownership mechanism. Yet in a world you can partition mempool like you
> show
> > with your
> > for example, it's easy to make this proof-of-UTXO economically unpaid by
> > the attacker. Asking
> > aged UTXOs attached to a replacement candidate could be make such proof
> > more robust, in
> > my understanding.
>
> I think you're missing a third aspect to this: # of peers.
>
> Modulo economic irrationalities with differently sized txs like the Rule #6
> attack, the proof-of-UTXO is almost economically paid even when mempools
> are
> partitioned because the bandwidth used by a given form of a transaction is
> limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of
> nodes,
> and TxB to the other 50%, both spending the same txout, the total cost/KB
> used
> in total would exactly the same... except that nodes have more than one
> peer.
> This acts as an amplification fator to attacks depending on the exact
> topology
> as bandwidth is wasted in proportion to the # of peers txs need to be
> broadcast
> too. Basically, a fan-out factor.
>
> If the # of peers is reduced, the impact of this type of attack is also
> reduced. Of course, a balance has to be maintained.
>
> I call the Rule #6 attack an economic irrationality because the higher
> fee-rate
> transaction should have replaced the low fee-rate transactions: it's the
> one
> that got mined, so bandwidth spend on the low fee-rate txs was clearly
> wasted,
> and miners lost out on some fees.
>
> --
> 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/CALZpt%2BH2B1pSbqNa9phxZMxHX%2B30AiDqX7TgiRjH4rtirLwb9g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 11550 bytes --]
next prev parent reply other threads:[~2024-03-28 19:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 13:21 [bitcoindev] " Peter Todd
2024-03-19 12:37 ` Nagaev Boris
2024-03-19 13:46 ` Peter Todd
2024-03-23 0:29 ` Nagaev Boris
2024-03-22 23:18 ` [bitcoindev] " Antoine Riard
2024-03-27 13:04 ` Peter Todd
2024-03-27 19:17 ` Antoine Riard
2024-03-28 14:27 ` Peter Todd
2024-03-28 15:20 ` Peter Todd
2024-03-28 19:13 ` Antoine Riard [this message]
2024-03-28 19:47 ` Peter Todd
2024-03-29 20:48 ` Antoine Riard
2024-03-26 18:36 ` [bitcoindev] " David A. Harding
2024-03-27 6:27 ` Antoine Riard
2024-03-27 12:54 ` 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=CALZpt+H2B1pSbqNa9phxZMxHX+30AiDqX7TgiRjH4rtirLwb9g@mail.gmail.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=pete@petertodd$(echo .)org \
/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