Skip to content

Commit 5f18700

Browse files
committed
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.
1 parent bdb297a commit 5f18700

File tree

1 file changed

+100
-0
lines changed

1 file changed

+100
-0
lines changed

bip-disable-tx.mediawiki

Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
<pre>
2+
BIP: XXX
3+
Layer: Peer Services
4+
Title: Disable transaction relay message
5+
Author: Suhas Daftuar <[email protected]>
6+
Comments-Summary: No comments yet.
7+
Comments-URI:
8+
Status: Draft
9+
Type: Standards Track
10+
Created: 2020-09-03
11+
License: BSD-2-Clause
12+
</pre>
13+
14+
==Abstract==
15+
16+
This BIP describes a change to the p2p protocol to allow a node to tell a peer
17+
that a connection will not be used for transaction relay, to support
18+
block-relay-only connections that are currently in use on the network.
19+
20+
==Motivation==
21+
22+
For nearly the past year, software has been deployed[1] which initiates
23+
connections on the Bitcoin network and sets the transaction relay field
24+
(introduced by BIP 37 and also defined in BIP 60) to false, to prevent
25+
transaction relay from occurring on the connection. Additionally, addr messages
26+
received from the peer are ignored by this software.
27+
28+
The purpose of these connections is two-fold: by making additional
29+
low-bandwidth connections on which blocks can propagate, the robustness of a
30+
node to network partitioning attacks is strengthened. Additionally, by not
31+
relaying transactions and ignoring received addresses, the ability of an
32+
adversary to learn the complete network graph (or a subgraph) is reduced[2],
33+
which in turn increases the cost or difficulty to an attacker seeking to carry
34+
out a network partitioning attack (when compared with having such knowledge).
35+
36+
The low-bandwidth / minimal-resource nature of these connections is currently
37+
known only by the initiator of the connection; this is because the transaction
38+
relay field in the version message is not a permanent setting for the lifetime
39+
of the connection. Consequently, a node receiving an inbound connection with
40+
transaction relay disabled cannot distinguish between a peer that will never
41+
enable transaction relay (as described in BIP 37) and one that will. Moreover,
42+
the node also cannot determine that the incoming connection will ignore relayed
43+
addresses; with that knowledge a node would likely choose other peers to
44+
receive announced addresses instead.
45+
46+
This proposal adds a new, optional message that a node can send a peer when
47+
initiating a connection to that peer, to indicate that connection should not be
48+
used for transaction-relay for the connection's lifetime. In addition, without
49+
a current mechanism to negotiate whether addresses should be relayed on a
50+
connection, this BIP suggests that address messages not be sent on links where
51+
tx-relay has been disabled.
52+
53+
==Specification==
54+
55+
# A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx".
56+
# The protocol version of nodes implementing this BIP must be set to 70017 or higher.
57+
# 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.
58+
# A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer:
59+
## inv messages for transactions
60+
## getdata messages for transactions
61+
## getdata messages for merkleblock (BIP 37)
62+
## filteradd/filterload/filterclear (BIP 37)
63+
## mempool (BIP 35)
64+
# 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:
65+
## addr/getaddr
66+
## addrv2 (BIP 155)
67+
# The behavior regarding sending or processing other message types is not specified by this BIP.
68+
# 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).
69+
70+
==Compatibility==
71+
72+
Nodes with protocol version >= 70017 that do not implement this BIP, and nodes
73+
with protocol version < 70017, will continue to remain compatible with
74+
implementing software: transactions would not be relayed to peers sending the
75+
disabletx message (provided that BIP 37 or BIP 60 has been implemented), and while
76+
periodic address relay may still take place, software implementing this BIP
77+
should not be disconnecting such peers solely for that reason.
78+
79+
Disabling address relay is suggested but not required by this BIP, to allow for
80+
future protocol extensions that might specify more carefully how address relay
81+
is to be negotiated. This BIP's recommendations for software to not relay
82+
addresses is intended to be interpreted as guidance in the absence of any such
83+
future protocol extension, to accommodate existing software behavior.
84+
85+
Note that all messages specified in BIP 152, including blocktxn and
86+
getblocktxn, are permitted between peers that have sent/received a disabletx
87+
message, subject to the feature negotiation of BIP 152.
88+
89+
==Implementation==
90+
91+
TBD
92+
93+
==References==
94+
95+
# Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemented this functionality] since version 0.19.0.1, released in November 2019.
96+
# For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and https://arxiv.org/pdf/1812.00942.pdf.
97+
98+
==Copyright==
99+
100+
This BIP is licensed under the 2-clause BSD license.

0 commit comments

Comments
 (0)