* [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
@ 2023-12-09 10:08 Peter Todd
2023-12-15 22:29 ` Antoine Riard
0 siblings, 1 reply; 5+ messages in thread
From: Peter Todd @ 2023-12-09 10:08 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4605 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
2023-12-09 10:08 [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation Peter Todd
@ 2023-12-15 22:29 ` Antoine Riard
2023-12-17 10:57 ` Peter Todd
0 siblings, 1 reply; 5+ messages in thread
From: Antoine Riard @ 2023-12-15 22:29 UTC (permalink / raw)
To: Peter Todd, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7638 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 9049 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
2023-12-15 22:29 ` Antoine Riard
@ 2023-12-17 10:57 ` Peter Todd
2023-12-21 21:59 ` Antoine Riard
0 siblings, 1 reply; 5+ messages in thread
From: Peter Todd @ 2023-12-17 10:57 UTC (permalink / raw)
To: Antoine Riard; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4556 bytes --]
On Fri, Dec 15, 2023 at 10:29:22PM +0000, Antoine Riard wrote:
> 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.
Obviously a local replacement cache is a possibility. The whole point of my
email is to show that a local replacement cache isn't necessarily needed, as
any alturistic party can implement that cache for all nodes.
> 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.
1) That is trivially avoided by only broadcasting txs that meet the local
mempool min fee, plus some buffer. There's no point to broadcasting txs that
aren't going to get mined any time soon.
2) BIP-133 feefilter avoids this as well, as Bitcoin Core uses the feefilter
P2P message to tell peers not to send transactions below a threshold fee rate.
https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
> 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.
Did you actually read my email? I worked out the budget required in a
reasonable worst case scenario:
> > 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.
Here, we're talking about an attacker that has financial resources high enough
to possibly do 51% attacks. And even in that scenario, storing the entire
replacement database in RAM costs under $1000
The reality is such an attack would probably be limited by P2P bandwidth, not
financial resources, as 2MB/s of tx traffic would likely leave mempools in an
somewhat inconsistent state across the network due to bandwidth limitations.
And that is *regardless* of whether or not anyone implements alturistic tx
broadcasting.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
2023-12-17 10:57 ` Peter Todd
@ 2023-12-21 21:59 ` Antoine Riard
2023-12-22 14:01 ` Peter Todd
0 siblings, 1 reply; 5+ messages in thread
From: Antoine Riard @ 2023-12-21 21:59 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 8404 bytes --]
Hi Peter,
> Obviously a local replacement cache is a possibility. The whole point of
my
> email is to show that a local replacement cache isn't necessarily needed,
as
> any alturistic party can implement that cache for all nodes.
Sure, note as soon as you start to introduce an altruistic party
rebroadcasting for everyone in the network, we're talking about a different
security model for time-sensitive second-layers. And unfortunately, one can
expect the same dynamics we're seeing with BIP157 filter servers, a handful
of altruistic nodes for a large swarm of clients.
> 1) That is trivially avoided by only broadcasting txs that meet the local
> mempool min fee, plus some buffer. There's no point to broadcasting txs
that
> aren't going to get mined any time soon.
>
> 2) BIP-133 feefilter avoids this as well, as Bitcoin Core uses the
feefilter
> P2P message to tell peers not to send transactions below a threshold fee
rate.
>
> https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
I know we can introduce BIP-133 style of filtering here only the top % of
the block template is altruistically rebroadcast. I still think this is an
open question how a second-layer node would discover the "global" mempool
min fee, and note an adversary might inflate the top % of block template to
prevent rebroadcast of malicious HTLC-preimage.
> Did you actually read my email? I worked out the budget required in a
> reasonable worst case scenario:
Yes. I think my uncertainty lies in the fact that an adversary can
rebroadcast _multiple_ times the same UTXO amount under different txids,
occupying all your altruistic bandwidth. Your economic estimation makes an
assumption per-block (i.e 3.125 BTC / 10 minutes). Where it might be
pernicious is that an adversary should be able to reuse those 3.125 BTC of
value for each inter-block time.
Of course, you can introduce an additional rate-limitation per-UTXO, though
I think this is very unsure how this rate-limit would not introduce a new
pinning vector for "honest" counterparty transaction.
> Here, we're talking about an attacker that has financial resources high
enough
> to possibly do 51% attacks. And even in that scenario, storing the entire
> replacement database in RAM costs under $1000
> The reality is such an attack would probably be limited by P2P bandwidth,
not
> financial resources, as 2MB/s of tx traffic would likely leave mempools
in an
> somewhat inconsistent state across the network due to bandwidth
limitations.
> And that is *regardless* of whether or not anyone implements alturistic tx
> broadcasting.
Sure, I think we considered bandwidth limitations in the design of the
package relay. Though see my point above, the real difficulty in your
proposed design sounds to me in the ability to reuse the same UTXO
liquidity for an unbounded number of concurrent replacement transactions
exhausting all the altruistic bandwidth.
One can just use a 0.1 BTC UTXO and just fan-out 3.125 BTC of concurrent
replacement transactions from then. So I don't think the assumed adversary
financial resources are accurate.
I think the best long-term way to fix replacement cycling is still more in
the direction of things like:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022191.html
With the additional constraint of removing package malleability, where all
the feerate is coming from package self-contained fee-bumping reserves
UTXOs.
Best,
Antoine
Le dim. 17 déc. 2023 à 10:57, Peter Todd <pete@petertodd•org> a écrit :
> On Fri, Dec 15, 2023 at 10:29:22PM +0000, Antoine Riard wrote:
> > 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.
>
> Obviously a local replacement cache is a possibility. The whole point of my
> email is to show that a local replacement cache isn't necessarily needed,
> as
> any alturistic party can implement that cache for all nodes.
>
> > 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.
>
> 1) That is trivially avoided by only broadcasting txs that meet the local
> mempool min fee, plus some buffer. There's no point to broadcasting txs
> that
> aren't going to get mined any time soon.
>
> 2) BIP-133 feefilter avoids this as well, as Bitcoin Core uses the
> feefilter
> P2P message to tell peers not to send transactions below a threshold fee
> rate.
>
> https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
>
> > 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.
>
> Did you actually read my email? I worked out the budget required in a
> reasonable worst case scenario:
>
> > > 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.
>
> Here, we're talking about an attacker that has financial resources high
> enough
> to possibly do 51% attacks. And even in that scenario, storing the entire
> replacement database in RAM costs under $1000
>
> The reality is such an attack would probably be limited by P2P bandwidth,
> not
> financial resources, as 2MB/s of tx traffic would likely leave mempools in
> an
> somewhat inconsistent state across the network due to bandwidth
> limitations.
> And that is *regardless* of whether or not anyone implements alturistic tx
> broadcasting.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
[-- Attachment #2: Type: text/html, Size: 10179 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
2023-12-21 21:59 ` Antoine Riard
@ 2023-12-22 14:01 ` Peter Todd
0 siblings, 0 replies; 5+ messages in thread
From: Peter Todd @ 2023-12-22 14:01 UTC (permalink / raw)
To: Antoine Riard; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6621 bytes --]
On Thu, Dec 21, 2023 at 09:59:04PM +0000, Antoine Riard wrote:
> Hi Peter,
>
> > Obviously a local replacement cache is a possibility. The whole point of
> my
> > email is to show that a local replacement cache isn't necessarily needed,
> as
> > any alturistic party can implement that cache for all nodes.
>
> Sure, note as soon as you start to introduce an altruistic party
> rebroadcasting for everyone in the network, we're talking about a different
> security model for time-sensitive second-layers. And unfortunately, one can
> expect the same dynamics we're seeing with BIP157 filter servers, a handful
> of altruistic nodes for a large swarm of clients.
Are you claiming that BIP157 doesn't work well? In my experience it does.
Rebroadcasting is additive security, so the minimum number you need for the
functionality to work is just one.
> > 1) That is trivially avoided by only broadcasting txs that meet the local
> > mempool min fee, plus some buffer. There's no point to broadcasting txs
> that
> > aren't going to get mined any time soon.
> >
> > 2) BIP-133 feefilter avoids this as well, as Bitcoin Core uses the
> feefilter
> > P2P message to tell peers not to send transactions below a threshold fee
> rate.
> >
> > https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
>
> I know we can introduce BIP-133 style of filtering here only the top % of
> the block template is altruistically rebroadcast. I still think this is an
> open question how a second-layer node would discover the "global" mempool
> min fee, and note an adversary might inflate the top % of block template to
> prevent rebroadcast of malicious HTLC-preimage.
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.
> > Did you actually read my email? I worked out the budget required in a
> > reasonable worst case scenario:
>
> Yes. I think my uncertainty lies in the fact that an adversary can
> rebroadcast _multiple_ times the same UTXO amount under different txids,
> occupying all your altruistic bandwidth. Your economic estimation makes an
> assumption per-block (i.e 3.125 BTC / 10 minutes). Where it might be
> pernicious is that an adversary should be able to reuse those 3.125 BTC of
> value for each inter-block time.
>
> Of course, you can introduce an additional rate-limitation per-UTXO, though
> I think this is very unsure how this rate-limit would not introduce a new
> pinning vector for "honest" counterparty transaction.
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.
> > Here, we're talking about an attacker that has financial resources high
> enough
> > to possibly do 51% attacks. And even in that scenario, storing the entire
> > replacement database in RAM costs under $1000
>
> > The reality is such an attack would probably be limited by P2P bandwidth,
> not
> > financial resources, as 2MB/s of tx traffic would likely leave mempools
> in an
> > somewhat inconsistent state across the network due to bandwidth
> limitations.
> > And that is *regardless* of whether or not anyone implements alturistic tx
> > broadcasting.
>
> Sure, I think we considered bandwidth limitations in the design of the
> package relay. Though see my point above, the real difficulty in your
> proposed design sounds to me in the ability to reuse the same UTXO
> liquidity for an unbounded number of concurrent replacement transactions
> exhausting all the altruistic bandwidth.
>
> One can just use a 0.1 BTC UTXO and just fan-out 3.125 BTC of concurrent
> replacement transactions from then. So I don't think the assumed adversary
> financial resources are accurate.
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.
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.
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-12-22 14:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-09 10:08 [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation Peter Todd
2023-12-15 22:29 ` Antoine Riard
2023-12-17 10:57 ` Peter Todd
2023-12-21 21:59 ` Antoine Riard
2023-12-22 14:01 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox