Author: Billy Tetrud 2021-06-26 16:13:23
Published on: 2021-06-26T16:13:23+00:00
The Bitcoin community is currently discussing whether to continue supporting 0-conf payments despite the potential security risks associated with double-spending. While Lightning Network (LN) provides faster payment mechanisms, some service providers still offer zero-conf channels where payments can be made instantly. However, it is challenging to determine how much Bitcoin traffic is tied to 0-conf, as many service providers are reluctant to share this information for business reasons.The proposal to deprecate opt-in RBF in favor of full-RBF as Bitcoin Core's default replacement policy in version 24.0 has been deemed highly controversial a few years ago, but ongoing changes in the Bitcoin ecosystem have motivated this proposal. Several approaches have been suggested to enhance 0-conf security, including proactive security models like double-spend monitoring and receiver-side fee-topping with package relay and reactive security models like economic-reputation-based compensations.The presence of opt-in RBF as a DoS vector against multi-party funded transactions and mempool partitions vector has been identified as a risk to robust second-layer protocol deployment. The conversation around preserving the interests of 0-conf users while enabling upcoming interests of fancy L2s to flourish is a good one to have. If there is agreement on switching to full-RBF, it could be deferred to version 0.25 or 0.26.The discussion also references "turbo-channels" and suggests that mobile nodes may become normalized, highlighting the importance of addressing this issue. To fix zero-conf security in the Lightning Network ecosystem, the context provided includes links to a lightning-dev discussion and a GitHub pull request. Additionally, the bitcoin-dev mailing list is mentioned as a resource for further information on the topic.
Updated on: 2023-06-14T22:36:49.252577+00:00