path: root/f3/22352f336ddeb71ebe81deb403682b00867f7f

Return-Path: <eric@voskuil.org>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 72A24C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 21:18:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 3125586F43
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 21:18:00 +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 9fza2fvXCzDc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 21:17:58 +0000 (UTC)
X-Greylist: delayed 16:52:48 by SQLgrey-1.7.6
Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com
 [209.85.214.174])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 2D28686F3A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 21:17:58 +0000 (UTC)
Received: by mail-pl1-f174.google.com with SMTP id b11so1437536pld.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Aug 2020 14:17:58 -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=OgKjMe+F8uCZvMmpTu1k0T9Z+0frfMetb9pG022K0so=;
 b=ST/F9QiLHk5NO2VNxC5SlmaBr1QNSbDujGDJvSDZgzUwvEUCpRAb5VHyUoQKkK1ebX
 vKWwMZSn7t1Jv+5Oh1D7vXIzMCME5cNrkSolF1Z4SO4s5sy9DWO55AF/GRJSNQpYaUK4
 MQeHBsOpVlNoH+KLzqBDs/v4ixpzBTPFVBJ24zKJnpbpwebTlRjXpmRDESyHdw1QZwkK
 uJ9J5y6kzaEXcjXVlabSSlMc9dSytRLP34VVHdZbQBvuQowXof5t2Yhbs6SCQ//F3OTz
 hQLITDBR4JC/0m+P03ER1+qdpX8xaM7aXiUqkbMMduL6nHRzo84CQnDYiQ/ooc5HMMCR
 dkOQ==
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=OgKjMe+F8uCZvMmpTu1k0T9Z+0frfMetb9pG022K0so=;
 b=F4Pw+gLzicEKatBHp6Bhv9y118k3/zdC4XDFucP6jBlwsZP0P2HBQuZ8bqybVEWyr8
 gTyTkWRCflMM9vbkT5NsG+kILy7uDZ1OsVhWU/gS9zryrbTq0bQZ8nr6o7rSsfgu01s1
 FX6LoK0RimCa2y2xnublSVfoc/OGAu5J3srz2/2xtmst+PSAolGHgPcfb1XanEvhdnCy
 9PKmSQH79TxlXbYTiWpYCDjoiFm7UP5FZvnRD2I3DSH5m0s+UqfLKZWo1r0WaB/qQEXZ
 zb+MxFUodaliq9FxKqJovDEUvJGkZL8wn+hU7hzZDwxUzKAqkC2bhisg99nF6+tT1mPw
 k60g==
X-Gm-Message-State: AOAM533M+VAjnCP9qGythZSNHzRym4iOAxrhkTB8i11xQrt5YzciUuVm
 Hkd49H4esV8nHGFIc4gyIG7FEmiAfBJUrw==
X-Google-Smtp-Source: ABdhPJyFjg+ZGFBuduH/arXEADDulRK712aC17XYGYnqx844YRHllScIsf4MIZQWXECIx7r60Yes7Q==
X-Received: by 2002:a17:902:9889:: with SMTP id
 s9mr3813888plp.90.1598044677147; 
 Fri, 21 Aug 2020 14:17:57 -0700 (PDT)
Received: from ?IPv6:2600:380:7066:ce6e:c450:64a1:5dd1:d29b?
 ([2600:380:7066:ce6e:c450:64a1:5dd1:d29b])
 by smtp.gmail.com with ESMTPSA id o192sm3859595pfg.81.2020.08.21.14.17.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 21 Aug 2020 14:17:56 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-F47D6351-3432-4509-8567-AED633B486DB
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Fri, 21 Aug 2020 14:17:55 -0700
Message-Id: <C9CB03D3-2328-4FEB-96EF-4FB297C78BC6@voskuil.org>
References: <CAD5xwhhrz8SMQ4bA6eD2VRwqmMEzVv7NmrD8kDnPfqJy092bKQ@mail.gmail.com>
In-Reply-To: <CAD5xwhhrz8SMQ4bA6eD2VRwqmMEzVv7NmrD8kDnPfqJy092bKQ@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
X-Mailer: iPhone Mail (17G68)
X-Mailman-Approved-At: Fri, 21 Aug 2020 21:26:52 +0000
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:18:00 -0000


