Published on: 2022-03-21T12:06:54+00:00
The email conversation between Antoine and ZmnSCPxj revolves around the use of a signature challenge for ensuring the uptime of hot contracts. However, they acknowledge that this method has drawbacks, such as the need to presign multiple versions of a transaction with varying feerates and the issue of third-party trust. To address these concerns, ZmnSCPxj suggests using a DLC (Discreet Log Contract) oracle, which would provide a set of points corresponding to different feerate ranges. The oracle would commit to publishing the scalar of one of those points at a future block height. Adaptor signatures would be created for each feerate version, and multiple watchtowers would be sent these signatures to prevent any single watchtower from publishing the highest-feerate version. Despite the advantages of this approach, there are still limitations, including third-party trust, time-bound DLCs, and the inability to invoke the oracle at any time for hot dynamic protocols.In another part of the conversation, Antoine proposes using covenants for fee bumping in Bitcoin contracts, although this would require a soft fork. He explains that covenant-based fee bumping has appealing properties, but finding a similar solution for other protocols has proven challenging. Antoine suggests attaching an increasing relative timelock to each leaf as the committed revocation feerate increases, allowing the feerate to adapt to the block space market. This approach also provides anti-fee sniping protection if the revocation transaction pays a significant amount of fees. However, paying fees from internal funds introduces the possibility of blackmail for multi-party contracts. Precommitted levels of fee bumping may work, but they come with substantial costs. Another option is using sponsors, which are similar to CPFP (Child Pays For Parent) and simplify the management of transaction chains in the mempool. Sponsors allow the allocation of funds later on but require pre-committing to all possible fee-bumped levels, preventing the dynamic addition of more fees.The conversation also highlights the differences between "cold contracts" (vaults) and "hot contracts" in terms of fee bumping. Timelocks are used for cold contracts to prevent the denial-of-service (DOS) attacks that can occur with high feerates. On the other hand, hot contracts utilize a signature challenge for the same purpose. However, this method has its flaws, as the lower the uptime risk, the higher the DOS risk. The use of sponsor-type solutions allows for the design of protocols without native fee payment methods, relying on external systems to achieve the desired effect. A recent post on the Bitcoin-dev mailing list proposes a timelocked-covenant approach to fee bumping for multi-party contracts like vaults, using shared funds to pay for fees and avoiding perverse incentives.Jeremy Rubin contributes to the discussion by suggesting transaction sponsors as a form of covenant for fee bumping. He emphasizes their efficiency, particularly pre-committed levels and fancier covenants, as well as their capital efficiency. Sponsors can also address protocol design concerns and RBF (Replace-By-Fee) pinning issues. In response to darosior's soft fork proposal for dynamic fee bumping, Jeremy suggests using a covenant-based approach instead. He provides an example of designing a covenant for a vault wallet software with five participants, committing to the revocation transaction with increasing feerate and relative timelock. This enables fee adaptation and anti-fee sniping protection.Antoine Riard introduces a new fee bumping method for Bitcoin transactions. It involves adding a single input and output to a Taproot transaction, costing 520 weight units or 105 virtual bytes. This method offers more granularity in fee bumps at a relatively low cost. However, it is not applicable for bumping the first transaction of a chain, such as HTLC transactions in Lightning. A workaround is to use a different covenant per participant behind a signature check, requiring funds to already be in the contract for unilateral close. While not as optimal and usable as other methods like CPFP or adding input/output pairs, it remains more efficient for many use cases.The conversation also touches on the idea of using a soft fork to fix dynamic fee bumping, given the complexity of designing with current primitives. One proposed solution is using covenants for fee bumping, which have attractive properties. An Unvaulting transaction triggers a timelock, after which a revocation transaction may be confirmed. With a covenant, one can commit to the revocation transaction instead of presigning it. Using a Taproot tree, different versions of the revocation transaction with increasing feerates can be committed to. However, careful consideration is needed to avoid wrecking miner incentives. Paying fees from shared funds eliminates the need for refilling and managing a fee-bumping wallet. Antoine Riard's covenant-based approach to fee bumping in multi-party vault setups is seen as a promising solution.
Updated on: 2023-08-02T05:55:38.338309+00:00