A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent



Summary:

The email discusses the benefits and drawbacks of a sponsor-like mechanism. The author believes that the API of such a mechanism is close to ideal, as it is compatible with non-malleable transactions, has zero overhead if fees are accurately estimated, is watchtower friendly, and requires minimal protocol awareness. Additionally, it is friendly with most mempool eviction policies, can work to atomically bump multiple transactions, and can be bumped cooperatively by multiple sponsors without coordination. There is also zero rebroadcast overhead and it is compatible with change being in cold storage. However, the main drawback is that it is less efficient in terms of chain space, as an additional transaction is made. Nonetheless, the author thinks that the API benefits outweigh this concern, especially if the sponsorship efficiency hypothesis holds true. This hypothesis suggests that most transactions will not require sponsors, so the savings from not needing to preplan bumping mechanisms overall will be more efficient. An important point raised is that the number of contracts closed cooperatively versus non-cooperatively on the long-term will ultimately determine the sponsorship chain/fee overhead. For example, even if emergency closure for security reasons is rare in practice, significant non-cooperative closing may still occur when counterparties cannot agree on the economic opportunity of pursuing the contract or not. Thus, the next step of the discussion would be to come up with a consistent simulation against which all proposals can be scored.


Updated on: 2023-06-14T22:15:42.613237+00:00