--Apple-Mail-F47D6351-3432-4509-8567-AED633B486DB
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Service bits are advertised, protocol support is not.

https://en.bitcoin.it/wiki/Protocol_documentation#Network_address

e

> On Aug 21, 2020, at 14:08, Jeremy <jlrubin@mit.edu> wrote:
>=20
> =EF=BB=BF
> Actually we already have service bits (which are sadly limited) which allo=
w negotiation of non bilateral feature support, so this would supercede that=
.
> --
> @JeremyRubin
>=20
>=20
>> On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo <lf-lists@mattcorallo.com> w=
rote:
>> This seems to be pretty overengineered. Do you have a specific use-case i=
n mind for anything more than simply continuing=20
>> the pattern we've been using of sending a message indicating support for a=
 given feature? If we find some in the future,=20
>> we could deploy something like this, though the current proposal makes it=
 possible to do it on a per-feature case.
>>=20
>> The great thing about Suhas' proposal is the diff is about -1/+1 (not inc=
luding tests), while still getting all the=20
>> flexibility we need. Even better, the code already exists.
>>=20
>> Matt
>>=20
>> On 8/21/20 3:50 PM, Jeremy wrote:
>> > I have a proposal:
>> >=20
>> > Protocol >=3D 70016 cease to send or process VERACK, and instead use HA=
NDSHAKEACK, which is completed after feature=20
>> > negotiation.
>> >=20
>> > This should make everyone happy/unhappy, as in a new protocol number it=
's fair game to change these semantics to be=20
>> > clear that we're acking more than version.
>> >=20
>> > I don't care about when or where these messages are sequenced overall, i=
t seems to have minimal impact. If I had free=20
>> > choice, I slightly agree with Eric that verack should come before featu=
re negotiation, as we want to divorce the idea=20
>> > that protocol number and feature support are tied.
>> >=20
>> > But once this is done, we can supplant Verack with HANDSHAKENACK or HAN=
DSHAKEACK to signal success or failure to agree=20
>> > on a connection. A NACK reason (version too high/low or an important fe=
ature missing) could be optional. Implicit NACK=20
>> > would be disconnecting, but is discouraged because a peer doesn't know i=
f it should reconnect or the failure was=20
>> > intentional.
>> >=20
>> > ------
>> >=20
>> > AJ: I think I generally do prefer to have a FEATURE wrapper as you sugg=
ested, or a rule that all messages in this period=20
>> > are interpreted as features (and may be redundant with p2p message type=
s -- so you can literally just use the p2p=20
>> > message name w/o any data).
>> >=20
>> > I think we would want a semantic (which could be based just on message n=
ames, but first-class support would be nice) for=20
>> > ACKing that a feature is enabled. This is because a transcript of:
>> >=20
>> > NODE0:
>> > FEATURE A
>> > FEATURE B
>> > VERACK
>> >=20
>> > NODE1:
>> > FEATURE A
>> > VERACK
>> >=20
>> > It remains unclear if Node 1 ignored B because it's an unknown feature,=
 or because it is disabled. A transcript like:
>> >=20
>> > NODE0:
>> > FEATURE A
>> > FEATURE B
>> > FEATURE C
>> > ACK A
>> > VERACK
>> >=20
>> > NODE1:
>> > FEATURE A
>> > ACK A
>> > NACK B
>> > VERACK
>> >=20
>> > would make it clear that A and B are known, B is disabled, and C is unk=
nown. C has 0 support, B Node 0 should support=20
>> > inbound messages but knows not to send to Node 1, and A has full bilate=
ral support. Maybe instead it could a message=20
>> > FEATURE SEND A and FEATURE RECV A, so we can make the split explicit ra=
ther than inferred from ACK/NACK.
>> >=20
>> >=20
>> > ------
>> >=20
>> > I'd also propose that we add a message which is SYNC, which indicates t=
he end of a list of FEATURES and a request to=20
>> > send ACKS or NACKS back (which are followed by a SYNC). This allows mul=
ti-round negotiation where based on the presence=20
>> > of other features, I may expand the set of features I am offering. I th=
ink you could do without SYNC, but there are more=20
>> > edge cases and the explicitness is nice given that this already introdu=
ces future complexity.
>> >=20
>> > This multi-round makes it an actual negotiation rather than a pure anno=
uncement system. I don't think it would be used=20
>> > much in the near term, but it makes sense to define it correctly now. B=
uild for the future and all...
>> >=20
>> >=20
>> >=20
>> > --
>> > @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/Jere=
myRubin>

--Apple-Mail-F47D6351-3432-4509-8567-AED633B486DB
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">Service bits are advertise=
d, protocol support is not.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"=
><a href=3D"https://en.bitcoin.it/wiki/Protocol_documentation#Network_addres=
s">https://en.bitcoin.it/wiki/Protocol_documentation#Network_address</a></di=
v><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</div><div dir=3D"ltr"><br><b=
lockquote type=3D"cite">On Aug 21, 2020, at 14:08, Jeremy &lt;jlrubin@mit.ed=
u&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D=
"ltr">=EF=BB=BF<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:#000000">Actually we a=
lready have service bits (which are sadly limited) which allow negotiation o=
f non bilateral feature support, so this would supercede that.<br clear=3D"a=
ll"></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"=
gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/Jerem=
yRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/Jer=
emyRubin" target=3D"_blank"></a></div></div></div><br></div><br><div class=3D=
"gmail_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=
@mattcorallo.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=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 specific=
 use-case in mind for anything more than simply continuing <br>
the pattern we've been using of sending a message indicating support for a g=
iven feature? If we find some in the future, <br>
we could deploy something like this, though the current proposal makes it po=
ssible to do it on a per-feature case.<br>
<br>
The great thing about Suhas' proposal is the diff is about -1/+1 (not includ=
ing 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 use=
 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 it=
's fair game to change these semantics to be <br>
&gt; clear that we're acking more than version.<br>
&gt; <br>
&gt; I don't care about when or where these messages are sequenced overall, i=
t seems to have minimal impact. If I had free <br>
&gt; choice, I slightly agree with Eric that verack should come before featu=
re 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 HAN=
DSHAKEACK to signal success or failure to agree <br>
&gt; on a connection. A NACK reason (version too high/low or an important fe=
ature missing) could be optional. Implicit NACK <br>
&gt; would be disconnecting, but is discouraged because a peer doesn't know i=
f 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 sugg=
ested, or a rule that all messages in this period <br>
&gt; are interpreted as features (and may be redundant with p2p message type=
s -- 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 n=
ames, 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's an unknown feature,=
 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 unk=
nown. 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 bilate=
ral support. Maybe instead it could a message <br>
&gt; FEATURE SEND A and FEATURE RECV A, so we can make the split explicit ra=
ther than inferred from ACK/NACK.<br>
&gt; <br>
&gt; <br>
&gt; ------<br>
&gt; <br>
&gt; I'd also propose that we add a message which is SYNC, which indicates t=
he 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 mul=
ti-round negotiation where based on the presence <br>
&gt; of other features, I may expand the set of features I am offering. I th=
ink you could do without SYNC, but there are more <br>
&gt; edge cases and the explicitness is nice given that this already introdu=
ces future complexity.<br>
&gt; <br>
&gt; This multi-round makes it an actual negotiation rather than a pure anno=
uncement system. I don't think it would be used <br>
&gt; much in the near term, but it makes sense to define it correctly now. B=
uild 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"nor=
eferrer" target=3D"_blank">https://twitter.com/JeremyRubin</a>&gt;&lt;<a hre=
f=3D"https://twitter.com/JeremyRubin" rel=3D"noreferrer" target=3D"_blank">h=
ttps://twitter.com/JeremyRubin</a>&gt;<br>
</blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-F47D6351-3432-4509-8567-AED633B486DB--