path: root/46/397d30e6f9a7c60df85337d134201c7a022dc6

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 EFD91C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 21:08:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id B144F2309D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 21:08:50 +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 YuuSFIXTIQXi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 21:08:48 +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 717F223086
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 21:08:48 +0000 (UTC)
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com
 [209.85.218.49]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07LL8jT2024788
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 21 Aug 2020 17:08:46 -0400
Received: by mail-ej1-f49.google.com with SMTP id qc22so4033420ejb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 14:08:46 -0700 (PDT)
X-Gm-Message-State: AOAM5318ogsXWvU3M0ibYNbrk3A1x00mak7BlJKPmGvMBF1UEL5VaEn+
 8IgtLMIC8t9z12faXQaBLc7yxkKGFDSxGpCwe8w=
X-Google-Smtp-Source: ABdhPJx7y0EiyoB80zD62Yn9uCRUdGnnv+NHOVkfacYI/dumDl6KppiXXvZU4mnN4CRKBXbdtVTRC4m6p9j7TCTPoeM=
X-Received: by 2002:a17:907:20db:: with SMTP id
 qq27mr4927419ejb.550.1598044125620; 
 Fri, 21 Aug 2020 14:08:45 -0700 (PDT)
MIME-Version: 1.0
References: <A26FA2BC-50E5-4635-95E4-56AAA969C9DA@mattcorallo.com>
 <B514142F-382B-4D49-B68D-0115ECBD1D79@voskuil.org>
 <CAD5xwhi9zVp3nOhFy3Hia_Md++Gdz+F5Kat_bbbZwBcmPhMGZA@mail.gmail.com>
 <b6198e1a-c30b-358a-9673-247a7c305913@mattcorallo.com>
In-Reply-To: <b6198e1a-c30b-358a-9673-247a7c305913@mattcorallo.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 21 Aug 2020 14:08:33 -0700
X-Gmail-Original-Message-ID: <CAD5xwhhrz8SMQ4bA6eD2VRwqmMEzVv7NmrD8kDnPfqJy092bKQ@mail.gmail.com>
Message-ID: <CAD5xwhhrz8SMQ4bA6eD2VRwqmMEzVv7NmrD8kDnPfqJy092bKQ@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="00000000000071765605ad69a4c2"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 21:08:51 -0000

--00000000000071765605ad69a4c2
Content-Type: text/plain; charset="UTF-8"

Actually we already have service bits (which are sadly limited) which allow
negotiation of non bilateral feature support, so this would supercede that.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> This seems to be pretty overengineered. Do you have a specific use-case in
> mind for anything more than simply continuing
> the pattern we've been using of sending a message indicating support for a
> given feature? If we find some in the future,
> we could deploy something like this, though the current proposal makes it
> possible to do it on a per-feature case.
>
> The great thing about Suhas' proposal is the diff is about -1/+1 (not
> including tests), while still getting all the
> flexibility we need. Even better, the code already exists.
>
> Matt
>
> On 8/21/20 3:50 PM, Jeremy wrote:
> > 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>
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Actually we already have =
service bits (which are sadly limited) which allow negotiation of non bilat=
eral feature support, so this would supercede that.<br clear=3D"all"></div>=
<div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_sig=
nature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" =
target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubi=
n" target=3D"_blank"></a></div></div></div><br></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug 21, 2020 at 1:45=
 PM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcorallo.com">lf-lists@m=
