BIP: <unassigned> Layer: Peer Services Title: Transaction Package Relay Author: Suhas Daftuar <[email protected]> Comments-Summary: Comments-URI: Status: Draft Type: Standards Track Created: 2018-09-25 License: GNU-All-Permissive
Add peer-to-peer protocol support for transmitting groups of transactions with interdependencies, for the purpose of allowing a network client to evaluate the set of transactions together.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
A low feerate transaction may have poor network propagation, resulting in an additional source of confirmation delay. While BIP 125 (replace-by-fee) provides one mechanism for transaction creators to replace a transaction with one that propagates better and is more likely to be confirmed in a block, so-called "child-pays-for-parent" strategies, where a descendant transaction is created with a high feerate to incentivize confirmation of the low feerate ancestor, afford transaction recipients a mechanism to reduce confirmation delays as well.
However, children of low feerate transactions may also have poor propagation on the network, because transactions generally only propagate through a node when the unconfirmed ancestors of the transaction are known, so that the transaction can be validated before relay (doing otherwise would generally pose Denial-of-Service concerns for the relaying peer). And if the parent transaction had low feerate and poor propagation, that can in turn cause the child transaction to have poor propagation, even though mining nodes would be incentivized to include the transaction package consisting of both transactions in a block.
To improve the propagation of transaction packages, we propose adding a set of new messages to the peer-to-peer network, to allow network clients to query one another to learn the set of ancestor transactions of a target transaction.
| Field Name | Type | Size | Encoding | Purpose |
| target_txid | Binary blob | 32 bytes | The output from a double-SHA256 of the serialized transaction, without witness | The transaction id whose ancestors are being provided |
| ancestors_length | CompactSize | 1 or 3 bytes | As used to encode lengths elsewhere | The number of ancestors provided |
| transaction hashes | List of transaction ids | 32 bytes each | The output from a double-SHA256 of the serialized transaction, without witness | The transaction ids of the unconfirmed ancestors of the target_txid |
- The sendpackages message is defined as a message containing a 8-byte integer where pchCommand == "sendpackages".
- The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendpackages message MUST currently set this value to 1.
- TODO: do we need to negotiate the ancestor limit for a given peer, or just hardcode a big number into the spec?
- Upon receipt of a "sendpackages" message with the version set to 1, nodes MAY send the peer "getancestors" messages
- The getancestors message is defined as a message containing a 32-byte field where pchCommand == "getpackage".
- The 32-byte filed SHALL be interpreted as a transaction id (serialized without witness).
- Upon receipt of a "getpackage" message for a transaction id that the node recently announced to the peer, a node SHOULD respond with the transaction ids of the unconfirmed ancestors of the transaction, sorted in topological/dependency order (ie, suitable for inclusion in a block), in the form an "package" message. A node MUST NOT include transaction ids that are not ancestors of the transaction id identified in the "getpackage" message.
- The package message is defined as a message containing a serialized TransactionPackage message and pchCommand == "package".
- The transaction ids in the package message MUST be in a valid order for inclusion in a block; in particular, a transaction id MUST NOT appear before the transaction id of any transaction it depends on.
- A peer SHOULD respond to getdata requests for any transaction id in a package that it recently announced.
@