Author: alicexbt 2022-09-26 17:50:48
Published on: 2022-09-26T17:50:48+00:00
This email thread discusses the concept of transaction packages in Bitcoin and its potential implications. The proposed objective of transaction packages is to propagate transactions that are incentive-compatible to mine, even if they don't meet minimum feerate alone. Without package relay, it’s not possible to effectively CPFP fee bump a transaction that’s below the minimum feerate nodes accept. The proposal suggests an additional INV element type, such as MSG_TX_PACKAGE, which must contain a set of transactions that can be mined into one block with defined constraints such as partial tx order, size/sigops constraint, etc. Various questions related to transaction packages are discussed, like whether multiple pre-signed transactions with different fee rates in a range are possible, how covenants affect this problem, how often pre-signed transactions get rejected by nodes because they did not meet the minimum fee rate, and how changing the order of transactions affects these transactions. Additionally, the email explores if packages introduce more attack vectors in Bitcoin for front running or MEV, what happens if the package contains a transaction with a sanctioned address, and why miners would use packages if the existing scenario in terms of fees per block is beneficial for them. It is argued that while it may be anti-bitcoin to introduce so much complexity, packages can help fix issues in which multiple users and transaction pre-signed between them are involved. However, creating new pre-signed transactions in some cases may be difficult to coordinate.Overall, the proposed transaction packages seem to be a primarily implementation change rather than a protocol change. They aim to avoid predictable orphans and create minimal packages, which should minimize the work/traffic required to invalidate the message. The approach involves graph search algorithms and should be O(n) where n is the unconfirmed ancestry of the package. The proposal is to maintain a transaction DAG with tx.feerate on each transaction to ensure that every peer has the necessary transaction (tx) for packaging. This would require maintenance of a transaction graph, but it does not have to be anything more than the parameters needed to confirm validated transactions within a block. A simple version negotiation can identify which nodes are package-accepting/sending. However, there may be an issue with bandwidth waste due to different policy rules among nodes.In particular, nodes that do not accept certain transactions will send getdata(PKGINFO1, T) and learn all of T's unconfirmed parents, which may cause bandwidth waste from downloading duplicate data from all peers. To mitigate this, some ways include including a hash of the package wtxids along with the wtxid of the child in the initial announcement or limiting v1 packages to transactions with very few parents. The discussion on the Package Relay Proposal continued on the Bitcoin-dev mailing list. Eric Voskuil suggested that a package is fundamentally a compact block announcement without the header, and hence, a node should never be required to retain an orphan. Voskuil also noted that compact block (BIP152) announcement is already well-defined and widely implemented. He added that there is no reason why packaging is not simply BIP152 without the 'header' field, an updated protocol version, and some renaming of message types. On the issue of dishonest peers announcing packages with inaccurate information, Anthony Towns proposed encoding the parent transactions as a short hash of the wtxid and including that in the inv announcement. However, Eric Voskuil suggested that this would not provide any benefit over using BIP152, which ensures that a validated set of transactions within the package has been obtained with sufficient fee, and a fee-optimal node would accept the largest subgraph of the package that conforms to fee constraints. The discussion also touched upon the issue of adding a graph to the proposal and the size/count parameters for the package. Finally, there was a suggestion to have "version" in "sendpackages" be a bit field instead of sending a message for each version. Overall, the participants appreciated the feedback and suggestions and discussed various aspects of the proposal.
Updated on: 2023-06-15T21:42:59.860862+00:00