attcorallo.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">This seems to be pretty overengineered. Do you have a specifi=
c use-case in mind for anything more than simply continuing <br>
the pattern we&#39;ve been using of sending a message indicating support fo=
r a given feature? If we find some in the future, <br>
we could deploy something like this, though the current proposal makes it p=
ossible to do it on a per-feature case.<br>
<br>
The great thing about Suhas&#39; proposal is the diff is about -1/+1 (not i=
ncluding tests), while still getting all the <br>
flexibility we need. Even better, the code already exists.<br>
<br>
Matt<br>
<br>
On 8/21/20 3:50 PM, Jeremy wrote:<br>
&gt; I have a proposal:<br>
&gt; <br>
&gt; Protocol &gt;=3D 70016 cease to send or process VERACK, and instead us=
e HANDSHAKEACK, which is completed after feature <br>
&gt; negotiation.<br>
&gt; <br>
&gt; This should make everyone happy/unhappy, as in a new protocol number i=
t&#39;s fair game to change these semantics to be <br>
&gt; clear that we&#39;re acking more than version.<br>
&gt; <br>
&gt; I don&#39;t care about when or where these messages are sequenced over=
all, it seems to have minimal impact. If I had free <br>
&gt; choice, I slightly agree with Eric that verack should come before feat=
ure negotiation, as we want to divorce the idea <br>
&gt; that protocol number and feature support are tied.<br>
&gt; <br>
&gt; But once this is done, we can supplant Verack with HANDSHAKENACK or HA=
NDSHAKEACK to signal success or failure to agree <br>
&gt; on a connection. A NACK reason (version too high/low or an important f=
eature missing) could be optional. Implicit NACK <br>
&gt; would be disconnecting, but is discouraged because a peer doesn&#39;t =
know if it should reconnect or the failure was <br>
&gt; intentional.<br>
&gt; <br>
&gt; ------<br>
&gt; <br>
&gt; AJ: I think I generally do prefer to have a FEATURE wrapper as you sug=
gested, or a rule that all messages in this period <br>
&gt; are interpreted as features (and may be redundant with p2p message typ=
es -- so you can literally just use the p2p <br>
&gt; message name w/o any data).<br>
&gt; <br>
&gt; I think we would want a semantic (which could be based just on message=
 names, but first-class support would be nice) for <br>
&gt; ACKing that a feature is enabled. This is because a transcript of:<br>
&gt; <br>
&gt; NODE0:<br>
&gt; FEATURE A<br>
&gt; FEATURE B<br>
&gt; VERACK<br>
&gt; <br>
&gt; NODE1:<br>
&gt; FEATURE A<br>
&gt; VERACK<br>
&gt; <br>
&gt; It remains unclear if Node 1 ignored B because it&#39;s an unknown fea=
ture, or because it is disabled. A transcript like:<br>
&gt; <br>
&gt; NODE0:<br>
&gt; FEATURE A<br>
&gt; FEATURE B<br>
&gt; FEATURE C<br>
&gt; ACK A<br>
&gt; VERACK<br>
&gt; <br>
&gt; NODE1:<br>
&gt; FEATURE A<br>
&gt; ACK A<br>
&gt; NACK B<br>
&gt; VERACK<br>
&gt; <br>
&gt; would make it clear that A and B are known, B is disabled, and C is un=
known. C has 0 support, B Node 0 should support <br>
&gt; inbound messages but knows not to send to Node 1, and A has full bilat=
eral support. Maybe instead it could a message <br>
&gt; FEATURE SEND A and FEATURE RECV A, so we can make the split explicit r=
ather than inferred from ACK/NACK.<br>
&gt; <br>
&gt; <br>
&gt; ------<br>
&gt; <br>
&gt; I&#39;d also propose that we add a message which is SYNC, which indica=
tes the end of a list of FEATURES and a request to <br>
&gt; send ACKS or NACKS back (which are followed by a SYNC). This allows mu=
lti-round negotiation where based on the presence <br>
&gt; 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 <br>
&gt; edge cases and the explicitness is nice given that this already introd=
uces future complexity.<br>
&gt; <br>
&gt; This multi-round makes it an actual negotiation rather than a pure ann=
ouncement system. I don&#39;t think it would be used <br>
&gt; much in the near term, but it makes sense to define it correctly now. =
Build for the future and all...<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; @JeremyRubin &lt;<a href=3D"https://twitter.com/JeremyRubin" rel=3D"no=
referrer" target=3D"_blank">https://twitter.com/JeremyRubin</a>&gt;&lt;<a h=
ref=3D"https://twitter.com/JeremyRubin" rel=3D"noreferrer" target=3D"_blank=
">https://twitter.com/JeremyRubin</a>&gt;<br>
</blockquote></div>

--00000000000071765605ad69a4c2--