Published on: 2019-03-06T09:05:09+00:00
The concept ACK discusses several considerations regarding the gossip protocol in Bitcoin. The first consideration is whether a client should store and gossip address formats that they do not know about, especially those outside a certain overlay network. Three scenarios where a node may not know about an address format are discussed, followed by recommendations on how to proceed in each case. Despite concerns about gossiping unverified information, it is suggested that sharing information about other networks could be useful for nodes to help bootstrap connections.Another consideration is the precision of the time field in the protocol. It is argued that using seconds precision can be excessive and harmful. To address this, it is recommended to reduce the time field to 16 bits and quantize it to 1-hour precision, creating a "time ago seen" metric. This would reduce space requirements and mitigate attacks that exploit high-precision timestamps for mapping the current network topology.The document also proposes the inclusion of optional (per-service) data, which could be useful for various purposes, including optional flags. To encode the length of the payload for each flag, a byte count and type system is recommended. The authors acknowledge that while adding more information would create more opportunities for mapping the network topology, it could also be beneficial for certain use cases.A discussion on the Bitcoin-dev mailing list has raised questions about the maximum length of addresses for the Bitcoin protocol, specifically for the I2P network. It is suggested that the maximum address length should be defined per address type, considering there are two formats in use. Additionally, there was a debate on whether clients should store and gossip address formats they do not know about. It is proposed that clients should be discouraged from gossiping types they don't understand but not forbidden from doing so. However, caution should be exercised when gossiping unknown address types to prevent file transfer over invalid address types, particularly for networks without exit nodes.The document proposes a new P2P message called addrv2 to gossip longer node addresses over the P2P network. This is necessary to support new-generation Onion addresses, I2P, and other networks with longer endpoint addresses than what currently fits in the 128 bits of the addr message. The addrv2 message is defined as a message where pchCommand == "addrv2" and is serialized in the standard encoding for P2P messages. It has a format similar to the current addr message but with changes to accommodate longer addresses and a different time and services format.The list of reserved network IDs includes IPV4, IPV6, TORV2, TORV3, I2P, and CJDNS. Clients must ignore address types they do not know about to allow for future extensibility. They may also store and gossip address formats that they do not know about. However, they should reject addresses that have a different length than specified in the table for a specific address ID. The addrv2 messages should only be sent to peers with a certain protocol version or higher.The document lists various considerations that need further discussion, such as gossiping addresses outside a certain overlay network, the lower precision of the time field, rolling port into addr, or making the port optional. It is noted that the reference implementation is not yet available.
Updated on: 2023-08-02T00:30:54.606027+00:00