1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
Return-Path: <john@johnnewbery.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 75D0BC013B
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Dec 2020 10:16:25 +0000 (UTC)
Received: by mail-lf1-f50.google.com with SMTP id y19so7354441lfa.13
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>
(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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <john@johnnewbery.com>
Date: Thu, 10 Dec 2020 09:47:54 +0000
X-Gmail-Original-Message-ID: <CAFmfg2sSV=F0c1UXu5pi-6YxvvkG4n1BpGbR2Ysz89cA8=HkVw@mail.gmail.com>
Message-ID: <CAFmfg2sSV=F0c1UXu5pi-6YxvvkG4n1BpGbR2Ysz89cA8=HkVw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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"
<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'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&type=Issues" target="_blank">https://github.com/bitcoin/bips/search?q=addrv2+is%3Apr&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--
|
