Package relay

p2p-package-relay.mediawiki

  BIP: <unassigned>
  Layer: Peer Services
  Title: Transaction Package Relay
  Author: Suhas Daftuar <sdaftuar@chaincode.com>
  Comments-Summary: 
  Comments-URI: 
  Status: Draft
  Type: Standards Track
  Created: 2018-09-25
  License: GNU-All-Permissive

Table of Contents Abstract Motivation Specification New data structures TransactionPackage New messages sendpackages getpackage package

Abstract

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.

Motivation

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.

Specification

New data structures

TransactionPackage

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

New messages

sendpackages

1. The sendpackages message is defined as a message containing a 8-byte integer where pchCommand == "sendpackages".
2. The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendpackages message MUST currently set this value to 1.
3. TODO: do we need to negotiate the ancestor limit for a given peer, or just hardcode a big number into the spec?
4. Upon receipt of a "sendpackages" message with the version set to 1, nodes MAY send the peer "getancestors" messages

for transaction ids that have been announced by the peer.

getpackage

1. The getancestors message is defined as a message containing a 32-byte field where pchCommand == "getpackage".
2. The 32-byte filed SHALL be interpreted as a transaction id (serialized without witness).
3. 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.

package

1. The package message is defined as a message containing a serialized TransactionPackage message and pchCommand == "package".
2. 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.
3. A peer SHOULD respond to getdata requests for any transaction id in a package that it recently announced.

TODO: do we need to negotiate the ancestor limit for a given peer, or just hardcode a big number into the spec?

I think we just want a big number in this spec (probably just repeat MAX_INV_SZ). The node that sends the package won't send more than its ancestor limit, and the receiving node can just look at the number of ancestors and check there's not too many before doing GETDATA.

I would have thought including some fee/weight info in the package message would make sense?

Is the second message called getpackage or getancestors (or both?)?

@