Author: John Newbery 2021-03-02 12:11:23
Published on: 2021-03-02T12:11:23+00:00
In a discussion on the bitcoin-dev mailing list, John Newbery proposed changes to Bitcoin Core's policy for how it treats its peer connections. The proposal aims to allow a node to accept more incoming connections that will only be used for block propagation while minimizing resource requirements. He suggested using `fRelay` field in the `version` message to indicate that no transaction relay can happen for the entire lifetime of the connection.Antoine Riard expressed concerns about using `fRelay` to disable transaction relay, arguing that this is not good practice ecosystem-wise. They recommended having a well-defined standard with a clean negotiation mechanism rather than relying on code specifics of a given Bitcoin client. Additionally, they suggested explicit addr-relay negotiation to offer more flexibility and hygienic code paths rather than triggering data structure initialization in few different locations.Furthermore, there was a discussion on preventing 'addr black holes' where addresses of potential peers are gossiped around the p2p network using `addr` messages. John suggested that Bitcoin Core should only relay addr records to an inbound peer if it has previously received an `addr` or `addrv2` message from that peer, since that indicates definitively that the peer actively gossips `addr` records. This approach was first suggested by AJ in the original block-relay-only PR. However, Antoine argued that distrust of inbound peers with addr-relay might be a sane direction and explicit addr-relay negotiation would offer more flexibility.The Bitcoin Core node relays `addr` records to one or two of its peers at random in order for the record to eventually reach most of the nodes on the network. However, if there are too many nodes on the network that receive `addr` records but do not relay them on to their peers (termed "addr black hole" nodes), then propagation of those `addr` records suffers. Bitcoin Core will not relay `addr` records on block-relay-only connections to protect against eclipse attacks and thwart network topology analysis.To address this issue, it is proposed that Bitcoin Core only relays addr records to an inbound peer if it has previously received an `addr` or `addrv2` message from that peer, since that indicates definitively that the peer actively gossips `addr` records. This approach will improve addr propagation immediately and without any change to the P2P protocol. An advantage of this approach is that it will prevent sending `addr` records to all addr black holes, not just incoming block-relay-only connections.In addition, a new, optional p2p message called "disabletx" is proposed to allow peers to communicate that they do not want to send or receive loose transactions for the lifetime of a connection. The purpose of this message is to help facilitate connections on the network over which only block-related data (blocks/headers/compact blocks/etc) are relayed, to create low-resource connections that help protect against partition attacks on the network. Nodes implementing this BIP must set the protocol version to 70017 or higher.Overall, these proposed changes aim to increase the permitted number of inbound block-relay-only peers while minimizing resource requirements and improving addr record propagation, without any changes to the p2p protocol required. The proposed BIP is designed to facilitate connections on the Bitcoin network over which only block-related data are relayed. By adding a new p2p message, "disabletx", peers can communicate that they do not want to send or receive transactions for the lifetime of a connection. 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 is reduced, which in turn increases the cost or difficulty to an attacker seeking to carry out a network partitioning attack.This proposal would add a single new p2p message, "disabletx," which if used at all must be sent between version and verack. This message is valid for peers advertising protocol version 70017 or higher. Nodes that have sent or received a disabletx message to/from a peer must not send any inv messages for transactions, getdata messages for transactions, getdata messages for merkleblock (BIP 37), filteradd/filterload/filterclear (BIP 37), or mempool (BIP 35) messages to the peer. It is recommended that nodes that have sent or received a disabletx message to/from a peer not send any addr/getaddr or addrv2 (BIP 155) messages to the peer.Bitcoin Core has implemented this functionality since version 0.19.0.1, released in November 2019.
Updated on: 2023-06-14T17:02:19.505875+00:00