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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id ADC68C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2020 14:59:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id A8CFC845D1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2020 14:59:05 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id r27o_NZ_j6pI
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2020 14:59:03 +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 fraxinus.osuosl.org (Postfix) with ESMTPS id AE80084493
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2020 14:59:03 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with ESMTPSA id 31D1A2E72E9;
Tue, 18 Aug 2020 14:59:01 +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=1597760464; t=1597762741;
bh=Yd1ORamHXsrgTtar9sQJqODT/i5vbCis3HuAY930SHs=;
h=Subject:To:References:From:Date:In-Reply-To:From;
b=FqrQKWHw1sZc1zF3c+zlZbBdOGuTB4ILZek2qRWmGd6ugphCcruB5a4BD/AWsEgGS
gnsU71fBDLsIpeHy75QseaQSPIyoJnEUJkgBStYdpoACpWe7BVgugcFV4gQ/lAtI7G
OkwnTSwjnhsATxok2j9onaO29jg22EEcY8XEL3GsyTFJcmujN8O/FvRbOYp7YlcijW
FiNw3wTgsTdPLIUs/CHReE2RWZdEvQbau8tOXdg9izc8LVfa8eYKHjL+UjRsYcl3l2
VFTpRQtOEMWLm1m5BVrphMQZNxm+rjdtiTzcekAoEvuAZHqxEPgoLRhuyS3DkLyXGc
FvZc51IOMKNjQ==
To: Suhas Daftuar <sdaftuar@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <8a7031f2-a598-ac09-f2df-1672cd82980b@mattcorallo.com>
Date: Tue, 18 Aug 2020 10:59:00 -0400
MIME-Version: 1.0
In-Reply-To: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
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 14:59:05 -0000
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
>
|
