Author: Antoine Riard 2021-03-02 22:42:14
Published on: 2021-03-02T22:42:14+00:00
The proposal aims to allow nodes to accept more incoming connections that only propagate blocks without transaction relays or address gossip while minimizing resource requirements. It is suggested that fRelay, an optional field in the version message, should be used to indicate no transaction relay. However, BIP 60 is unclear, and a well-defined standard with a clean negotiation mechanism is needed instead of relying on code specifics of a given Bitcoin client. To allow a certain number of inbound peers that do not relay transactions, it is suggested to update the inbound eviction logic to protect more inbound peers that do not have transaction relay data structures. However, this may give a bias toward an attacker in occupying our inbound slots compared to honest inbound peers which, on average, are going to be full-relay.A proposal has been made to add a new optional p2p message called "disabletx" which would allow peers to communicate that they will not send or receive loose transactions for the lifetime of the connection, helping to create low-resource connections that protect against partition attacks on the network. The proposed solution adds a single new p2p message, "disabletx", which (if used at all) must be sent between version and verack. Addresses of potential peers are shared around the p2p network using "addr" messages, and Bitcoin Core relays these records to one or two of its peers, chosen at random. To prevent addr black holes, Bitcoin Core should only relay addr records to an inbound peer if it has previously received an "addr" or "addrv2" message from that peer. This approach will improve addr propagation immediately and without any change to the P2P protocol and will prevent sending "addr" records to all addr black holes (such as light clients), not just incoming block-relay-only connections.It is proposed that for Bitcoin Core version 22.0, only initialize 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. Only initialize the addr data structures for inbound connections when an "addr", "addrv2" or "getaddr" message is received on the connection, and only consider a connection for addr relay if its addr data structures are initialized. Update the inbound eviction logic to protect more inbound peers which do not have transaction relay data structures. Then, in version 23.0, modestly increase the number of outbound block-relay-only connections.A new, optional p2p message has been proposed by Suhas Daftuar to allow peers to communicate that they do not want to send or receive transactions for the lifetime of a connection. The proposal adds a new "disabletx" message that can be sent between version and verack, indicating that the connection should not be used for transaction-relay for the connection's lifetime. Nodes with protocol version >= 70017 that do not implement this BIP, and nodes implementing software: transactions would not be relayed to peers sending the disabletx message (provided that BIP 37 or BIP 60 has been implemented), while periodic address relay may still take place. 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. Bitcoin Core has implemented this functionality since version 0.19.0.1, released in November 2019.
Updated on: 2023-06-14T16:59:15.347729+00:00