[Opt-in full-RBF] Zero-conf apps in immediate danger



Summary:

Daniel Lipshitz, CEO of GAP600, shared statistics about the significance of the zero-conf use case. GAP600 guarantees zero confirmed Bitcoin and other crypto transactions, with BTC being a primary part of their business. Their guarantee enables their customers to recognize zero-conf deposits. They reimburse their clients the value of the transaction should they get it wrong and a transaction they confirmed gets double-spent. As of the end of November 2022, GAP600 has processed approximately 15 million transactions with a cumulative value of $2.3 billion USD. They currently see approximately 1.5 million transactions queried per month.Lipshitz addressed the potential impact on the capacity to accept zero-confs on mainnet should full RBF become default-enabled and significantly adopted. He stated that this use case would be forced to move to a different chain, with Lightning being just another option. He urged consideration of the major risk placed on this significant market share when deciding to make this feature default-enabled and encouraging full adoption.Antoine Riard responded to Lipshitz's concerns, noting that GAP600 operates a zero-conf risk analysis business, which is integrated and leveraged by payment processors/liquidity providers and merchants. A deployment of full-RBF by enough full-node operators and a subset of the mining hashrate would lower the cost of double-spend attack by lambda users, therefore increasing the risk exposure of GAP600's users. This increased risk exposure could lead to an alteration of the acceptance of incoming zero-conf transactions, similar to Bitrefill's reasoning earlier in the year. Riard also questioned how many of those 1.5 million transactions per month were Bitcoin-only, excluded from zero-conf due to factors like RBF, long-chain of unconfirmed ancestors, or too high-value, and what has been the average feerate.Regarding full-RBF, Riard expressed his personal position on deploying full-RBF, stating that the community still does not have conceptual consensus on deploying or removing it. He thinks there are open questions about whether they should restrain user choice in policy settings in the name of preserving mining income and established use-case stability. Riard referred to the original technical motivation of this option and the wider smoother deployment was to address a DoS vector affecting another class of use-case: multi-party transactions like coinjoin and contracting protocols like Lightning. All of them expect to generate economic flows and corresponding mining income. Since then, alternative paths to solve this DoS vector have been devised, all with their own trade-offs and conceptual issues.


Updated on: 2023-06-16T00:53:47.444394+00:00