From 5f18700477e2c09653591b940caa40d285a21d95 Mon Sep 17 00:00:00 2001 From: Suhas Daftuar Date: Thu, 3 Sep 2020 16:51:17 -0400 Subject: [PATCH] p2p: Add disabletx message This message, valid between version/verack for peers with version >= 70017, would allow establishing at the time of connection that no transactions will be announced/requested between those peers. --- bip-disable-tx.mediawiki | 100 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 bip-disable-tx.mediawiki diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki new file mode 100644 index 00000000..c2bca255 --- /dev/null +++ b/bip-disable-tx.mediawiki @@ -0,0 +1,100 @@ +
+  BIP: XXX
+  Layer: Peer Services
+  Title: Disable transaction relay message
+  Author: Suhas Daftuar 
+  Comments-Summary: No comments yet.
+  Comments-URI:
+  Status: Draft
+  Type: Standards Track
+  Created: 2020-09-03
+  License: BSD-2-Clause
+
+ +==Abstract== + +This BIP describes a change to the p2p protocol to allow a node to tell a peer +that a connection will not be used for transaction relay, to support +block-relay-only connections that are currently in use on the network. + +==Motivation== + +For nearly the past year, software has been deployed[1] which initiates +connections on the Bitcoin network and sets the transaction relay field +(introduced by BIP 37 and also defined in BIP 60) to false, to prevent +transaction relay from occurring on the connection. Additionally, addr messages +received from the peer are ignored by this software. + +The purpose of these connections is two-fold: by making additional +low-bandwidth connections on which blocks can propagate, the robustness of a +node to network partitioning attacks is strengthened. Additionally, by not +relaying transactions and ignoring received addresses, the ability of an +adversary to learn the complete network graph (or a subgraph) is reduced[2], +which in turn increases the cost or difficulty to an attacker seeking to carry +out a network partitioning attack (when compared with having such knowledge). + +The low-bandwidth / minimal-resource nature of these connections is currently +known only by the initiator of the connection; this is because the transaction +relay field in the version message is not a permanent setting for the lifetime +of the connection. Consequently, a node receiving an inbound connection with +transaction relay disabled cannot distinguish between a peer that will never +enable transaction relay (as described in BIP 37) and one that will. Moreover, +the node also cannot determine that the incoming connection will ignore relayed +addresses; with that knowledge a node would likely choose other peers to +receive announced addresses instead. + +This proposal adds a new, optional message that a node can send a peer when +initiating a connection to that peer, to indicate that connection should not be +used for transaction-relay for the connection's lifetime. In addition, without +a current mechanism to negotiate whether addresses should be relayed on a +connection, this BIP suggests that address messages not be sent on links where +tx-relay has been disabled. + +==Specification== + +# A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx". +# The protocol version of nodes implementing this BIP must be set to 70017 or higher. +# If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack. +# A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer: +## inv messages for transactions +## getdata messages for transactions +## getdata messages for merkleblock (BIP 37) +## filteradd/filterload/filterclear (BIP 37) +## mempool (BIP 35) +# It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer: +## addr/getaddr +## addrv2 (BIP 155) +# The behavior regarding sending or processing other message types is not specified by this BIP. +# Nodes MAY decide to not remain connected to peers that send this message (for example, if trying to find a peer that will relay transactions). + +==Compatibility== + +Nodes with protocol version >= 70017 that do not implement this BIP, and nodes +with protocol version < 70017, will continue to remain compatible with +implementing software: transactions would not be relayed to peers sending the +disabletx message (provided that BIP 37 or BIP 60 has been implemented), and while +periodic address relay may still take place, software implementing this BIP +should not be disconnecting such peers solely for that reason. + +Disabling address relay is suggested but not required by this BIP, to allow for +future protocol extensions that might specify more carefully how address relay +is to be negotiated. This BIP's recommendations for software to not relay +addresses is intended to be interpreted as guidance in the absence of any such +future protocol extension, to accommodate existing software behavior. + +Note that all messages specified in BIP 152, including blocktxn and +getblocktxn, are permitted between peers that have sent/received a disabletx +message, subject to the feature negotiation of BIP 152. + +==Implementation== + +TBD + +==References== + +# Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemented this functionality] since version 0.19.0.1, released in November 2019. +# For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and https://arxiv.org/pdf/1812.00942.pdf. + +==Copyright== + +This BIP is licensed under the 2-clause BSD license.