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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 41822C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2020 17:26:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 2E81B865CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2020 17:26:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id KDSDouj6kpi4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2020 17:26:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by whitealder.osuosl.org (Postfix) with ESMTPS id AB349865C1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2020 17:26:40 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with ESMTPSA id 70E8C2E77CD;
Tue, 18 Aug 2020 17:26:37 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
s=1597770064; t=1597771597;
bh=9nyqG3cD7rxVJC/0Aq4tQjF2itm3unj+xHEbHrMNw04=;
h=Subject:To:Cc:References:From:Date:In-Reply-To:From;
b=iERDdCsLOZS7dfexZbdu8hjNDLyXXbVdUKk8PhMFxUSYLU88sWKeWR5lTlQiIEpkr
7c/rcIdWznFDG/ZmCuSwB8SWdJ2zz3JL1bC/oyBKplaoUxq30s68NC1bZR898IilT4
78Ki3UCKRTlEABShOhrEA0glLix80ar5s6VfiIYmjrTP4JkIJzEIhWhaieAni9orbh
6gCVx3vJKf4GB+ynsCfQf8lvlK97+/nAPJWJqwd/1YM8ePAsaN9iMpvA11tZlJhdSv
AC8EcNUBCTjQ5y2CGuOEYhvLBvEn7XRmpez2w08LnUql7nE2JKa6dDCGIg+a5d1Ofo
5Mrrd0E5OJjZw==
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <8a7031f2-a598-ac09-f2df-1672cd82980b@mattcorallo.com>
<84F1FD44-0482-4F77-8FFA-65492E445D23@voskuil.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <6ccf6ff8-6b4f-c8f4-0dbb-36c5d076528f@mattcorallo.com>
Date: Tue, 18 Aug 2020 13:26:36 -0400
MIME-Version: 1.0
In-Reply-To: <84F1FD44-0482-4F77-8FFA-65492E445D23@voskuil.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p
connections are setup
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: Tue, 18 Aug 2020 17:26:42 -0000
There are several cases where a new message has been sent as a part of a negotiation without changing the protocol
version. You may chose to ignore that, but that doesn't mean that it isn't an understood and even relied upon feature of
the Bitcoin P2P protocol. If you wish to fail connections to new nodes (and risk network splits, as Suhas points out),
then you may do so, but that doesn't make it a part of the Bitcoin P2P protocol that you must do so. Of course there is
no "official document" by which we can make a formal appeal, but historical precedent suggests otherwise.
Still, I think we're talking pedantics here, and not in a useful way. Ultimately we need some kind of negotiation which
is flexible in allowing different software to negotiate different features without a global lock-step version number
increase. Or, to put it another way, if a feature is fully optional, why should there be a version number increase for
it - the negotiation of it is independent and a version number only increases confusion over which change "owns" a given
version number.
I presume you'd support a single message that lists the set of features which a node (optionally) wishes to support on
the connection. This proposal is fully equivalent to that, instead opting to list them as individual messages instead of
one message, which is a bit nicer in that they can be handled more independently or by different subsystems including
even the message hashing.
Matt
On 8/18/20 12:54 PM, Eric Voskuil wrote:
> “Bitcoin protocol has always expected clients to ignore unknown messages”
>
> This is not true. Bitcoin has long implemented version negotiation, which is the opposite expectation. Libbitcoin’s p2p
> protocol implementation immediately drops a peer that sends an invalid message according to the negotiated version. The
> fact that a given client does not validate the protocol does not make it an expectation that the protocol not be validated.
>
> Features can clearly be optional within an actual protocol. There have been post-handshake negotiations implemented for
> optional messages which are valid at the negotiated version. The protocol may be flexible while remaining validateable.
> There is no reason to force a client to accept unknown message traffic.
>
> A generalized versioning change can be implemented in or after the handshake. The latter is already done on an ad-hoc
> basis. The former is possible as long as the peer’s version is sufficient to be aware of the behavior. This does not
> imply any need to send invalid messages. The verack itself can simply be extended with a matrix of feature support.
> There is no reason to complicate negotiation with an additional message(s).
>
> FWIW, bip37 did this poorly, adding a feature field to the version message, resulting in bip60. Due to this design,
> older protocol-validating clients were broken. In this case it was message length that was presumed to not be validated.
>
> e
>
>> On Aug 18, 2020, at 07:59, Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> This sounds like a great idea!
>>
>> Bitcoin is no longer a homogeneous network of one client - it is many, with different features implemented in each.
>> The Bitcoin protocol hasn't (fully) evolved to capture that reality. Initially the Bitcoin protocol had a simple
>> numerical version field, but that is wholly impractical for any diverse network - some clients may not wish to
>> implement every possible new relay mechanic, and why should they have to in order to use other new features?
>>
>> Bitcoin protocol changes have, many times in recent history, been made via new dummy "negotiation" messages, which
>> take advantage of the fact that the Bitcoin protocol has always expected clients to ignore unknown messages. Given
>> that pattern, it makes sense to have an explicit negotiation phase - after version and before verack, just send the
>> list of features that you support to negotiate what the connection will be capable of. The exact way we do that
>> doesn't matter much, and sending it as a stream of messages which each indicate support for a given protocol feature
>> perfectly captures the pattern that has been used in several recent network upgrades, keeping consistency.
>>
>> Matt
>>
>> On 8/14/20 3:28 PM, Suhas Daftuar via bitcoin-dev wrote:
>>> Hi,
>>> Back in February I posted a proposal for WTXID-based transaction relay[1] (now known as BIP 339), which included a
>>> proposal for feature negotiation to take place prior to the VERACK message being received by each side. In my email
>>> to this list, I had asked for feedback as to whether that proposal was problematic, and didn't receive any responses.
>>> Since then, the implementation of BIP 339 has been merged into Bitcoin Core, though it has not yet been released.
>>> In thinking about the mechanism used there, I thought it would be helpful to codify in a BIP the idea that Bitcoin
>>> network clients should ignore unknown messages received before a VERACK. A draft of my proposal is available here[2].
>>> I presume that software upgrading past protocol version 70016 was already planning to either implement BIP 339, or
>>> ignore the wtxidrelay message proposed in BIP 339 (if not, then this would create network split concerns in the
>>> future -- so I hope that someone would speak up if this were a problem). When we propose future protocol upgrades
>>> that would benefit from feature negotiation at the time of connection, I think it would be nice to be able to use the
>>> same method as proposed in BIP 339, without even needing to bump the protocol version. So having an understanding
>>> that this is the standard of how other network clients operate would be helpful.
>>> If, on the other hand, this is problematic for some reason, I look forward to hearing that as well, so that we can be
>>> careful about how we deploy future p2p changes to avoid disruption.
>>> Thanks,
>>> Suhas Daftuar
>>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html
>>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html>
>>> [2]
>>> https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki
>>> <https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
