From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id EFD91C0051 for ; 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 ; 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 ; 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 ; 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 ; Fri, 21 Aug 2020 17:08:46 -0400 Received: by mail-ej1-f49.google.com with SMTP id qc22so4033420ejb.4 for ; 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: In-Reply-To: From: Jeremy Date: Fri, 21 Aug 2020 14:08:33 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary="00000000000071765605ad69a4c2" 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: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 On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo 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> > --00000000000071765605ad69a4c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually we already have = service bits (which are sadly limited) which allow negotiation of non bilat= eral feature support, so this would supercede that.
=

On Fri, Aug 21, 2020 at 1:45= PM Matt Corallo <lf-lists@m= attcorallo.com> wrote:
This seems to be pretty overengineered. Do you have a specifi= c use-case in mind for anything more than simply continuing
the pattern we've been using of sending a message indicating support fo= r a given feature? If we find some in the future,
we could deploy something like this, though the current proposal makes it p= ossible to do it on a per-feature case.

The great thing about Suhas' proposal is the diff is about -1/+1 (not i= ncluding 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 us= e HANDSHAKEACK, which is completed after feature
> negotiation.
>
> This should make everyone happy/unhappy, as in a new protocol number i= t'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 over= all, it seems to have minimal impact. If I had free
> choice, I slightly agree with Eric that verack should come before feat= ure 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 HA= NDSHAKEACK to signal success or failure to agree
> on a connection. A NACK reason (version too high/low or an important f= eature 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 sug= gested, or a rule that all messages in this period
> are interpreted as features (and may be redundant with p2p message typ= es -- 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 fea= ture, 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 un= known. C has 0 support, B Node 0 should support
> inbound messages but knows not to send to Node 1, and A has full bilat= eral support. Maybe instead it could a message
> FEATURE SEND A and FEATURE RECV A, so we can make the split explicit r= ather than inferred from ACK/NACK.
>
>
> ------
>
> I'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
> send ACKS or NACKS back (which are followed by a SYNC). This allows mu= lti-round negotiation where based on the presence
> 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 explicitness is nice given that this already introd= uces future complexity.
>
> This multi-round makes it an actual negotiation rather than a pure ann= ouncement 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--