Author: Antoine Riard 2022-06-17 20:08:36
Published on: 2022-06-17T20:08:36+00:00
The proposal for package relay aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions. It suggests grouping transactions called packages, which are connected directed acyclic graphs of transactions. The sender provides package information using "pckginfo1," including the blockhash of the sender's best block, the wtxids of the transactions in the package, their total fees and total weight. A child-with-unconfirmed-parents package for a transaction should be announced when it meets the peer's fee filter but one or more of its parents don't. However, there are concerns about pinning attacks and package-feerate downgrades attacks that need to be addressed.To solve the issue of pinning attacks, nodes should consider packages of transactions as a unit instead of individually. Bitcoin Core has used ancestor packages since v0.13 to evaluate transactions in the mempool and select them for inclusion in blocks. Developing a safe and incentive-compatible package mempool acceptance policy is necessary to fully address the issue. The proposed protocol flow for relaying a package of low-fee parent(s) and high-fee child involves the sender announcing the package using "inv(MSG_PCKG1)" and providing package information using "pckginfo1" upon request from the receiver. A new inv type, "MSG_PCKG1", and new protocol message, "PCKGINFO1", are added to support this protocol. Bitcoin developer Gloria Zhao has proposed a new transaction relay policy that would help mitigate potential denial-of-service (DoS) attacks. The proposal suggests creating a package relay, which would bundle multiple transactions together and send them as a single unit across the Bitcoin network. This would make it more difficult for attackers to target specific transactions and overwhelm the network with excessive data requests. The proposed package relay system would have two “flavors” of versioning: one where the version number is incremented when package mempool acceptance is upgraded to support more types of packages, and another where a version number is assigned to each new type of package introduced.The proposal contains two components: generic package relay protocol and an extension of it, child-with-unconfirmed-parents packages, as version 1 package relay. The main ideas introduced are to download and validate packages of transactions together and provide information to help peers decide whether to request and/or how to validate transactions which are part of a package. Two types of dialogue are proposed, receiver-initiated and sender-initiated, to facilitate the validation of transactions. Three new protocol messages are added for use in any version of package relay, and each version of package relay must define its own inv type and "pckginfo" message version. Version 1 packages extend package relay for packages consisting of one transaction and all of its unconfirmed parents.A child-with-unconfirmed-parents package can be defined for any transaction that spends unconfirmed inputs. The child can be thought of as the "representative" of the package. This package must be sorted topologically, consist of only one transaction and its unconfirmed parents, include all unconfirmed parents, have no conflicts, and have accurate total fees and weight fields. The protocol is extensible to support multiple types of packages based on future desired use. Older clients remain fully compatible and interoperable after this change. Clients implementing this protocol will only attempt to send and request packages if agreed upon during the version handshake.In conclusion, the proposal aims to improve the mempool and miner policy, making it easier for users to fee-bump their transactions and secure contracting protocols. However, concerns about pinning attacks and package-feerate downgrades attacks need to be addressed. The proposal builds upon previous work by other developers, including Suhas Daftuar and Antoine Riard. Zhao hopes to receive feedback on the proposal from other Bitcoin developers and acknowledges the contributions of John Newbery, Martin Zumsande, Matt Corallo, Christian Decker, David Harding, Antoine Poinsot, Antoine Riard, Gregory Sanders, Chris Stewart, and Bastien Teinturier in the development of the proposal. A list of related links and resources is provided at the end of the proposal.
Updated on: 2023-06-15T20:57:31.098754+00:00