MIME-Version: 1.0
From: John Newbery <john@johnnewbery.com>
Date: Thu, 10 Dec 2020 09:47:54 +0000
Message-ID: <CAFmfg2sSV=F0c1UXu5pi-6YxvvkG4n1BpGbR2Ysz89cA8=HkVw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009377d605b61912ba"
Subject: [bitcoin-dev] BIP 155 (addrv2) update - spec and Bitcoin Core v0.21
	implementation
Precedence: list

--0000000000009377d605b61912ba
Content-Type: text/plain; charset="UTF-8"

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

--0000000000009377d605b61912ba
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">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&#39;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] <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016687.html" target="_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016687.html</a>
[2] <a href="https://github.com/bitcoin/bips/search?q=addrv2+is%3Apr&amp;type=Issues" target="_blank">https://github.com/bitcoin/bips/search?q=addrv2+is%3Apr&amp;type=Issues</a>
[3] <a href="https://github.com/bitcoin/bitcoin/pull/20564" target="_blank">https://github.com/bitcoin/bitcoin/pull/20564</a>
[4] <a href="https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki" target="_blank">https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki</a>
[5] <a href="https://github.com/btcsuite/btcd/issues/1661" target="_blank">https://github.com/btcsuite/btcd/issues/1661</a>
[6] <a href="https://github.com/benjyz/bitcoinArchive/blob/master/bitcoin0.1/src/main.cpp#L2035-L2039" target="_blank">https://github.com/benjyz/bitcoinArchive/blob/master/bitcoin0.1/src/main.cpp#L2035-L2039</a></pre></div>

--0000000000009377d605b61912ba--