Published on: 2022-12-06T05:03:56+00:00
The bitcoin-dev community is currently discussing the use of a different nVersion to signal full-rbf in multi-party transactions such as coinjoin and contracting protocols like Lightning. Originally, this option was proposed to address a DoS vector affecting these use-cases. However, alternative solutions have been developed that also solve this issue but have their own trade-offs and privacy concerns.One of the proposals suggests that multi-party protocols use a different nVersion to signal full-rbf in their transactions. However, this approach negatively impacts privacy by making it easier for bad actors to deanonymize transactions. Single-party wallets are discouraged from using this option due to complaints from services like Bitrefill about RBF transactions. Designing a protocol without harming privacy seems impossible, as it would require zeroconf services to determine whether a txout has opted into full-rbf while preventing Chainalysis services from doing the same.The decision on how to balance the interests of centralized services and other users regarding privacy tradeoffs needs to be made by the community. Another v3 proposal also presents similar privacy issues, but there may be potential ways to avoid this impact through mempool design.Antoine's message addresses Daniel, who operates a zero-conf risk analysis business. Antoine expresses concerns about the deployment of fullrbf, which could lower the cost of double-spend attacks and increase risk exposure for users. He questions the statistics on the 1.5M transactions per month received by Daniel's business, specifically asking how many are Bitcoin-only transactions excluded from zeroconf due to factors like RBF, long-chain of unconfirmed ancestors, or high value. Antoine also asks about the average feerate.Antoine shares his personal position on fullrbf deployment, as expressed in #26525, stating that there is still no consensus on deploying or removing it. He believes that before considering removing the current option from Bitcoin Core, the community needs to determine the qualification of enough economic flows at risk and the presence of a significant loss in miners' income. He also raises the question of whether the Bitcoin protocol development community should limit user choice in policy settings to preserve mining income and established use-case stability.The original technical motivation for the fullrbf option was to address a DoS vector affecting multi-party transactions like coinjoin and contracting protocols like Lightning. However, alternative solutions have been proposed since then, each with their own trade-offs and conceptual issues. Antoine provides links to previous discussions on these matters, emphasizing the potential risks associated with fullrbf deployment and the importance of balancing user choice with preserving mining income and established use-case stability.
Updated on: 2023-08-02T08:34:50.355400+00:00