Published on: 2021-03-02T22:42:14+00:00
In a Bitcoin development mailing list, there is a proposal to increase the number of block-relay-only connections and improve addr record propagation without making changes to the p2p protocol. The proposal suggests using the fRelay field in the version message to indicate no transaction relay. However, there are concerns about this approach, and it is recommended to have a well-defined standard with a clean negotiation mechanism.To prevent addr black holes, it is 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. This approach will improve addr propagation immediately and prevent sending addr records to all addr black holes.A new 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. This message aims to create low-resource connections that protect against partition attacks on the network. Nodes implementing this BIP must set the protocol version to 70017 or higher.The proposed changes aim to increase the number of inbound block-relay-only peers while minimizing resource requirements and improving addr record propagation. This would be achieved by initializing transaction relay data structures after the version message is received and only if certain conditions are met. Additionally, a new p2p message, "disabletx," would be added to facilitate connections over which only block-related data are relayed.However, there are disagreements regarding the use of fRelay and the need for a clear negotiation mechanism. Some argue that reusing fRelay for a different purpose is not ideal and suggest having a well-defined standard instead. They also propose explicitly negotiating addr relay for more flexibility.Overall, the proposed changes aim to enhance the efficiency and security of peer connections in the Bitcoin network, specifically focusing on block propagation and addr record propagation. These changes would help protect against network attacks and improve the overall performance of the network. Bitcoin Core has already implemented some of these functionalities in previous versions, demonstrating the feasibility and potential benefits of these proposals.In a recent email thread, Bitcoin developer Suhas Daftuar has proposed the addition of a new optional peer-to-peer (p2p) message called "disabletx" to the Bitcoin protocol. This message would allow peers to communicate that they do not want to send or receive loose transactions during their connection. The purpose of this message is to facilitate low-resource connections on the network, where only block-related data are relayed, in order to strengthen network security against partition attacks.Currently, software has been deployed that initiates connections on the Bitcoin network and sets the transaction relay field to false, preventing transaction relay from occurring on the connection. These connections serve two purposes: enhancing the robustness of a node to network partitioning attacks and reducing an adversary's ability to learn the complete network graph. However, there is a need for a more standardized approach to indicate that loose transactions will not be sent or received for the entire lifetime of a connection.The proposal suggests adding the "disabletx" message as a new p2p message to address this need. It also recommends using the existing "fRelay" field in the version message to indicate that no transaction relay can happen for the entire lifetime of the connection. By postponing resource allocation for transaction relay data structures until after the version message has been received, the proposal aims to minimize resource usage for incoming block-relay-only connections.Additionally, the proposal suggests updating the inbound eviction logic to protect more inbound peers that do not have transaction relay data structures. It recommends initializing address data structures for inbound connections only when specific messages related to addresses are received on the connection. Furthermore, it proposes modestly increasing the number of outbound block-relay-only connections.The Bitcoin Improvement Proposal (BIP) 324 also suggests disabling address relay between peers to prevent network analysis attacks. While the proposal does not require software to relay addresses, it allows for future protocol extensions that might specify how address relay should be negotiated.The proposed changes aim to strengthen network security against partition attacks and network analysis attacks while minimizing resource usage for incoming block-relay-only connections. The full details of the proposals, including compatibility information, can be found in the respective BIPs.
Updated on: 2023-08-02T03:00:35.927900+00:00