Skip to content

Add BIP 338: Disable transaction relay message #1052

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Feb 12, 2021
Merged

Add BIP 338: Disable transaction relay message #1052

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
5f18700
p2p: Add disabletx message
sdaftuar Sep 3, 2020
794f20a
Add link to implementation
sdaftuar Jan 26, 2021
55a31eb
Add more language in hope of BIP number assignment
sdaftuar Feb 11, 2021
332b9a4
Note that tx messages are never allowed on disabletx links
sdaftuar Feb 12, 2021
31f61e7
Mention compatibility with bip 37
sdaftuar Feb 12, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
109 changes: 109 additions & 0 deletions bip-disable-tx.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,109 @@
<pre>
BIP: XXX
Layer: Peer Services
Title: Disable transaction relay message
Author: Suhas Daftuar <[email protected]>
Comments-Summary: No comments yet.
Comments-URI:
Status: Draft
Type: Standards Track
Created: 2020-09-03
License: BSD-2-Clause
</pre>

==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==

This proposal is part of an effort to increase the number of inbound
connections that a peer can service, by distinguishing peers which will not
relay transactions from those that do.

Since 2019, 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
transaction relay has been disabled.

After this BIP is deployed, nodes could more easily implement inbound
connection limiting that differentiates low-resource nodes (such as those
sending disabletx) from full-relay peers, potentially allowing for an increase
in the number of block-relay-only connections that can be made on the network.

==Specification==

# A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx".
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx".
# A new disabletx message is added, which is defined as an empty message with message type "disabletx".

unrelated style nit: I know previous bips like to reference Bitcoin Core internal implementation details, such as variable naming. Though, I think it would be good if bips avoided implementation-specific details where possible to avoid confusion when the internals change. Just saying "message type" might even be clearer and the audience that is interested in Bitcoin Core internals, can still follow the link in the Implementation section.

# 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:
Copy link
Member

@jonatack jonatack Feb 5, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should disconnection (as opposed to ignoring said messages) be explicitly specified here for the MUST NOT messages (or is that implied?)

Disconnection is mentioned line 68 below, "Nodes MAY decide to not remain connected..."

Copy link
Member Author

@sdaftuar sdaftuar Feb 11, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think how software handles a peer that violates a "MUST NOT" behavior is totally up to the implementation and disconnecting is an implied acceptable outcome.

Calling out that nodes might disconnect a peer further down was just to make it clear that even nodes that faithfully implement the BIP might disconnect each other for a legitimate reason (ie that a node is looking for a full relay connection, but only could establish a block-relay-only connection).

## 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==

https://github.com/bitcoin/bitcoin/pull/20726

==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.