bitcoin-dev

Draft BIP for User-Defined Transaction Flags Policy & Strategy

Draft BIP for User-Defined Transaction Flags Policy & Strategy

Original Postby Antoine Riard

Posted on: April 16, 2024 02:01 UTC

Several years ago, discussions on mitigations for mempool pinning at both the commitment and second-stage transaction levels led to the proposal of a new transaction-relay infrastructure.

This infrastructure aimed to directly connect Lightning nodes and miners' mempools via LN gossips. However, this idea was eventually set aside due to potential misalignments in incentives between miners and Lightning nodes. Specifically, there were concerns that a Lightning Service Provider (LSP), acting as a channel counterparty, might neglect to relay critical transactions, such as those containing a Hash Time-Locked Contract (HTLC) preimage. Furthermore, the issue of mempool partitioning by a counterparty using an alternate commitment transaction was raised, highlighting inherent vulnerabilities in the proposed system.

Since these initial discussions, there has been a noticeable increase in privileged transaction-relay APIs designed for Bitcoin applications with urgent transaction needs. These "transaction accelerators" depend largely on the reputation of mining pools and have sparked debates over the potential erosion of a unified blockspace market fee rate, which is traditionally estimated by all full-node operators. This shift towards private or staged transaction-relay APIs poses significant questions about the future accessibility and equity of transaction fees in the Bitcoin network.

In exploring alternatives, an experiment titled "transaction-issuer selected policy limits" was conducted, focusing on allowing transaction issuers to define their own policy boundaries, such as the maximum standard transaction weight acceptable for a specific transaction version. The experiment utilized the nSequence field for signaling opt-in, though this approach was criticized for its inelegance and associated challenges. The discussion highlights the broader implications of user-defined transaction flags, suggesting that any proposals in this area must be backed by a robust security model. Such a model would need to leverage miners' economic incentives to ensure that these flags are respected, thereby safeguarding the integrity and finality of transactions within the network.

This conversation underscores the evolving landscape of Bitcoin transaction protocols and the ongoing search for solutions that balance innovation with security, fairness, and efficiency. As the industry moves forward, it will be crucial to consider the economic and technical ramifications of new transaction relay methods, ensuring that they serve the broader goals of the Bitcoin ecosystem without compromising its foundational principles.