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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 287F59B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 13:14:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6032F14D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Feb 2017 13:14:16 +0000 (UTC)
Received: from [100.150.167.205] (unknown [172.56.12.208])
by mail.bluematt.me (Postfix) with ESMTPSA id 79D8013761C;
Mon, 13 Feb 2017 13:14:12 +0000 (UTC)
Date: Mon, 13 Feb 2017 13:04:15 +0000
In-Reply-To: <0983c823-e517-2821-1398-24bc7467b364@voskuil.org>
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
<CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
<dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org>
<424C9E40-0B90-46A6-9C5E-30AE3E84E119@mattcorallo.com>
<9ca02a65-23df-5eb4-f9bd-7e05b54ec4ea@voskuil.org>
<9ECDD902-1D2C-4500-8FC2-4DADF46E4318@mattcorallo.com>
<0983c823-e517-2821-1398-24bc7467b364@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Pieter Wuille <pieter.wuille@gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <D863B756-565E-46A2-9731-2B8133653823@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: libbitcoin@lists.dyne.org
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Mon, 13 Feb 2017 13:14:17 -0000
Sorry, I'm still missing it=2E=2E=2E
So your claim is that a) ignoring incoming messages of a type you do not r=
ecognize is bad, and thus b) we should be disconnecting/banning peers which=
send us messages we do not recognize (can you spell out why? Anyone is fre=
e to send your host address messages/transactions they are generating/etc/e=
tc, we don't ban nodes for such messages, as that would be crazy - why shou=
ld we ban a peer for sending us an extra 50 bytes which we ignore?), and th=
us c) this would be backwards incompatible with software which does not cur=
rently exist?
Usually "backwards incompatible" refers to breaking existing software, not=
breaking theoretical software=2E Note that, last I heard, BIP 151 is still=
a draft, if such software actually exists we can discuss changing it, but =
there are real wins in sending these messages before VERSION=2E
On February 13, 2017 12:17:11 PM GMT+01:00, Eric Voskuil <eric@voskuil=2Eo=
rg> wrote:
>On 02/13/2017 03:11 AM, Matt Corallo wrote:
>> I believe many, if not all, of those messages are sent irrespective
>of version number=2E
>
>In the interest of perfect clarity, see your code:
>
>https://github=2Ecom/bitcoin/bitcoin/blob/master/src/net_processing=2Ecpp=
#L1372-L1403
>
>Inside of the VERACK handler (i=2Ee=2E after the handshake) there is a pe=
er
>version test before sending SENDCMPCT (and SENDHEADERS)=2E
>
>I have no idea where the fee filter message is sent, if it is sent at
>all=2E But I have *never* seen any control messages arrive before the
>handshake is complete=2E
>
>> In any case, I fail to see how adding any additional messages which
>are ignored by old peers amounts to a lack of backward compatibility=2E
>
>See preceding messages in this thread, I think it's pretty clearly
>spelled out=2E
>
>e
>
>> On February 13, 2017 11:54:23 AM GMT+01:00, Eric Voskuil
><eric@voskuil=2Eorg> wrote:
>>> On 02/13/2017 02:16 AM, Matt Corallo wrote:
>>>> For the reasons Pieter listed, an explicit part of our version
>>> handshake and protocol negotiation is the exchange of
>otherwise-ignored
>>> messages to set up optional features=2E
>>>
>>> Only if the peer is at the protocol level that allows the message:
>>>
>>> compact blocks:
>>>
>>>
>https://github=2Ecom/bitcoin/bitcoin/blob/master/src/protocol=2Eh#L217-L2=
42
>>>
>>> fee filter:
>>>
>>>
>https://github=2Ecom/bitcoin/bitcoin/blob/master/src/protocol=2Eh#L211-L2=
16
>>>
>>> send headers:
>>>
>>>
>https://github=2Ecom/bitcoin/bitcoin/blob/master/src/protocol=2Eh#L204-L2=
10
>>>
>>> filters:
>>>
>>>
>https://github=2Ecom/bitcoin/bitcoin/blob/master/src/protocol=2Eh#L170-L1=
96
>>>
>>>> Peers that do not support this ignore such messages, just as if
>they
>>> had indicated they wouldn't support it, see, eg BIP 152's handshake=2E
>>> Not
>>> sure why you consider this backwards incompatible, as I would say
>it's
>>> pretty clearly allowing old nodes to communicate just fine=2E
>>>
>>> No, it is not the same as BIP152=2E Control messages apart from BIP151
>>> are
>>> not sent until *after* the version is negotiated=2E
>>>
>>> I assume that BIP151 is different in this manner because it has a
>>> desire
>>> to negotiate encryption before any other communications, including
>>> version=2E
>>>
>>> e
|
