Published on: 2022-11-02T15:00:47+00:00
The impact of rule #3 and rule #5 on coinjoin scenarios is discussed in the conversation. Despite the implementation of fullrbf-everywhere and V3, pinning can still be an issue. Rule #5 violations are contained to coinjoins with around 50 peers, but there is no technical reason for this rule to exist other than being a conservative DoS limit. Exploiting these rules requires money, and while their existence may not be guaranteed, they do currently affect operations. Attackers have more at stake and can be booted from the protocol if they pay the price and get mined.In an email exchange, Greg Sanders highlights that pinning remains an issue in coinjoin scenarios despite fullrbf-everywhere and V3. Adversaries can double-spend their coins either to full package weight or give 24 descendants, resulting in paying more or being excluded from RBFing if there are four or more adversaries violating rule #5. Narrowing the policy to mark transaction outputs as opt-in to V3 can restrict rule #5 violations to coinjoins with approximately 50 peers. However, the existence of rule #5 has no concrete technical justification and simply serves as a conservative DoS limit. It is uncertain whether these rules will continue to exist, but their exploitation incurs costs.On the bitcoin-dev mailing list, Antoine Riard proposes using zeroconf as a solution to address multi-party funding pinning. However, Peter Todd opposes this idea, arguing that zeroconf is a marginal use case with potential privacy trade-offs and engineering costs. He suggests adopting full-RBF instead to eliminate the privacy harm caused by opt-in-RBF. Greg Maxwell adds in a subsequent email that even with fullrbf-everywhere and V3, pinning via rule #3 and rule #5 remains an issue in coinjoin scenarios. Each adversary in a coinjoin can double-spend their coin, leading to paying more or being excluded from RBFing if there are four or more adversaries violating rule #5. While narrowing the policy to opt-in V3 marking is interesting, double-spending counterparties can still cause pain per peer through rule #3. Rule #5 violations, however, are contained within coinjoins with approximately 50 peers. The exploration of this approach is speculative but worth considering.Antoine Riard proposes an alternative solution to address pinning in multi-party collaborative flows by adopting a zeroconf-like mechanism. However, Peter Todd strongly disagrees, stating that incurring engineering costs and compromising privacy for a marginal use case like zeroconf is unreasonable. He suggests moving towards full-RBF to undo the privacy cost of opt-in-RBF. He also notes that achieving zeroconf will become even harder due to diminishing mempool consistency in the future. The only supporters of zeroconf are Bitrefill and Muun, with the latter working to eliminate its vulnerability to it. Attempts to secure zeroconf have involved sybil attacks against the network to measure transaction propagation.Antoine Riard proposes a new policy to address the issue of low-cost and high-success DoS vector in multi-party funding flows. The problem arises when participants combining inputs lack control or visibility over potential double-spends by other participants. Antoine suggests marking all coins' nVersion fields as opting for fullrbf to work around this issue for contracting protocols wallets. However, this policy marking becomes a protocol fingerprint leak for observers of transaction logs. In the long term, assuming all wallets will be Lightning wallets, this privacy issue could lead to most wallets signaling RBF for their spends, making them incompatible with zeroconf services and gradually outlawing them. Antoine sees this as an alternative way forward, allowing users to decide with their coins instead of miners enforcing the policy.The challenge of pinning contracting protocols funding flows with opt-out double-spends can be addressed by implementing an opt-in Full-Replace-by-Fee Spent-nVersion Signaling policy. This addresses the low-cost and high-success DoS vector in multi-party collaborative flows, where a single input can harm the remaining inputs or engage in MEV attacks. The proposed solution involves considering a confirmed transaction as opting-in for replacement if the last bit of the nVersion field is set. This protects participants in multi-party flows from pinning due to opt-out double-spends. However, there are engineering challenges related to accessing the spent nVersion fields in mempool logic. For contracting protocols wallets, marking all coins' nVersion fields as opting for fullrbf is a better approach if they don't know which coins will be used in a collaborative flow. However, this policy marking becomes a protocol fingerprint leak. Zeroconf operators can inspect the ancestors' nVersion fields of receiving transactions to identify replaceable transactions. In the long term, the efficiency of this new policy enforcement relies on relay paths and support at the miner mempools. Incentive alignment with hashrate is crucial for transaction-relay rules.
Updated on: 2023-08-02T08:21:36.331219+00:00