Author: Jeremy Rubin 2022-03-13 02:33:48
Published on: 2022-03-13T02:33:48+00:00
In an email exchange, Jeremy Rubin shares his thoughts on using transaction sponsors as a form of covenant for fee bumping. He notes that while transaction sponsorships could be used as a smart contracting primitive, the main priority is to use them for fee bumping. Jeremy emphasizes the efficiency of pre-committed levels and fancier covenants, as well as the capital efficiency of sponsors. Additionally, he highlights how sponsorships can help with protocol design concerns and RBF pinning issues.In the latter half of the email, Jeremy responds to darosior's proposed soft fork to fix dynamic fee bumping and suggests using a covenant-based approach instead. He provides a concrete example of designing such a covenant for a vault wallet software with five participants. The covenant would commit to the revocation transaction with increasing feerate and relative timelock, enabling fee adaptation to the block space market and anti-fee sniping protection.Antoine Riard has proposed a new method for fee bumping transactions in Bitcoin. The approach involves adding a single input and output to a Taproot transaction, which costs 520 weight units or 105 virtual bytes, assuming all inputs and outputs have already been included. This method allows for more granularity in fee bumps at a cost of only 8 more vbytes each. However, it is not applicable for bumping the first transaction of a chain, such as in HTLC transactions in Lightning. To work around this limitation, a different covenant per participant behind a signature check is necessary. This requires funds to already be in the contract to pay for the unilateral close. While less optimal and usable than CPFP or adding a pair of input/output, it is still more efficient for many use cases.
Updated on: 2023-06-15T18:13:55.444977+00:00