Author: eric at voskuil.org 2022-09-26 21:19:39
Published on: 2022-09-26T21:19:39+00:00
The email discusses the issue of stuck transactions arising from minimum fee rate policy and proposes a solution through package relay. The objective of the proposal is to propagate transactions that are incentive-compatible to mine, even if they don't meet the minimum feerate alone. The email raises several questions and observations related to the proposed mechanism, including the possibility of having multiple pre-signed transactions with different fee rates in a range, the impact of covenants on this problem, and the predictability of pre-signed tx rejection by nodes. The author also provides insights from Matt Corallo's thoughts on the matter, which point to the need for introducing a mechanism for parent transactions to be relayed along with their higher feerate children, even if the parent transaction would be rejected by itself. The email further discusses the impact of changing the order of transactions in a package and how packages introduce more attack vectors in Bitcoin for front running or MEV. The email concludes that any policy beyond what is published via the protocol will cause problems and that the only policies that remain in widespread application are those that are necessary for DOS protection (fee rate).The Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. The proposal suggests that a node should package transactions for each of its peers, based on their individual fee rate. This design eliminates dead-ending packages and provides a solution to stuck transactions. A node receiving an announcement for a package or transaction below its own fee rate should drop the announcing peer. The proposal requires an additional INV element type, such as MSG_TX_PACKAGE. It also suggests additional constraints, such as defining a set that can be mined into one block, ensuring minimal packages and imposing a partial tx order. The design calls for maintenance of a transaction DAG with tx.feerate on each tx, which could be the unconfirmed tx graph or memory pool, and nodes must be able to confirm a set of validated transactions within a block. The package relay algorithm introduces two essential aspects: avoiding predictable orphans and creating minimal packages.The discussion on package relay proposal continues with new observations and suggestions. One observation made is that having transaction relay gated on whether two nodes agree on chain tip seems overly restrictive. The goal is to minimize disruption from network splits, and transaction relay bifurcating on the two network halves would only exacerbate the difference between the two sides of the split. Additionally, the use of a chain tip might impose a larger burden than is necessary on software seeking to participate in transaction relay without implementing headers sync/validation. The proposed package is similar to a compact block announcement, already defined in BIP152, but with updated protocol versions and changes to names. The size of the package is restricted by consensus and can be up to what can be mined in one block, while the count is incorporated into BIP152 as 'shortids_length'. Once a validated set of transactions within the package has been obtained with sufficient fee, a fee-optimal node would accept the largest subgraph of the package that conforms to fee constraints and drop any peer that provides a package for which the full graph does not.
Updated on: 2023-06-15T21:41:23.106920+00:00