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
[bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
TL;DR = * All known Lightning channel and factory protocols are susceptible to forced expiration spam attacks, in which an attacker floods the blockchain with transactions in order to prevent honest users from putting their transactions onchain before timelocks expire. * Feerate-Dependent Timelocks (FDTs) are timelocks that automatically extend when blockchain feerates spike. - In the normal case, there's no spike in feerates and thus no tradeoff between capital efficiency and safety. - If a dishonest user attempts a forced expiration spam attack, feerates increase and FDTs are extended, thus penalizing the attacker by keeping their capital timelocked for longer. - FDTs are tunable and can be made to be highly resistant to attacks from dishonest miners. * Of separate interest, an exact analysis of the risk of double spend attacks is presented that corrects an error in the original Bitcoin whitepaper. Overview Because the Lightning protocol relies on timelocks to establish the correct channel state, Lightning users could lose their funds if they're unable to put their transactions onchain quickly enough. The original Lightning paper [1] states that "[f]orced expiration of many transactions may be the greatest systemic risk when using the Lightning Network" and it uses the term "forced expiration spam" for an attack in which a malicious party "creates many channels and forces them all to expire at once", thus allowing timelocked transactions to become valid. That paper also says that the creation of a credible threat against "spamming the blockchain to encourage transactions to timeout" is "imperative" [1]. Channel factories that create multiple Lightning channels with a single onchain transaction [2][3][4][5] increase this risk in two ways. First, factories allow more channels to be created, thus increasing the potential for many channels to require onchain transactions at the same time. Second, channel factories themselves use timelocks, and thus are vulnerable to a "forced expiration spam" attack. In fact, the timelocks in Lightning channels and factories are risky even without an attack from a malicious party. Blockchain congestion is highly variable and new applications (such as ordinals) can cause a sudden spike in congestion at any time. As a result, timelocks that were set when congestion was low can be too short when congestion spikes. Even worse, a spike in congestion could be self-reinforcing if it causes malicious parties to attack opportunistically and honest parties to put their channels onchain due to the heightened risk. One way to reduce the risk of a forced expiration spam attack is to use longer timelocks that give honest users more time to put their transactions onchain. However, long timelocks limit the ability to dynamically reassign the channel's (or factory's) funds, thus creating a tradeoff between capital efficiency and safety [6]. While long timelocks could maintain safety for small numbers of channels, supporting billions (or tens of billions) of channels while maintaining safety is probably impossible [7]. Another way to reduce risk is to impose a penalty on an attacker. Some channel protocols, such as the original Lightning protocol [1], a version of the two-party eltoo protocol [8], the fully-factory-optimized protocol [9], and the tunable-penalty channel protocol [10] include such penalties. In addition, the tunable-penalty and single-commitment factory protocols [4] support penalties. However, as was noted in the original Lightning paper [1], penalties don't eliminate the risk of a forced expiration spam attack. Furthermore, existing penalty-based factory protocols [4] have limited scalability, as they depend on getting large numbers of casual users to coordinate and co-sign transactions [11][5]. In contrast, the timeout-tree protocol [5] scales via simple covenants (enabled by support for CheckTemplateVerify, AnyPrevOut, or a similar change to the Bitcoin consensus rules). As a result, a single timeout-tree can support millions of channels and one small transaction per block can fund timeout-trees with tens of billions of offchain channels [5]. However, timeout-trees don't support penalties, and like all other known factory protocols [2][3][4], timeout-trees rely on timelocks. Therefore, if the need to protect against forced expiration spam was already "imperative" for the original Lightning channel protocol [1], the use of scalable channel factories will make such protection indispensable. This post proposes a change to Bitcoin's consensus rules that allows the length of a timelock to depend on the feerate being charged for putting transactions onchain. Such Feerate-Dependent Timelocks (FDTs) can be used to make the above channel and factory protocols resistant to sudden spikes in blockchain congestion. In the normal case, when there's no spike in congestion, FDTs don't extend the lengths of
