A fee-bumping model

Summary:

Gloria thanks Darosior and Ariard for their work on fee-bumping in contract security. She agrees that fee-bumping is often under-prioritized and considers their findings as strong motivation for some of the proposed changes to RBF they have been discussing.Gloria has questions about how fee-bumping would be used with the watchtower model in the delegation process. She wonders if all vault parties deposit to the vault and a refill/fee to the watchtower, and if there is a reward for the watchtower for a successful cancel or something else. She also asks if watchtowers tracking multiple vaults will batch multiple cancel transaction fee bumps.Gloria notes that Revault can afford to introduce malleability in the Cancel transaction since there is no second-stage transaction depending on its txid. They cannot use ANYONECANPAY|SINGLE since it would open a pinning vector. She asks if removing the BIP125#2 restriction would allow them to keep one big UTXO per vault and cut out the exact nValue needed to fee-bump cancel transactions without feeling like "burning" for the sake of fee-bumping.Regarding LN service providers, Gloria notes that overpayments bear on their operational costs, downgrading their economic competitiveness. For the average LN user, overpayment might price them out of a non-custodial deployment. Gloria agrees that this problem statement can be easily generalized to any offchain contract. Gloria discusses RBF pinning and suggests that introducing new consensus rules like committing to a maximum tx size or dropping the requirement on increasing absolute fees if the mempool is "full enough" could mitigate it. Finally, she asks about a fee-bumping "shared cache", a CPFP variation, where Alice and Bob commit collateral inputs to a separate UTXO from the main off-chain contract.The issue of fee-bumping is crucial for the security of many protocols building on Bitcoin, as they require the confirmation of a transaction before the expiration of a timelock at any point after the establishment of the contract. For delegated vaults, one must ensure the confirmation of a Cancel transaction in a configured number of blocks at any point to minimize overpayments and the UTxO set footprint. The first difficulty is to get to be able to unilaterally enforce your contract onchain.For Revault, the delegation process involves spending policies enforced by network monitors (watchtowers). Coins are received on a large multisig, and participants create two transactions - the Unvault and the Cancel. Participants regularly exchange the Cancel transaction signatures for each deposit, sharing the signatures with the watchtowers they operate. They then optionally sign the Unvault transaction and share the signatures with the small multisig participants who can use them to proceed with a spending. Watchtowers can enforce spending policies by having the Cancel transaction confirmed before the expiration of the timelock.For fee-bumping, one solution is to re-sign a high-feerate CPFP assuming interactivity. As the CPFP is counter-signed by everyone, the outputs can be CSV-1 encumbered to prevent pinnings. This solution can be easily generalized to more than 2 counterparties by using a multi-signature scheme. However, if the feerate is short due to fee spikes, and one needs to re-sign a higher-feerate CPFP, they are trusting their counterparty to interact.In Lightning, one would need to keep an equivalent amount of funds as the sum of all their channels balances sitting there unallocated "just in case," which is not reasonable. Lower fee-bumping reserve, higher liquidity deployed, in theory, higher routing fees.The Revault team also discusses how much funds a watchtower needs and the UTxO pool layout. They suggest fanning out the coins per-vault in advance, where the refiller can give an excess to pay for the fees of the fanout transaction. Finally, they discuss bumping and re-bumping, including when to fee-bump, and fallback to a blockchain-based estimation when estimates are unavailable.The email thread discusses the Real Revault approach and its use-case, primarily how to claim back coins from a contract after a deadline before taking part in it. One suggestion is only presigning part of the Unvault transactions so that it allows for delegating only part of the coins. The thread references several links, including a pull request on Github, a block iterator, and a website called Statoshi. There is also discussion around combinatorial coin selection and the potential for censorship.

Updated on: 2023-06-15T03:08:06.625675+00:00