Published on: 2021-05-18T13:10:12+00:00
Implementing Replace-By-Fee (RBF) in financial code presents challenges in exception handling and testing reorgs. Thorough testing is necessary, but code with many branches due to handling exceptions is difficult to cover completely. C-lightning supports RBF, but potential edge cases may cause mishandling of replaced transactions and loss of onchain funds. The combination of RBF and Child-Pays-for-Parent (CPFP) has yet to be explored fully, with potential use cases like the maker-taker model requiring careful exception handling.In a discussion on Bitcoin Stack Exchange, Jeremy and ZmnSCPxj share their thoughts on fee estimation. The recent CVE related to RBF by Antoine Riard and the differences between RBF implementation in Bitcoin Core and btcd are also discussed. However, the reasoning behind not implementing inherited signalling in Bitcoin Core remains unclear.In an email exchange, ZmnSCPxj and Prayank discuss engineering issues related to a full RBF wallet. While ZmnSCPxj believes a true full-RBF wallet should be the goal, he acknowledges the engineering challenges. He explains the process of a true full-RBF wallet and warns about race conditions when miners find new blocks while fees are being bumped. The wallet needs to track "pending spends" and correlate them with actual transactions. ZmnSCPxj also notes that spending unconfirmed inputs may not be safe due to conflicting transactions. Engineering issues pose significant challenges in achieving a true full-RBF wallet.The author of the message agrees that a "true" full-RBF wallet should be the goal for every on-chain wallet but notes the difficulties in achieving this. They explain how some wallets handle unconfirmed inputs and the simplification of database design. To achieve a true full-RBF wallet, the wallet must keep track of pending spends and correlate them with actual transactions. The author admits they have not considered all factors related to this issue.Jeremy Rubin shares a link with Prayank explaining the concept of a "fee-only" wallet. This feature allows users to arrange fee bumps using a separate wallet without disturbing on-chain dependents. It can be cheaper than RBF since users are not subject to the feerate improvement rule. Rubin suggests creating a market via LN for transaction inclusion by a particular date. Prayank raises concerns about different estimations used in wallets and proposes a three-step approach: showing mempool stats, leaving the fee rate decision to the user, and using RBF algorithms for automated bidding.In an email exchange, Jeremy Rubin shares a post on Bitcoin-dev related to background services. He highlights the potential of a separate fee-only wallet for arranging fee bumps without disturbing on-chain dependents. He suggests it could be cheaper than RBF and discusses the idea of creating a market for transaction inclusion. Prayank discusses different fee estimations and suggests sharing mempool stats and allowing users to decide the fee rate. He proposes using RBF algorithms and wonders if the proposed approach would work offline.The writer begins with personal well-being and recovery from COVID-19 before discussing Bitcoin transactions and fee estimations. They question the use of different estimations and propose showing mempool stats and allowing users to decide on the fee rate. They compare this to estimating buy orders in the BTCUSD orderbook. The writer finds current estimations misleading and suggests a three-step approach, including RBF algorithms for automated bidding. They seek input on the proposed approach and provide an example of replacing transactions with different fee rates even when offline.
Updated on: 2023-08-02T03:43:36.516184+00:00