Delivery-date: Thu, 28 Mar 2024 07:58:29 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 64.147.123.144 as permitted sender) client-ip=64.147.123.144;
Feedback-ID: i525146e8:Fastmail
Date: Thu, 28 Mar 2024 14:27:18 +0000
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
Message-ID: <ZgV+Rk0m4azlbRZP@petertodd.org>
References: <Zfg/6IZyA/iInyMx@petertodd.org>
 <0a377ddb-b001-41ba-9208-27b3fa059bb5n@googlegroups.com>
 <ZgQZUOCc/dSjKMoL@petertodd.org>
 <CALZpt+GOCiwYdK4vfkODrT0Sx6HxCAuvhVqa1c5o3Xjy03OiAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="nQsR4l3SVl/46568"
Content-Disposition: inline
In-Reply-To: <CALZpt+GOCiwYdK4vfkODrT0Sx6HxCAuvhVqa1c5o3Xjy03OiAQ@mail.gmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--nQsR4l3SVl/46568
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

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/ZgV%2BRk0m4azlbRZP%40petertodd.org.

--nQsR4l3SVl/46568
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmYFfj8ACgkQLly11TVR
LzdZWg/+N7SHalFTmifKpJ4KaADVlyoGlRFittRIFLzlz6roSp/sQ2c7NJwmfUtH
Uulj9V3MPfQZ5PBMc6L5Xhx+fOLD6i1M+P3lMendFPiQAje0SrQOy/n/oW//dR6K
AiRrhf6aYkbVygITLgw2oQP2ukfze0ls10YL1ezI/itEKYLoWNHMLNF+RVtl6DMn
14lf9WTadAVUXcs6avbpUNggEYE7w8MYf+zC7tisZKcphdJm6stvLQYZ5yHWVqNM
AnOb7ejkL5Y2jFl1urz84f+quqwb1OxUJ6+UkVoKjmVaBL7fcvflOL2+PWWA0H1J
HPf9nQSzGUVVk+oBa6yGU8vyw1KyXsFm55LI0KQyqyuOTa81UVUEKM/mONae2ymu
oe2xjMKIOfu091O0jxrGDu90iaqS3R1QEPtAE4U4BDcePPsazG39BlvHzhM2Mbxq
JM/2FI7EQoXdHE5GETey/ENz7AsvzyepG3QLM65HV6OzLR6rdnZj7sPuJWMZsCTo
kn75B/afJmbuV6fO1tKA4tKl091ckPE/P9S/ggp3A6xrNzEMJA2i2BuYgA2Dn7Fg
xb5P4D06aZTKXjtwmj7qMaflnbzAsrI68jpzK/pX9JC+RbNwCahF18y9EZ5PK65c
t5p6H0Ry/YXpYpGVrz2Fbqe7OLl2lEytiCgtoe5sr3G9SgXlmF4=
=wXFE
-----END PGP SIGNATURE-----

--nQsR4l3SVl/46568--