From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 75D0BC013B for ; Thu, 10 Dec 2020 10:16:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 70DDC20341 for ; Thu, 10 Dec 2020 10:16:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DKD3jOX1mgG for ; Thu, 10 Dec 2020 10:16:26 +0000 (UTC) X-Greylist: delayed 00:28:17 by SQLgrey-1.7.6 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by silver.osuosl.org (Postfix) with ESMTPS id C92E52033F for ; Thu, 10 Dec 2020 10:16:25 +0000 (UTC) Received: by mail-lf1-f50.google.com with SMTP id y19so7354441lfa.13 for ; Thu, 10 Dec 2020 02:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnewbery-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=LSTDMfsokfT322B2zleLLb9MbxPCWkEBrG8tyxjsF7w=; b=knk+hAuZSdKN/mF3nUtuBE6cJVLjHX3p6ZXn4xOOuVhQvpsE9XY4INl1m3GfocY1ZK bu7036XxoCZmqpNRFeuv7iARabh8i/IUF81s8R5MTle6KTfD+dNhiFGQeSSQmVE+HXU+ JhLXRZwZwxVzUqWh1H9i1Ys50LXkF2nQ05P7wP73R1mSAJlITyY85jw76zKyqem+104g cXixLNmvdSCqgX2WDn6rv4a8hMhNPXAdMWP1LvX40fHc4g+oeKUThAsPWfbhdxYdGbF7 GwlhkI6hImbC8T+mRSDkO5Fzilpf9+RcJJm5HmT84gaOoMIOnpTw95Umn21wxC+ma6s5 RS8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LSTDMfsokfT322B2zleLLb9MbxPCWkEBrG8tyxjsF7w=; b=h+ajGae+NYgiQ/U+UWa9JXBaSCMHvNQu4C0N/WGmBx/8LNSGOhdoXAGIN9hqQAs/14 E9kYlQJqPfDHdHHsmb38GjnVgNHczt2vC+KmS5Tb98Qm24GUfDH1mPl0mV73ED4ECpUr 5hkC3siiuhs73DkiipH+4n1OB50HhG2zZA0IgPrAQXATPAhhDfKNm72IpucVgXzLVn39 AbIcxiYDLlw5++AlBnmOLP+VGjN8diOGu46eW6Eon3nSpTEMR89Pv+Wyh2XiRyQORP+J hbfqRx4yCTKeDrA0Psiq2VNhkGiteeazeaANea6SCdbfRZpXc6PFKN1bbwXo94Da4Tl0 QQzQ== X-Gm-Message-State: AOAM53153gts60bvkjsU4xNO7Wq7+BvBaWZRlf72b/6kDSwskB/oy6QG E3Ipfjtl8imYTmRsFOYX6yUXVQUezCT2NML8 X-Google-Smtp-Source: ABdhPJyzWEg6TrVPtIeUXl8Y+4UTGOxX+lPBU1ijrp0zXajIQVgodHCDbWCYTwJEb7dsSsDO3WrqZw== X-Received: by 2002:ac2:599b:: with SMTP id w27mr977805lfn.420.1607593686695; Thu, 10 Dec 2020 01:48:06 -0800 (PST) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com. [209.85.167.41]) by smtp.gmail.com with ESMTPSA id a3sm458276lfr.97.2020.12.10.01.48.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 01:48:06 -0800 (PST) Received: by mail-lf1-f41.google.com with SMTP id u18so7274884lfd.9 for ; Thu, 10 Dec 2020 01:48:05 -0800 (PST) X-Received: by 2002:a05:6512:1143:: with SMTP id m3mr740576lfg.1.1607593685643; Thu, 10 Dec 2020 01:48:05 -0800 (PST) MIME-Version: 1.0 From: John Newbery Date: Thu, 10 Dec 2020 09:47:54 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000009377d605b61912ba" X-Mailman-Approved-At: Thu, 10 Dec 2020 10:21:49 +0000 Subject: [bitcoin-dev] BIP 155 (addrv2) update - spec and Bitcoin Core v0.21 implementation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 10:16:27 -0000 --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" 
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--