Delivery-date: Wed, 27 Mar 2024 06:06:23 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 64.147.123.20 as permitted sender) client-ip=64.147.123.20;
Feedback-ID: i525146e8:Fastmail
Date: Wed, 27 Mar 2024 13:04:16 +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: <ZgQZUOCc/dSjKMoL@petertodd.org>
References: <Zfg/6IZyA/iInyMx@petertodd.org>
 <0a377ddb-b001-41ba-9208-27b3fa059bb5n@googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="PpuiUmP00u1KRYlS"
Content-Disposition: inline
In-Reply-To: <0a377ddb-b001-41ba-9208-27b3fa059bb5n@googlegroups.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


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

On Fri, Mar 22, 2024 at 04:18:18PM -0700, Antoine Riard wrote:
> Hi Peter,
> 
> > The marginal cost to an attacker who was planning on broadcasting B 
> anyway is 
> > fairly small, as provided that sufficiently small fee-rates are chosen 
> for A_n, 
> > the probability of A_n being mined is low. The attack does of course 
> require 
> > capital, as the attacker needs to have UTXO's of sufficient size for A_n.
> 
> I think an attacker does not necessarily need to have a UTXO's of 
> sufficient size for A_n.
> One could reuse feerate ascending old LN states, where the balance on 
> latest states is
> in favor of your counterparty. So it might be a lower assumption on 
> attacker ressources,
> you only needs to have been _allocate_ a shared-UTXO in the past.

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?

> > The larger the mempool size limit, the more 
> > effective the attack tends to be. Similarly, the attack is more effective 
> with 
> > a larger size difference between A and B. Finally, the attack is more 
> effective 
> > with a smaller minimum incremental relay fee, as more individual versions 
> of 
> > the transaction can be broadcast for a given fee-delta range.
> 
> I think the observation on larger the mempool size, more effective the 
> attack tends
> to come as a novel insight to me. Naively, in a world where the future 
> blockspace
> demand is uncertain, miners have an incentive to scale up their mempool 
> size limit.
> As such, holding a cache of non-mined low-feerates transactions. The type 
> of bandwidth,
> denial-of-service described sounds effectively to affect more full-nodes 
> with large 
> mempools. Fair point, it's expected they have more bandwidth ressources 
> available too.

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.

> Commenting on this, do we have a free-relay attack variant where an 
> attacker with reasonable
> visibility on the transaction-relay network could exploit propagation 
> asymmetries due to
> *_INVENTORY_BROADCAST_INTERVAL and re-inject A_n traffic in a targeted 
> fashion ?
> I don't think it's worst than the parallelization you're describing, it's 
> just another approach.

Well, whether or not that is an attack depends on how exactly the transcation
could be rebroadcast.

> > Requiring replacements to increase the fee-rate by a certain ratio would 
> also 
> > mitigate the attack. However doing so would break a lot of wallet 
> software that 
> > bumps fees by values equal or close to the minimum relay fee.
> 
> I think there is still the open questions of the economic relevance of 
> replace-by-fee if
> the local mempool is completely empty. Here a miner is optimizing to 
> maximize absolute
> fee as a transaction replaced by a higher-feerate, lower fee is less 
> interesting if you have
> less than 1 MB virtual bytes / 4 MB WU.

Obviously. That's why I proposed one-shot replace-by-fee-rate. Not pure
replace-by-fee-rate.

> > Ironically, the existence of this attack is an argument in favor of 
> > replace-by-fee-rate. While RBFR introduces a degree of free-relay, the 
> fact 
> > that Bitcoin Core's existing rules *also* allow for free-relay in this 
> form 
> > makes the difference inconsequential.
> 
> Back on the point where an attacker ability to provoke bandwidth DoS in 
> considerations
> of the UTXO-amount available, a minimal absolute fee as a proof of owning 
> some UTXO
> amount could be still maintained (or maybe after a _bounded_ number of 
> replacement under
> a given block period).
> 
> We studied proof-of-UTXO ownership as a p2p DoS mitigation approach in the 
> past with Gleb:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html

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.

-- 
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/ZgQZUOCc/dSjKMoL%40petertodd.org.

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmYEGU4ACgkQLly11TVR
LzctjBAAm+89w34SEgz7iJqtvL2NzxI90i3JN5dd5yYriVJZIm0YN0NdKBGodGRg
NDie7Y3ZD+cBIf6haYe+qdxoiNElO1e8kARNa7cm9M3T9bPQVAD/gyxhjd3EEA9B
+SqrwNiHiZvsGV7G1M44QzuDhkTxRGuRSc+xyS9Oq3euc42JX7NNz3l2tJB+lKB1
TYDyMzLySse7T32XpV/f+n1iGrtDG56thSmy/A+KtaqdIJNJRMv2vJxfVgTtdY0y
Z/JCu53Z3+lzldE0uLgyphWIUxIP9LkwPnXFlM37blkqApPQg9dzsr+BQW0PPjeH
075arPC/4BTU1CW/WWMh9kGQTIZfbSH5JM6e44zSufz2VrZOPZeIsplP5bzUeSRQ
OwMYd/ofWHkrfh5LGP1Zi+xKl/7D9QN657grW1iqFGdK6PxACDyACIBf/qZcVmMN
DMwr+I4opyYMy81IZiBEBOlB1RJ+F73LfdlgX7nPQ1WYDRRnibJGCNyumkuJmz3y
7B2VpPG1mCBRmkfoPDWQN6a5tkrJBE3MpHnSBtnlOtK4s9k5E0nJxAxqpSEUX2FU
NjoBIg2PD1+qYsWpVwyI0zerrld67k4znT/sSWu2OqZUV4CNBHsLsp5oqNNPpTia
jtgr5dD7GY1lGvjZ8eI4XtlDKtFtyfDWO9bKUlEQXHV1zuItMnA=
=C7AU
-----END PGP SIGNATURE-----

--PpuiUmP00u1KRYlS--