John Newbery [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-10 📝 Original message:Hi folks, BIP 155 was ...
📅 Original date posted:2020-12-10
📝 Original message:Hi folks,
BIP 155 was proposed[1] in Feb 2019 by Wladimir van der Laan as a way of
gossipping longer node addresses over the Bitcoin P2P network, primarily
to support torv3 and other networks.
In the time since that initial mailing list post, several changes have
been made to the proposal. Discussion has been held on the BIPs repo[2],
and (for implementation issues) the Bitcoin Core repo[3].
This email summarizes the changes. Readers should refer to BIP 155[4]
for the full specification.
### Specification changes
1. The `time` field in the `addrv2` message is now stored as a fixed
length uint32 instead of a variable-length compact size.
2. The `addr` field may be up to a maximum of 512 bytes (4096 bits)
instead of 32 bytes (256 bits) for compatibility with future address
formats.
3. Clients now SHOULD gossip addresses for known networks (even if they
can't connect to those networks). They SHOULD NOT gossip addresses
for unknown networks. They SHOULD also ignore addresses for known
networks that are different from the address length for that network
specified in BIP 155.
4. New network IDs MUST be reserved in a BIP document.
5. Support for `addrv2` is not dependent on a p2p protocol version.
A new message type `sendaddrv2` is introduced to signal support
for addrv2. To signal support for addrv2, this message MUST be sent
after the initial version message is sent and before the verack
message is sent.
### Implementation detail
During testing of the Bitcoin Core implementation, it was found that
another Bitcoin implementation would disconnect from peers on receipt of
an unknown message[5]. I believe that to be an incorrect interpretation
of the Bitcoin p2p protocol. The original v0.1 Satoshi client (and all
Bitcoin Core versions derived from it) have always explicitly ignored
unknown message types as a mechanism to extend the p2p protocol[6]. This
property allows p2p implementions to permissionlessly deploy opt-in
extensions to the protocol.
As a pragmatic step to prevent those implementations from being
disconnected from v0.21 Bitcoin Core nodes, this initial version will
_only_ send sendaddrv2 messages to peers on p2p protocol version 70016
and higher. This behaviour may be reverted in future, at which point
Bitcoin Core would send sendaddrv2 messages to all peers during the
version/verack handshake.
Thanks to everyone who has contributed to the addrv2
spec/implementation.
John
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016687.html
[2] https://github.com/bitcoin/bips/search?q=addrv2+is%3Apr&type=Issues
[3] https://github.com/bitcoin/bitcoin/pull/20564
[4] https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
[5] https://github.com/btcsuite/btcd/issues/1661
[6] https://github.com/benjyz/bitcoinArchive/blob/master/bitcoin0.1/src/main.cpp#L2035-L2039
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201210/b6445a1c/attachment.html>;
📝 Original message:Hi folks,
BIP 155 was proposed[1] in Feb 2019 by Wladimir van der Laan as a way of
gossipping longer node addresses over the Bitcoin P2P network, primarily
to support torv3 and other networks.
In the time since that initial mailing list post, several changes have
been made to the proposal. Discussion has been held on the BIPs repo[2],
and (for implementation issues) the Bitcoin Core repo[3].
This email summarizes the changes. Readers should refer to BIP 155[4]
for the full specification.
### Specification changes
1. The `time` field in the `addrv2` message is now stored as a fixed
length uint32 instead of a variable-length compact size.
2. The `addr` field may be up to a maximum of 512 bytes (4096 bits)
instead of 32 bytes (256 bits) for compatibility with future address
formats.
3. Clients now SHOULD gossip addresses for known networks (even if they
can't connect to those networks). They SHOULD NOT gossip addresses
for unknown networks. They SHOULD also ignore addresses for known
networks that are different from the address length for that network
specified in BIP 155.
4. New network IDs MUST be reserved in a BIP document.
5. Support for `addrv2` is not dependent on a p2p protocol version.
A new message type `sendaddrv2` is introduced to signal support
for addrv2. To signal support for addrv2, this message MUST be sent
after the initial version message is sent and before the verack
message is sent.
### Implementation detail
During testing of the Bitcoin Core implementation, it was found that
another Bitcoin implementation would disconnect from peers on receipt of
an unknown message[5]. I believe that to be an incorrect interpretation
of the Bitcoin p2p protocol. The original v0.1 Satoshi client (and all
Bitcoin Core versions derived from it) have always explicitly ignored
unknown message types as a mechanism to extend the p2p protocol[6]. This
property allows p2p implementions to permissionlessly deploy opt-in
extensions to the protocol.
As a pragmatic step to prevent those implementations from being
disconnected from v0.21 Bitcoin Core nodes, this initial version will
_only_ send sendaddrv2 messages to peers on p2p protocol version 70016
and higher. This behaviour may be reverted in future, at which point
Bitcoin Core would send sendaddrv2 messages to all peers during the
version/verack handshake.
Thanks to everyone who has contributed to the addrv2
spec/implementation.
John
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016687.html
[2] https://github.com/bitcoin/bips/search?q=addrv2+is%3Apr&type=Issues
[3] https://github.com/bitcoin/bitcoin/pull/20564
[4] https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
[5] https://github.com/btcsuite/btcd/issues/1661
[6] https://github.com/benjyz/bitcoinArchive/blob/master/bitcoin0.1/src/main.cpp#L2035-L2039
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201210/b6445a1c/attachment.html>;