path: root/15/6a6675c1b84ea89235a949ab1ec480ee389159

Return-Path: <jlrubin@mit.edu>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F0A21C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 19:50:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id D2515230FB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 19:50:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id RYrlYi1sO8kB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 19:50:37 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by silver.osuosl.org (Postfix) with ESMTPS id 2D2542045D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 19:50:36 +0000 (UTC)
Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com
 [209.85.218.46]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07LJoY1Y030422
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 21 Aug 2020 15:50:35 -0400
Received: by mail-ej1-f46.google.com with SMTP id o18so3731650eje.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 12:50:35 -0700 (PDT)
X-Gm-Message-State: AOAM533C5hTDOWgUSViYvyurNJ/JdaNaaRXrSLh9AqU8tuMizF/c0vg8
 KauPAFlqaZfs0E/ed0A7EM/QatrMA5IG1k+rSNM=
X-Google-Smtp-Source: ABdhPJz0zS3pyZr8NsquHiJHvp0Y+a6LESZFQj7bCZ6aYXBFzX9LKJ7d+hUlqrpZ8F1/9DtXXhymKTG6qgs59PvjUfU=
X-Received: by 2002:a17:906:b814:: with SMTP id
 dv20mr4582111ejb.4.1598039434207; 
 Fri, 21 Aug 2020 12:50:34 -0700 (PDT)
MIME-Version: 1.0
References: <A26FA2BC-50E5-4635-95E4-56AAA969C9DA@mattcorallo.com>
 <B514142F-382B-4D49-B68D-0115ECBD1D79@voskuil.org>
In-Reply-To: <B514142F-382B-4D49-B68D-0115ECBD1D79@voskuil.org>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 21 Aug 2020 12:50:21 -0700
X-Gmail-Original-Message-ID: <CAD5xwhi9zVp3nOhFy3Hia_Md++Gdz+F5Kat_bbbZwBcmPhMGZA@mail.gmail.com>
Message-ID: <CAD5xwhi9zVp3nOhFy3Hia_Md++Gdz+F5Kat_bbbZwBcmPhMGZA@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d028a405ad688c88"
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 19:50:39 -0000

--000000000000d028a405ad688c88
Content-Type: text/plain; charset="UTF-8"

I have a proposal:

Protocol >= 70016 cease to send or process VERACK, and instead use
HANDSHAKEACK, which is completed after feature negotiation.

This should make everyone happy/unhappy, as in a new protocol number it's
fair game to change these semantics to be clear that we're acking more than
version.

I don't care about when or where these messages are sequenced overall, it
seems to have minimal impact. If I had free choice, I slightly agree with
Eric that verack should come before feature negotiation, as we want to
divorce the idea that protocol number and feature support are tied.

But once this is done, we can supplant Verack with HANDSHAKENACK or
HANDSHAKEACK to signal success or failure to agree on a connection. A NACK
reason (version too high/low or an important feature missing) could be
optional. Implicit NACK would be disconnecting, but is discouraged because
a peer doesn't know if it should reconnect or the failure was intentional.

------

AJ: I think I generally do prefer to have a FEATURE wrapper as you
suggested, or a rule that all messages in this period are interpreted as
features (and may be redundant with p2p message types -- so you can
literally just use the p2p message name w/o any data).

I think we would want a semantic (which could be based just on message
names, but first-class support would be nice) for ACKing that a feature is
enabled. This is because a transcript of:

NODE0:
FEATURE A
FEATURE B
VERACK

NODE1:
FEATURE A
VERACK

It remains unclear if Node 1 ignored B because it's an unknown feature, or
because it is disabled. A transcript like:

NODE0:
FEATURE A
FEATURE B
FEATURE C
ACK A
VERACK

NODE1:
FEATURE A
ACK A
NACK B
VERACK

would make it clear that A and B are known, B is disabled, and C is
unknown. C has 0 support, B Node 0 should support inbound messages but
knows not to send to Node 1, and A has full bilateral support. Maybe
instead it could a message FEATURE SEND A and FEATURE RECV A, so we can
make the split explicit rather than inferred from ACK/NACK.


------

I'd also propose that we add a message which is SYNC, which indicates the
end of a list of FEATURES and a request to send ACKS or NACKS back (which
are followed by a SYNC). This allows multi-round negotiation where based on
the presence of other features, I may expand the set of features I am
offering. I think you could do without SYNC, but there are more edge cases
and the explicitness is nice given that this already introduces future
complexity.

This multi-round makes it an actual negotiation rather than a pure
announcement system. I don't think it would be used much in the near term,
but it makes sense to define it correctly now. Build for the future and
all...



--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">I have a=
 proposal:</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000">Protocol &gt;=3D 70016 cease to send or process VERACK, an=
d instead use HANDSHAKEACK, which is completed after feature negotiation.</=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000">This should make everyone happy/unhappy, as in a new protocol number i=
t&#39;s fair game to change these semantics to be clear that we&#39;re acki=
ng more than version.</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000">I don&#39;t care about when or where these mess=
ages are sequenced overall, it seems to have minimal impact. If I had free =
choice, I slightly agree with Eric that verack should come before feature n=
egotiation, as we want to divorce the idea that protocol number and feature=
 support are tied.</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">But once this is done, we can supplant Verack with=
 HANDSHAKENACK or HANDSHAKEACK to signal success or failure to agree on a c=
onnection. A NACK reason (version too high/low or an important feature miss=
ing) could be optional. Implicit NACK would be disconnecting, but is discou=
raged because a peer doesn&#39;t know if it should reconnect or the failure=
 was intentional.<br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000">------<br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000">AJ: I think I generally do pre=
fer to have a FEATURE wrapper as you suggested, or a rule that all messages=
 in this period are interpreted as features (and may be redundant with p2p =
message types -- so you can literally just use the p2p message name w/o any=
 data).</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">I think we would want a semantic (which could be based just o=
n message names, but first-class support would be nice) for ACKing that a f=
eature is enabled. This is because a transcript of:</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000">NODE0:</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000">FEATURE A</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
>FEATURE B</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">VERACK<br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">NODE1:</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000">FEATURE A<br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">VERACK<br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000">It remains unclear if Node 1 ignored B becaus=
e it&#39;s an unknown feature, or because it is disabled. A transcript like=
:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)">NODE0:</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">FEATURE A</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">FEATURE=
 B</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)">FEATURE C<br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">ACK A<br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">VERACK<br></div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">NODE1:</div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">F=
EATURE A</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">ACK A</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)">NACK B<br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">V=
ERACK</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">would make it clear that A and B are known, B is disabled=
, and C is unknown. C has 0 support, B Node 0 should support inbound messag=
es but knows not to send to Node 1, and A has full bilateral support. Maybe=
 instead it could a message FEATURE SEND A and FEATURE RECV A, so we can ma=
ke the split explicit rather than inferred from ACK/NACK.<br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)">------</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I&#39;d als=
o propose that we add a message which is SYNC, which indicates the end of a=
 list of FEATURES and a request to send ACKS or NACKS back (which are follo=
wed by a SYNC). This allows multi-round negotiation where based on the pres=
ence of other features, I may expand the set of features I am offering. I t=
hink you could do without SYNC, but there are more edge cases and the expli=
citness is nice given that this already introduces future complexity.</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)">This multi-round makes it an actual negotiation rather than a pure a=
nnouncement system. I don&#39;t think it would be used much in the near ter=
m, but it makes sense to define it correctly now. Build for the future and =
all...<br></div></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div=
><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_si=
gnature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin"=
 target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRub=
in" target=3D"_blank"></a></div></div></div></div></div>

--000000000000d028a405ad688c88--