Hi Peter,

> Altruistic third parties can partially mitigate replacement cycling(1)
attacks
> by simply rebroadcasting the replaced transactions once the replacement
cycle
> completes. Since the replaced transaction is in fact fully valid, and the
> "cost" of broadcasting it has been paid by the replacement transactions,
it can
> be rebroadcast by anyone at all, and will propagate in a similar way to
when it
> was initially propagated. Actually implementing this simply requires code
to be
> written to keep track of all replaced transactions, and detect
opportunities to
> rebroadcast transactions that have since become valid again. Since any
> interested third party can do this, the memory/disk space requirements of
> keeping track of these replacements aren't important; normal nodes can
continue
> to operate exactly as they have before.

I think there is an alternative to altruistic and periodic rebroadcasting
still solving replacement cycling at the transaction-relay level, namely
introducing a local replacement cache.

https://github.com/bitcoin/bitcoin/issues/28699

One would keep in bounded memory a list of all seen transactions, which
have entered our mempool at least once at current mempool min fee.

For the full-nodes which cannot afford extensive storage in face of
medium-liquidity capable attackers, could imagine replacement cache nodes
entering into periodic altruistic rebroadcast. This would introduce a
tiered hierarchy of full-nodes participating in transaction-relay. I think
such topology would be more frail in face of any sybil attack or scarce
inbound slots connections malicious squatting.

The altruistic rebroadcasting default rate could be also a source of
amplification attacks, where there is a discrepancy between the feerate of
the rebroadcast traffic and the current dynamic mempool min fee of the
majority of network mempools. As such wasting bandwidth for everyone.

Assuming some medium-liquidity or high-liquidity attackers might reveal any
mitigation as insufficient, as an unbounded number of replacement
transactions might be issued from a very limited number of UTXOs, all
concurrent spends. In the context of multi-party time-sensitive protocol,
the highest feerate spend of an "honest" counterparty might fall under the
lowest concurrent replacement spend of a malicious counterparty, occupying
all the additional replacement cache storage.

Best,
Antoine

Le sam. 9 déc. 2023 à 10:09, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> While this seems like a reasonably obvious idea, I couldn't find a previous
> example of it published on bitcoin-dev or elsewhere. So for the ability to
> cite
> it, I'll publish it now.
>
>
> # Summary
>
> Altruistic third parties can partially mitigate replacement cycling(1)
> attacks
> by simply rebroadcasting the replaced transactions once the replacement
> cycle
> completes. Since the replaced transaction is in fact fully valid, and the
> "cost" of broadcasting it has been paid by the replacement transactions,
> it can
> be rebroadcast by anyone at all, and will propagate in a similar way to
> when it
> was initially propagated. Actually implementing this simply requires code
> to be
> written to keep track of all replaced transactions, and detect
> opportunities to
> rebroadcast transactions that have since become valid again. Since any
> interested third party can do this, the memory/disk space requirements of
> keeping track of these replacements aren't important; normal nodes can
> continue
> to operate exactly as they have before.
>
>
> # Background
>
> To recall, a replacement cycling attack has three basic stages:
>
> 0) Target transaction tx0_a is broadcast, spending one or more outputs
> 1) Attacker broadcasts double-spend tx0_b, spending an additional output
>    under the attacker's control
> 2) Attacker broadcasts double-spend tx1, double-spending only the
> additional
>    input, resulting in the original input set not being spent
>
> Replacement cycling is a potential threat any time two or more parties
> have the
> ability to spend a single txout, and rendering that output _unspent_ is
> harmful. For example, replacement cycling is an attack on lightning HTLCs,
> because it can result in an HTLC pre-image not being observed by a party
> until
> after the HTLC expires. Similarly, replacement cycling is a potential
> attack on
> signatureless anchor outputs, as it can allow third parties to revoke a
> CPFP
> anchor spend, making the parent transaction(s) unminable.
>
>
> # Altruistic Rebroadcasting
>
> Bitcoin Core keeps no records of replaced transactions. Thus after the
> replacement cycling attack is complete, tx0_a has been entirely purged
> from a
> Bitcoin Core node's mempool, and all inputs to tx0_a are unspent. Thus it
> is
> just as valid to broadcast as before.
>
>
> ## Resources Required
>
> Let's suppose we have a DoS attacker who is constantly broadcasting
> replacement
> in an effort to overwhelm nodes performing altruistic rebroadcasting. The
> BIP-125 RBF rules require that a replacement transaction pay for the
> bandwidth
> used by the replacement. On Bitcoin Core, this defaults to 1sat/vByte.
> Assuming
> the attacking transactions are ~100% witness bytes, that is ~0.25sats/byte
> of
> relay bandwidth per peer.
>
> Suppose the DoS attacker has a budget equal to 50% of the total block
> reward.
> That means they can spend 3.125 BTC / 10 minutes, or 520,833sats/s.
>
>     520,833 sats/s
>     -------------- = 2,083,332 bytes / s
>     0.25 sats/byte
>
> Even in this absurd case, storing a one day worth of replacements would
> require
> just 172GB of storage. 256GB of RAM costs well under $1000 these days,
> making
> altruistic rebroadcasting a service that could be provided to the network
> for
> just a few thousand dollars worth of hardware even in this absurd case.
>
> It's notable that miners may in fact want to run replacement rebroadcasting
> software themselves, to ensure they are not missing any valid, profitable,
> transactions. In the context of a large mining pool, the additional cost
> over
> running a regular node may be affordable.
>
>
> ## Limitations
>
> At the moment, Bitcoin Core propagates transactions purely via INV
> announcements; there is no set reconciliation mechanism to synchronize
> mempools
> between peers. If an INV announcement is missed for some reason, it's quite
> possible that the transaction will be missed. Thus rebroadcasting may be
> defeated if the % of nodes who do *not* have the transaction at the time of
> rebroadcast is below the percolation threshold. Indeed, with good timing
> and a
> sybil attack, an attacker may be able to deliberately trigger this
> condition.
>
> Improvements like the Transaction Announcements Reconciliation(2) BIP may
> be
> able to mitigate this issue, by ensuring that regardless of the timing of
> replacements, the rebroadcast transaction eventually reaches all nodes via
> the
> reconciliation process.
>
>
> # References
>
> 1)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021999.html
> 2)
> https://github.com/naumenkogs/bips/blob/bip_0330_updates/bip-0330.mediawiki
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>