summaryrefslogtreecommitdiff
path: root/bip-0338.mediawiki
diff options
context:
space:
mode:
authorLuke Dashjr <luke-jr+git@utopios.org>2021-02-12 21:02:49 +0000
committerLuke Dashjr <luke-jr+git@utopios.org>2021-02-12 21:03:39 +0000
commitd2853bcc511989d2ba96c0e3cffe51dd8b042879 (patch)
tree03134f6965c24a6b066c1dae11bee3978918cc63 /bip-0338.mediawiki
parent31f61e71759c8c205294b2065a8383a91c60b436 (diff)
Assign BIP 338 for Disable transaction relay message
Diffstat (limited to 'bip-0338.mediawiki')
-rw-r--r--bip-0338.mediawiki112
1 files changed, 112 insertions, 0 deletions
diff --git a/bip-0338.mediawiki b/bip-0338.mediawiki
new file mode 100644
index 0000000..4e2c220
--- /dev/null
+++ b/bip-0338.mediawiki
@@ -0,0 +1,112 @@
+<pre>
+ BIP: 338
+ Layer: Peer Services
+ Title: Disable transaction relay message
+ Author: Suhas Daftuar <sdaftuar@chaincode.com>
+ Comments-Summary: No comments yet.
+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0338
+ 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 with message type set to "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)
+## tx message
+# 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.
+
+This proposal is compatible with, but independent of, BIP 37.
+
+==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.