Subject: [bitcoindev] Re: OP_Expire mempool behavior

From: Antoine Riard <[email-masked]>
Date: Sat, 16 Mar 2024 11:21:50 -0700 (PDT)

> > > nodes should require higher minimum relay fees for transactions close 
to
> > their expiration height to ensure we don’t waste bandwidth on 
transactions
> > that have no potential to be mined

I think this concern can be raised on _today_ LN second-stage transactions 
(HTLC-preimage / HTLC-timeout),
when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes will 
automatically go to broadcast an
on-chain HTLC-timeout transaction. Probabilistically, we're wasting 
bandwidth on transactions that _might_ have
lower odds to be mined.

> If you already have a need to make such transactions, you can argue that 
the
> marginal cost to also use up that bandwidth is low. But that's already 
the case
> with RBF: we allow any transaction to be replaced with RBF for a (by 
default)
> 1sat/vB additional cost to "pay for" the bandwidth of that replacement.
> OP_EXPIRE does not change this situation: you're still paying for an 
additional
> 1sat/vB cost over the replaced transaction, as eventually one of your
> replacements will get mined.

I think yes this is indeed more a replacement issue, nothing new introduced 
by OP_EXPIRE finality time-bounding semantics.
However, I think it's more an issue if we introduce things like altruistic 
re-broadcasting.
 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022188.html
 
Certainly, the re-broadcast could favor transactions with higher odds of 
being mined, which naively should match RBF rules.

And by the same way taking time to answer the open questions on this thread 
from the old mailing list:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022224.html

> Are you claiming that BIP157 doesn't work well? In my experience it does. 

I've not checked recently, though from research memory a while back the 
numbers of BIP157 services offering peers
was in the range of ~10 / 100.

One can check by collecting nVersions messages from peers with 
`NODE_COMPACT_FILTERS`.

> Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so 
mempool min fees are very consistent across nodes. I just checked four 
different long running > nodes I have access to, running a variety of 
Bitcoin Core versions on different platforms and very different places in 
the world, and their minfees all agree to well within 1%  > In fact, they 
agree on min fee much *more* closely than the size of their mempools (in 
terms of # of transactions). Which makes sense when you think about it, as 
the
> slope of the supply/demand curve is fairly flat right now.

See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated from 
diverging mempool min fees from the ground iirc.

> From the point of view of a single node, an attacker can not reuse a UTXO 
in a replacement cycling attack. The BIP125 rules, in particular rule #4, 
ensure that each
> replacement consumes liquidity because each replacement requires a higher 
fee, at least high enough to "pay for" the bandwidth of the replacement. An 
attacker trying to > use the same UTXO's to cycle out multiple victim 
transactions has to pay a higher fee for each victim cycled out. This is 
because at each step of the cycle, the attacker had > to broadcast a 
transaction with a higher fee than some other transaction.

This does not stay true with nVersion=3, where a package parent can be 
signed with a feerate
under min relay tx fee. See the second test attached in the initial full 
report email on replacement
cycling attacks, one can replace the child of the package and the parent is 
automatically evicted, 
without the "pay for" bandwidth of the replacement fully covered.

This is correct there is a minimal fee basis for each additional victim 
cycled out, while one can get
a very advantageous scaling effect by RC'ing the child txn.

> If I understand correctly, here you are talking about an attacker with 
connections to many different nodes at once, using the same UTXO(s) to do 
replacement cycling
> attacks against different victim transactions on many different nodes at 
once.

> There is no free lunch in this strategy. By using the same UTXO(s) 
against multiple victims,
> the attacker dramatically reduces the effectiveness of the attack because 
only a subset of nodes see each "side" of the attack.

The attacker assumptions is correct and relies on partitioning mempools. 
However, I disagree
on the reduction in attack effectiveness as traditional LN nodes have only 
one tx-relay edge access
to the tx-relay network (and LN nodes interfaces are a clusterfuck to do it 
correctly here).

> Suppose that Mallory is connected directly or indirectly Alice and Bob's 
nodes, and attempts to do a replacement cycling attack against both Alice 
and Bob with the same
> UTXO(s).

> Both Alice and Bob's victim transactions spend different UTXOs, so every 
node on the network can add both transactions to their mempool. When Alice 
and Bob
>  broadcast their victim transactions, their nodes will tell multiple 
peers about their respective transactions. Indeed, if alturistic 
rebroadcasting is to be relevant at all, nodes > other than Alice and Bob's 
*must* have learned about their transactions!

> Mallory on the other hand is creating divergent attack transactions that 
are mututally
> incompatible. When Mallory broadcasts those attack transactions, from the 
perspective of some nodes, Alice's victim transaction will be replaced out 
but not Bob's, and
> from the perspective of other nodes, the opposite.

I'm assuming Mallory is partitioning Alice and Bob's local mempool from the 
rest of the network
by using.2 distinct UTXOs. However their victim transactions won't 
propagate out of their local
mempools due to Mallory's  higher / higher feerate conflicting 
transactions. Mallory won't have to
paid the fan-out of 3.125 BTC of concurrent replacement, assuming the 
partitioning isolation from
the rest of the network is well-done.

> Indeed, from the perspective of roughly half of the alturistic 
rebroadcasting nodes, Alice's transaction was never cycled out, and the 
other half, Bob's was never cycled out!

> Even in this case where the attack only used the same UTXO for two 
targets, each victim transaction gets to roughly 50% of the mining nodes, 
making the attack
> ineffective. And the numbers for Mallory just keep getting worse as he 
targets more victims at once.

I think you can just use one UTXO for each RC target by broadcasting a 
transaction in the target local
mempool's conflicting constantly with the malicious replacement transaction.

>From my understanding, altruistic rebroadcasting only introduces the 
encumbrance on the attacker to
add 1 UTXO per-victim's local mempool. I believe it's small advance to 
mitigate replacement cycling attacks,
however a very cheap one given the marginal cost of a UTXO.

Best,
Antoine

Le mercredi 13 mars 2024 à 05:10:40 UTC, Peter Todd a écrit :

> I got a question re: the following comment on delvingbitcoin with regard to
> OP_Expire:
>
> > > nodes should require higher minimum relay fees for transactions close 
> to
> > > their expiration height to ensure we don’t waste bandwidth on 
> transactions
> > > that have no potential to be mined
> >
> > This seems insufficient to solve the problem, unless the premium is so 
> high
> > that it virtually guarantees that the transaction will be mined before it
> > expires. However, if the feerate were that high, wouldn’t OP_EXPIRE 
> simply
> > waste blockspace? If however the feerate of the transaction is merely
> > competitive, the presence of OP_EXPIRE creates a bandwidth-wasting 
> vector: an
> > attacker would submit e.g. OP_EXPIRE transactions at the bottom of the 
> top
> > block and push them out of the top block with further OP_EXPIRE 
> transactions.
> > This way the attacker could issue a constant stream of transactions, but
> > never pay for more than a couple barely sliding in at the bottom of the
> > block.
> -https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8
>
> This "bandwidth-wasting vector" requires the attacker to create actual
> fee-paying transactions, with a fee-rate sufficiently high to get mined in 
> the
> next block or so. This of course is very expensive by itself.
>
> If you already have a need to make such transactions, you can argue that 
> the
> marginal cost to also use up that bandwidth is low. But that's already the 
> case
> with RBF: we allow any transaction to be replaced with RBF for a (by 
> default)
> 1sat/vB additional cost to "pay for" the bandwidth of that replacement.
> OP_EXPIRE does not change this situation: you're still paying for an 
> additional
> 1sat/vB cost over the replaced transaction, as eventually one of your
> replacements will get mined.
>
> -- 
> 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 [email-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/42adedc4-f3b0-4214-8f0d-2a27a3916fcen%40googlegroups.com.