BIP: XXX Layer: Peer Services Title: Package Relay Author: Antoine Riard <antoine.riard@gmail.com> Comments-Summary: No comments yet. Comments-URI: Status: Draft Type: Standards Track Created: License: BSD-2-Clause
This BIP describes new messages to the p2p protocol to support relay of groups of transactions with interdependencies, for the purpose of allowing a network client to evaluate them atomically.
Historically, transactions have always been evaluated on their own feerate at mempool acceptance, while being cattered as package, i.e graph of unconfirmed transactions with interdependent feerates for their block inclusion.
This mode of acceptance and propogation doesn't serve an array of use-cases, either by restraining some network clients to discover the best-feerate bids or higher-level applications to effectively enforce their transaction confirmation policies.
We propose adding a set of new messages to the peer-to-peer network to allow network clients to propagate package for which mempool acceptance must be evaluated atomically.
A node on the network may have a small mempool configuration, such that its minimum feerate required for acceptance is far higher than the rest of the network. A receipt of a low-feerate transaction will be rejected while a high-feerate child may be received just after. This downgrade the feerate discovery of such node and may false their fee-estimator.
A Coinjoin user among a set of participants may have a different liquidity preference than others and would like to unilaterally bump the feerate of the pending coinjoin to spend sooner its funds. Requiring interactivity might break privacy assumptions by triggering another round of communications. or trigger spending policy violations by accessing again cold wallets.
A LN user may delegate enforcement of its channel to a watchtower, while only providing pre-signed transactions to avoid fund hijacks by the distrusted watchtower. To operate its delegation job correctly, the watchtower needs to bump feerate of pre-signed transactions.
Contracting applications (vaults or LN) rely on the timely confirmation of transactions for funds security. Assuming a pre-negotiated fees model, a counterparty has an interest to stuck inclusion of a transaction to benefit from a timelock expiration. A honest party should be able to unilaterally bump feerates of its counter-signed transactions, without assuming knowledge of network mempools. [1]
A TxPackage is used to provide transactions of a previously announced package.
| Field Name | Type | Size | Encoding | Purpose |
| package_size | CompactSize | 1 or 3 bytes | As used to encode array lengths elsewhere | The number of transactions provided |
| transactions | List of Transactions | variable | As encoded in "tx" messages in response to getdata MSG_TX | The transactions provided |
The transactions MUST be topologically-ordered (CompareInvMempoolOrder).
A new inv type (MSG_PACKAGE == 6) and 2 new protocol messages are added: sendpackage, package.
- A new sendpackage message is added, which is defined as an empty message where pchCommand == "sendpackage".
- Nodes SHOULD check for a protocol version of >= 80002 before sending sendpackage messages and thus before sending a VERACK.
- Nodes MUST NOT send an announcement for a MSG_PACAKGE object to a peer before having received a sendpackage from that peer.
- Nodes MUST NOT request a MSG_PACKAGE object before having sent all sendpackage messages to that peer which they intend to send, as the peer cannot know what version protocol to use in the response.
- A new inv type MSG_PACKAGE(0x00000006) is added, for use in both INV messages and GETDATA requests, indicating that the hash being referenced is a package_id. A package_id MUST be computed as SHA256(tx_1 || tx_2 || ... || tx_n) with transaction topologically-ordered.
- Upon receipt of a getdata containg a request for a MSG_PACKAGE object, nodes MUST respond with a package message corresponding to the fetched package_id. If any transaction part of the fetched package isn't locally available, a NOTFOUND message MUST be replied.
- A new package message is added, which is defined as a serialized PackageTransactions and pchCommand == "package".
- A package MUST NOT be rejected (AlreadyHave) if any of its transactions has already been previously rejected or accepted
- Upon receipt of a package, nodes MUST evaluate package transactions complying with BIP-XXX (package-acceptance mempool)
https://github.com/ariard/bitcoin/tree/2020-07-sender-package-relay
This BIP is licensed under the 2-clause BSD license.