Covenants and feebumping

Summary:

Antoine proposed using covenants for fee bumping in Bitcoin contracts, which would require a soft fork. Covenant-based fee bumping has attractive properties, but finding a solution as neat for other protocols as it is for vaults has proven difficult.In a vault construction, a UTxO can only be spent by an Unvaulting transaction, and a revocation transaction must be confirmed before the expiration of the timelock triggered by the Unvault output. The revocation transaction needs fee bumping to be enforceable. With a covenant, you could commit to the revocation tx instead of presigning it. Using a Taproot tree, you could commit to different versions of it with increasing feerate, and any network monitor could RBF the revocation transaction if it doesn't confirm by spending using a leaf with a higher-feerate transaction being committed to.However, this leaves you with a possible internal blackmail for multi-party contracts. Instead, Antoine suggests attaching an increasing relative timelock to each leaf as the committed revocation feerate increases so that the feerate adapts to the block space market. Another nice property of this approach is the integrated anti-fee sniping protection if the revocation transaction pays a non-trivial amount of fees.Paying fees from internal funds offers benefits like no need to decide on an amount to be refilled and no need to bother the user to refill the fee-bumping wallet. However, it also opens up the possibility of blackmail for multi-party contracts. Precommitted levels of fee bumping might work, but they have substantial costs. Sponsors are similar to CPFP in usage and get rid of the complexity of managing transaction chains in the mempool. They allow the allocation of funds later on but require pre-committing to all the possible fee-bumped levels, preventing the dynamic addition of more fees eventually.For "cold contracts" (vaults), timelocks prevent the DOS of immediately using a large feerate, whereas for "hot contracts," a signature challenge is used to achieve the same. However, this method is imperfect since the lower the uptime risk, the higher the DOS risk. Sponsor-type things allow you to design protocols to not have any native way of paying for fees inside the actual "Transaction Intents" and use an external system to create the intended effect. A recent post on the bitcoin-dev mailing list proposed a timelocked-covenant approach to fee-bumping that could be used for multi-party contracts, such as vaults. The proposal suggests using shared funds to pay for fees, which prevents perverse incentives in contracts with more than two parties.The covenant to the revocation transaction with a feerate of i*79 sats/vb and a relative timelock of i-1 blocks is created in a Taproot tree of depth 7, which also adds a hashlock to prevent nuisance. The transaction size is smaller in this case than using other feebumping primitives and has a smaller footprint on the UTxO set.However, the timelocked-covenant approach only applies to bumping the first transaction of a chain, so it cannot be used for HTLC transactions in Lightning to bump the parent commitment tx. It can be worked around by having a different covenant per participant behind a signature check.This proposal provides a more optimal and usable solution to fee-bumping than CPFP or adding a pair of input/output for all the reasons mentioned above.

Updated on: 2023-06-15T18:15:16.520814+00:00