summaryrefslogtreecommitdiff
path: root/4d/fcb6c7555eb745e25ef9725fec2f9409e2ed7e
blob: edacd9f538a3754a20f01ec9c32b694276d09d18 (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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
Return-Path: <sdaftuar@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8B702C004D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Aug 2020 19:28:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 78ACB87763
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Aug 2020 19:28:55 +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 vuXaOuIGwqgV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Aug 2020 19:28:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com
 [209.85.166.42])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 8719287524
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Aug 2020 19:28:54 +0000 (UTC)
Received: by mail-io1-f42.google.com with SMTP id u126so11753988iod.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Aug 2020 12:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=sWIMrKgKBc5UqI/YLh7mOxRTmgwCbDhPDDmPiyjX/YI=;
 b=UlzmyUeyjUlASqVc2Lgq5T3n44MZLqvXpw2zPfUezLe3OjOgaLTBPPoPSJ3Ibyf7v2
 7SJyteVSKggsxM3Brp8Ep5L1VohvgdXjDkhie9CSLv0EGJYvBjTeXDXcMQVmn4ZGUYdK
 slCNmmn+Wrxlpq46p6mlxEWDgyGBI1kTjmbvjYp5+kXNNx9AbTkoJfBBLkiAP7YopNXg
 aX/RwswzL9/PxCeQ3f+NSKjwFQunAPeQ+WAWzV8oqv0stxf3UakEaNW6j76vWL+S3KcD
 Sm1Rq4Co26k/tjE0mKfnRxl4NaUm7G8iPAra+BfVSYNRv6S4FON8Sdcmsdi9g3GifRAn
 jpqw==
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=sWIMrKgKBc5UqI/YLh7mOxRTmgwCbDhPDDmPiyjX/YI=;
 b=TpborjCouLH6F9q3ZdgfC2y9pg73oT+6tLue0oKQBO3UToRAg7VJW9LnzFogZy+2wJ
 14EwGiioiyZEoUxJV8v6iaaDj1pT9WRoPAL3h60NilttXVWLqPwHh542IMuPoHlDkJMX
 696WaeTNIGLwkypdONtYy6cHOUzXYSRbEQ3xtzRrYYEyUO+HkKZmyD2rQh9mf/xbEfjd
 G1JZAl7pjTX65NKmQK9K06q4ZGRwV6M//XYuaeZSHsUtoECG16TRypVm3OZd4A+3HRDH
 +2NKFui7lj7xMSDv2fUTqpaOKj2tFqRWuyxgq0UxRIKGoX9C2x+AALZv5ZJADb5v8pKF
 cOjQ==
X-Gm-Message-State: AOAM533+bSt2aKfokmUhKNblsraMoK01IgPJ0yMg5vyzmbLYBrjcJ+qm
 MpJMG/WVYdwxY8WNUr3isCkXLg+Lql6Io6fBo0iZFLmiSUfn2w==
X-Google-Smtp-Source: ABdhPJyFt6Cg8t4ykl7o9bAu0pjLoflg2dxLh6gEbBvzrmjcpxi0qOgxPpAkvl/FqStkZOtxgpKhPJePYqFILh+3pMk=
X-Received: by 2002:a5e:8c02:: with SMTP id n2mr3377470ioj.143.1597433333024; 
 Fri, 14 Aug 2020 12:28:53 -0700 (PDT)
MIME-Version: 1.0
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Fri, 14 Aug 2020 15:28:41 -0400
Message-ID: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005e0e4605acdb6eab"
Subject: [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, 14 Aug 2020 19:28:55 -0000

--0000000000005e0e4605acdb6eab
Content-Type: text/plain; charset="UTF-8"

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

[2]
https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki

--0000000000005e0e4605acdb6eab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Back in February I posted a proposa=
l for WTXID-based transaction relay[1] (now known as BIP 339), which includ=
ed a proposal for feature negotiation to take place prior to the VERACK mes=
sage being received by each side.=C2=A0 In my email to this list, I had ask=
ed for feedback as to whether that proposal was problematic, and didn&#39;t=
 receive any responses.</div><div><br></div><div>Since then, the implementa=
tion=C2=A0of BIP 339 has been merged into Bitcoin Core, though it has not y=
et been released.</div><div><br></div><div>In thinking about the mechanism =
used there, I thought it would=C2=A0be helpful to codify in a BIP the idea =
that Bitcoin network clients should ignore unknown messages received before=
 a VERACK.=C2=A0 A draft of my proposal is available here[2].</div><div><br=
></div><div>I presume that software upgrading past protocol version 70016 w=
as already planning to either implement BIP 339, or ignore the wtxidrelay m=
essage proposed in BIP 339 (if not, then this would create network split co=
ncerns in the future -- so I hope that someone would speak up if this were =
a problem).=C2=A0 When we propose future protocol upgrades that would benef=
it 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.=C2=A0 So having an understanding tha=
t this is the standard of how other network clients operate would be helpfu=
l.</div><div><br></div><div>If, on the other hand, this is problematic for =
some reason, I look forward to hearing that as well, so that we can be care=
ful about how we deploy future p2p changes to avoid disruption.</div><div><=
br></div><div>Thanks,</div><div>Suhas Daftuar</div><div><br></div><div>[1]=
=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
20-February/017648.html">https://lists.linuxfoundation.org/pipermail/bitcoi=
n-dev/2020-February/017648.html</a><br></div><div><br></div><div>[2]=C2=A0<=
a href=3D"https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature=
-negotiation/bip-p2p-feature-negotiation.mediawiki">https://github.com/sdaf=
tuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-nego=
tiation.mediawiki</a></div></div>

--0000000000005e0e4605acdb6eab--