Author: Antoine Riard 2021-03-01 23:11:51
Published on: 2021-03-01T23:11:51+00:00
The Bitcoin-dev mailing list is discussing the proposal of adding a new peer-to-peer (P2P) message. This new message would allow nodes to accept more incoming block-relay-only connections. However, John Newbery argues that this is unnecessary and suggests using fRelay=false instead. This approach would signal no transaction relay and postpone allocating resources for transaction relay data structures until after the version message has been received. To prevent addr black holes, John proposes only relaying addr records to an inbound peer if it has previously received an addr or addrv2 message from that peer.Antoine Riard disagrees with John's proposal and argues that reusing fRelay for a different aim is not good practice. He suggests having a well-defined standard with a clean negotiation mechanism instead. Antoine also points out that a non-Bitcoin Core client would have to implement the fRelay subset of BIP37 to understand tx-relay opt-out from peers correctly. This situation could cause future developers to choose between implementing a standard in a non-compliant way or implementing p2p messages for a light client protocol in a way of deprecation. Furthermore, Antoine suggests explicitly negotiating addr-relay to offer more flexibility and hygienic code paths.Suhas Daftuar proposed adding a new, optional P2P message to allow peers to communicate that they do not want to send or receive (loose) transactions for the lifetime of a connection. This proposal aims to facilitate connections on the network over which only block-related data are relayed. These types of connections create low-resource connections that help protect against partition attacks on the network. The proposed message, called "disabletx," must be sent between version and verack and is valid for peers advertising protocol version 70017 or higher.Nodes implementing software: transactions would not be relayed to peers sending the disabletx message, and periodic address relay may still take place. However, 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.The proposed BIP describes a change to the p2p protocol to allow a node to inform a peer that a connection will not be used for transaction relay. This change supports block-relay-only connections that are currently in use on the network. 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. John proposes only initializing the transaction relay data structures after the version message is received and only if fRelay=true and `NODE_BLOOM` is not offered on this connection for Bitcoin Core version 22.0. For version 23.0, John suggests modestly increasing the number of outbound block-relay-only connections.
Updated on: 2023-06-14T17:00:37.482335+00:00