summaryrefslogtreecommitdiff
path: root/06/0bb4a940dde194190e90840bb3efec7f46d0a5
blob: 7a28372400df73e19c53d034aa9a5a064e09111b (plain)
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
Return-Path: <eric@voskuil.org>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4079CC0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 04:31:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 2726C88650
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 04:31:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fHAM9VMUg6AU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 04:31:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com
 [209.85.217.49])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 4B59F88642
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 04:31:00 +0000 (UTC)
Received: by mail-vs1-f49.google.com with SMTP id r7so216578vsq.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Aug 2020 21:31:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20150623.gappssmtp.com; s=20150623;
 h=content-transfer-encoding:from:mime-version:subject:date:message-id
 :references:cc:in-reply-to:to;
 bh=uPv6TbVPz2mJZmx+d29NzowPvlk1FW2ahb1OQx5U6gI=;
 b=PAQU7etb11SxxI2oYlCeqt2ai3pxmKxOKrclD1rjl/9anIG00oB78dfjpTIzndB/sL
 cfW6cJpIYIgLSA5S04DgBmOO6ZRb9qUpKRhiTF/mDS1ZOM1L3i/8mn5Ds901HWBjUNK7
 yd37aWLzRsgNb7dLwIDyK/pkp4FzyS6WD06rYoZQFdM0mnpbXOq50Arl09QY0MWfE0SS
 LT1tMlkiptlxs8Z1BGZe3SmVSRB5TYpgyFfscW94FStIcNPdheRiMW5UvVRAkjuiIyb7
 H7kHwx5aslzkBPZNvygU72MqxtN7MOhjfw1RDs+YiwAQNot4RY09EBl9HfZGiFpnJ294
 tpZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version
 :subject:date:message-id:references:cc:in-reply-to:to;
 bh=uPv6TbVPz2mJZmx+d29NzowPvlk1FW2ahb1OQx5U6gI=;
 b=uHTKJcfMWEKnW1RYHP+C0++QuSZeWdIOSiRLwJ3QM2vbHa2syHBF3AzITppziYeAhx
 Yxp9rNl7u59HPlgOuorXRWCOG2Zl8F4Wr+azM0U7FN/bye9ZAOzyznI3DfWr6bh8Ri0E
 UEVUJ6X//sCb9Uuny1lYvC4iLtv5+/3psDLKjnJrSdWeu8BEa3aauZl0uZiUJM4tE+hh
 JfZsQSHCzf4DvtIBIZDIhjmfIvFGVpb0w3zXqvuX2la4Kex9sd1UWLvYVdHxiJyuINyk
 rOTuvwKl92FRjMgDOwHX83A8VuEe7JM7cc/ZaZkNDJeDOzZK7pPp6UKYjZXiygiVO5OI
 Eewg==
X-Gm-Message-State: AOAM531+zmc7iJc+bi/BjcO1zMg4ppiaLp8KSWdmQpaUnriCX/ZN7EbW
 h4YP/+AKpQF9xUa6pAZx5IiaYQLMW7ADJQ==
X-Google-Smtp-Source: ABdhPJzCzCALHrdSXrV7KLIl+XG6IwZ3NdKw/pvjlwp29ez/dFX5UEYn369b2+mg/wyHX6LUP3yzOw==
X-Received: by 2002:a17:902:b497:: with SMTP id
 y23mr846846plr.251.1597983909971; 
 Thu, 20 Aug 2020 21:25:09 -0700 (PDT)
Received: from ?IPv6:2600:380:7066:ce6e:7435:a47f:2958:b337?
 ([2600:380:7066:ce6e:7435:a47f:2958:b337])
 by smtp.gmail.com with ESMTPSA id h18sm735746pfo.21.2020.08.20.21.25.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2020 21:25:09 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 20 Aug 2020 21:25:08 -0700
Message-Id: <D8D5CF3A-27AE-4000-BECB-9926DCF7CB4C@voskuil.org>
References: <20200821023647.7eat4goqqrtaqnna@erisian.com.au>
In-Reply-To: <20200821023647.7eat4goqqrtaqnna@erisian.com.au>
To: Anthony Towns <aj@erisian.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (17G68)
X-Mailman-Approved-At: Fri, 21 Aug 2020 08:00:08 +0000
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: Fri, 21 Aug 2020 04:31:01 -0000

Hi Anthony,

This is what I was implying in my last post (the reference to the unnecessar=
y overload of message typing). However, if one imagines a sequence diagram f=
or this communication it becomes obvious that all such messages are 100% red=
undant with verack.

e

> On Aug 20, 2020, at 19:37, Anthony Towns via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>=20
> =EF=BB=BFOn Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitco=
in-dev wrote:
>> 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 unkno=
wn
>> messages received before a VERACK.  A draft of my proposal is available h=
ere
>> [2].
>=20
> Rather than allowing arbitrary messages, maybe it would make sense to
> have a specific feature negotiation message, eg:
>=20
>  VERSION ...
>  FEATURE wtxidrelay
>  FEATURE packagerelay
>  VERACK
>=20
> with the behaviour being that it's valid only between VERSION and VERACK,
> and it takes a length-prefixed-string giving the feature name, optional
> additional data, and if the feature name isn't recognised the message
> is ignored.
>=20
> If we were to support a "polite disconnect" feature like Jeremy suggested,=

> it might be easier to do that for a generic FEATURE message, than
> reimplement it for the message proposed by each new feature.
>=20
> Cheers,
> aj
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev