Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
On Thu, Dec 21, 2023 at 09:59:04PM +, 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
Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
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 a écrit : > On Fri, Dec 15, 2023 at 10:29:22PM +, 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
Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
On Fri, Dec 15, 2023 at 10:29:22PM +, 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
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
