Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 72A24C0051 for ; 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 ; 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 ; 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 ; Fri, 21 Aug 2020 21:17:58 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id b11so1437536pld.7 for ; 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 Mime-Version: 1.0 (1.0) Date: Fri, 21 Aug 2020 14:17:55 -0700 Message-Id: References: In-Reply-To: To: Jeremy X-Mailer: iPhone Mail (17G68) X-Mailman-Approved-At: Fri, 21 Aug 2020 21:26:52 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 --Apple-Mail-F47D6351-3432-4509-8567-AED633B486DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Service bits are advertise= d, protocol support is not.

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

e

On Aug 21, 2020, at 14:08, Jeremy <jlrubin@mit.ed= u> wrote:

=EF=BB=BF
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.


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 g= iven feature? If we find some in the future,
we could deploy something like this, though the current proposal makes it po= ssible to do it on a per-feature case.

The great thing about Suhas' proposal is the diff is about -1/+1 (not includ= ing 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 >=3D 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, i= t seems to have minimal impact. If I had free
> choice, I slightly agree with Eric that verack should come before featu= re 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 HAN= DSHAKEACK to signal success or failure to agree
> on a connection. A NACK reason (version too high/low or an important fe= ature missing) could be optional. Implicit NACK
> would be disconnecting, but is discouraged because a peer doesn't know i= f it should reconnect or the failure was
> intentional.
>
> ------
>
> 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
> are interpreted as features (and may be redundant with p2p message type= s -- 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 n= ames, 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 unk= nown. C has 0 support, B Node 0 should support
> inbound messages but knows not to send to Node 1, and A has full bilate= ral support. Maybe instead it could a message
> FEATURE SEND A and FEATURE RECV A, so we can make the split explicit ra= ther than inferred from ACK/NACK.
>
>
> ------
>
> 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
> send ACKS or NACKS back (which are followed by a SYNC). This allows mul= ti-round negotiation where based on the presence
> 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
> edge cases and the explicitness is nice given that this already introdu= ces future complexity.
>
> This multi-round makes it an actual negotiation rather than a pure anno= uncement system. I don't think it would be used
> much in the near term, but it makes sense to define it correctly now. B= uild for the future and all...
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin><h= ttps://twitter.com/JeremyRubin>
= --Apple-Mail-F47D6351-3432-4509-8567-AED633B486DB--