Published on: 2023-05-10T15:42:34+00:00
The email thread on the bitcoin-dev mailing list discusses the availability of the submitpackage RPC on the mainnet in the current core release. Tom Trevethan inquired about its availability and any plans for deployment in the next release. Greg replied that a PR was opened to address this concern and shared a link for higher-level tracking of the project.Currently, the submitpackage RPC is available on regtest in the current core release. However, there has been no recent discussion or timeline for deploying it on the mainnet in the next release. The submitpackage RPC is crucial for addressing mempool purge issues.Gloria Zhao proposed changes to her package relay proposal called Ancestor Package Relay, BIP331. The changes involve reducing the scope to receiver-initiated and ancestor packages only, removing sender-initiated package relay. The proposal also removes child-with-unconfirmed-parents package as it is a subset of ancestor packages. The major change in package information is the removal of the block hash, which should be handled internally at the mempool validation level. The proposal discusses the purpose of 'max_count' and 'max_weight', trade-offs in bandwidth consumption, and concerns of package-feerate downgrades attacks.The proposal suggests a set of p2p protocol changes to enable package relay, introducing version 1 packages consisting of one transaction and its unconfirmed parents. It explains the rules and requirements for package relay in Bitcoin Core, specifying the structure and purpose of messages like "sendpackages," "getpckgtxns," and "pckgtxns." The proposal aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions.The proposal also addresses pinning attacks by considering transactions as a unit instead of individually. It mentions the use of ancestor packages in evaluating transactions in the mempool and developing a safe and incentive-compatible package mempool acceptance policy. The proposed protocol flow involves the sender announcing the package and providing package information upon request from the receiver. It suggests adding new inv types and protocol messages to support this.The proposal for package relay aims to improve communication efficiency, reduce bandwidth usage, and optimize storage for unconfirmed transactions. It introduces versioning to support different types of packages based on future use cases. The proposal acknowledges the contributions of various developers and includes a list of related links and resources.The conversation between Gloria Zhao and Suhas Daftuar discusses potential issues with package relay, including concerns about bandwidth waste and potential denial-of-service attacks. Suggestions are made to mitigate these issues, such as including a hash of the package wtxids in the initial announcement and limiting the use of version 1 packages. The discussion also covers the validation rules for packages and the use of BIP152 shortids.The conversation further explores the implementation of package relay using BIP152 and proposes changes to improve its efficiency and security. The suggestion of using a Merkle root for package identity instead of blockhash is discussed. Various aspects of the proposal, including incorporating ancestors into package announcements and versioning, are considered.The conversation concludes that while there are potential issues with package relay, further consideration and improvements could make it a valuable addition to Bitcoin's protocol. Relevant resources and links, such as BIP152, are shared throughout the discussion.The conversation on the Bitcoin-dev mailing list discusses various aspects of package relay in the Bitcoin protocol. One of the main concerns raised is the possibility of peers providing false information, leading to censorship of transactions. To address this, it is suggested to store all announcements and request from every peer to prevent censorship. The idea of including more upfront information, such as fee and weight, when announcing packages is also discussed, although its effectiveness in resolving censorship issues is debated.Another proposed solution is to encode parent transactions as short hashes of the wtxid and include them in the inv announcement to avoid round trips while deduplicating parents. However, it is noted that this method may create a denial-of-service vector as nodes would need to calculate shortids for every transaction in their mempools every time they receive a package.The discussion also highlights the use of BIP152 shortids for package relay and the need to simplify the protocol. It is mentioned that adding versioning to individual protocols is a reflection of the insufficiency of the initial protocol versioning design. The size and count constraints for package broadcasts are addressed, and it is mentioned that packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row.Overall, the email thread focuses on potential issues with peer-to-peer package announcements and proposes solutions using existing protocols. The conversation delves into the technical details of package relay, including the inclusion of fee and weight information, encoding parent transactions, and the use of shortids.
Updated on: 2023-08-02T06:32:07.153762+00:00