A fee-bumping model

Summary:

The article focuses on the challenges of enforcing offchain contracts on the Bitcoin blockchain. The author proposes a solution called "Revault," which involves a multi-signature setup where funds are spread across several keys and transactions require multiple signatures to be spent. The post delves into the specific challenges of fee bumping in this context, as well as the importance of being able to enforce contracts on-chain before their timelocks expire.To address these issues, the authors suggest a dynamic fee estimation model that takes into account transaction dependencies and aims to minimize the cost of enforcement. They provide historical fee estimates data from Statoshi and Txstats, as well as chain data from Riccardo Casatta's `blocks_iterator`. The code for their proposed solution can be found on Github under the section "Fee bumping. "The topic of fee-bumping is critical for many protocols built on Bitcoin, as they require the confirmation of a transaction before the expiration of a timelock. Revault is no exception, and the delegation process is of particular interest in this study. Participants in the large multisig create two transactions, the Unvault and the Cancel, which are used to spend a deposit UTxO. Watchtowers can enforce spending policies by having the Cancel transaction confirmed before the expiration of the timelock.For Lightning, the management of the UTxO pool is simpler, but choosing a threat model is harder. In the Lightning security game, there are at least four types of players moves and incentives: your node, your channel counterparties, the miners, and the crowd of bitcoin users. Implications for LN fee-bumping strategy and the economic competitiveness of LN service providers and average users are discussed.Unlimited partitions can be done in Revault by mutating the ANYONECANPAY-input of the Cancel. However, it's believed that you would only be able to do so marginally due to using Miniscript. Distributed monitors deployed by few L1 merchants accepting 0-conf to detect naive double-spend can reliably observe such partitions.The article proposes a reserve feerate to limit the maximum feerate above which you cannot enforce all your contracts on-chain at the same time. The author also discusses the UTxO pool layout, bumping, and re-bumping. Finally, the paper presents their study and observations regarding different metrics such as time at risk.The author notes the potential need for an insurance market given the lack of a clear answer to what constitutes a reasonable feerate for on-chain enforcement. They also discuss the idea of a fee-bumping "shared cache," which is similar to `update_fee` but with the property that you have the channel liquidity not depend on the onchain feerate. The discussion moves on to fractional fee-bumping reserves being more realistic to expect in the LN network, and higher levels of reserve aren't worth the opportunity cost. In case of massive mempool congestion, one might try to front-run the crowd of bitcoin users relying on block connections for fee-bumping. A cryptography-based scheme around this type of insurance services would be the best way out.

Updated on: 2023-06-15T03:12:02.677107+00:00