Published on: 2020-09-24T04:22:56+00:00
The email thread discusses a proposed change to Bitcoin's transaction relay rules that introduces an "inverse timelock" mechanism for sponsor transactions. These sponsor transactions can be pre-signed and used to sponsor other transactions within the last 100 blocks, but after 100 blocks, the sponsor transaction becomes invalid. This proposal has raised skepticism as it goes against the principle that once a transaction is valid, it should not become invalid later. The author suggests improving the current policy rules for Child-Pays-for-Parent (CPFP) as an alternative to introducing a consensus change.There are discussions about the limitations and challenges of CPFP-based protocols, including chain bloat issues and difficulties with recursive use. The author suggests that emulating the behavior of sponsors in a transaction graph could be a viable alternative. However, they also acknowledge that a consensus change for sponsor transactions would be more robust and fixable in case of new attacks. They suggest implementing limitations and restrictions to mitigate concerns about pinning and recursive behavior.The conversation also addresses the issue of feerate in multi-party protocols using pre-signed transactions. There are concerns that the feerate may change between creation and broadcast, causing problems if the feerate is too low for the transaction to propagate across network mempools. The suggestion is made to evaluate the feerate of the entire package of transactions as a whole to ensure acceptance by the network. Concerns are also raised about low fee sponsored transactions being evicted from mempools due to fee pressure. The requirement that the sponsor's entry must be present in the mempool is seen as creating a catch-22 situation, and the suggestion is made to revise this requirement while still allowing Replace-by-Fee (RBF) to work.The discussion also touches on the issue of concurrent states being pinned in a sponsor mechanism. It is suggested to change the sponsor vectors to point to input outpoints instead of transaction IDs to address this issue. The conversation highlights the need to consider feerate and package relay in solving pinning issues, as well as the challenges and potential solutions related to malleability and protocol flexibility.A draft proposal has been shared with Bitcoin Devs for a mechanism to replace Child Pays For Parent (CPFP) and Replace By Fee (RBF) for increasing fees on transactions in the mempool. The proposal aims to create a fully abstracted primitive that requires no special structure from an underlying transaction to increase fees and confirm transactions. However, there are concerns about creatively combining vectors to provoke mempool partitions. A further softfork proposal regarding sighash malleability is required for the security semantic for Lightning type of protocols. The proposal suggests a general-purpose mechanism for expressing non-destructive dependencies on specific transactions that can be used to sponsor fees of remote transactions.The proposal restricts the mempool policy to ensure a subset of behavior sufficient to replace CPFP and RBF for fee bumping. The final output of a transaction is used as a location to attach metadata for transaction validation. In addition, a new feature has been introduced in the Bitcoin mempool that allows third-party fees to be attached to arbitrary transactions. There are limitations imposed on the Sponsor Vector to prevent garbage sponsors.Future policy work may involve inserting sponsors into a special sponsor pool with an eviction policy to track low fee transactions that cannot enter the mempool initially. A reference implementation demonstrating these rules is available but has not been audited for correctness.In a separate email conversation, concerns about potential attacks using the Bitcoin mempool pinning mechanism are raised. Two policies are suggested to prevent such attacks: restricting the size of sponsoring transactions or limiting the number of inputs and outputs in a sponsoring transaction. The conversation also discusses the implementation in the Bitcoin reference implementation and suggests policies to eliminate certain attacks.Another conversation addresses questions about the impact of implementing RBF/CPFP on Bitcoin transaction privacy. The speaker believes that there are reasons why it wouldn't worsen privacy and highlights the benefits of using RBF/CPFP.Overall, the proposed mechanism aims to replace CPFP and RBF for fee bumping in Bitcoin transactions. It provides a general specification for inter-transaction dependencies and restricts the mempool policy while allowing third parties to attach fees to arbitrary transactions.
Updated on: 2023-08-02T02:40:53.369506+00:00