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 <<a href=3D"mailto:lf-lists@mattcorallo.com">lf-lists@m= attcorallo.com</a>> 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'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' 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> > I have a proposal:<br> > <br> > Protocol >=3D 70016 cease to send or process VERACK, and instead us= e HANDSHAKEACK, which is completed after feature <br> > negotiation.<br> > <br> > This should make everyone happy/unhappy, as in a new protocol number i= t's fair game to change these semantics to be <br> > clear that we're acking more than version.<br> > <br> > I don't care about when or where these messages are sequenced over= all, it seems to have minimal impact. If I had free <br> > choice, I slightly agree with Eric that verack should come before feat= ure negotiation, as we want to divorce the idea <br> > that protocol number and feature support are tied.<br> > <br> > But once this is done, we can supplant Verack with HANDSHAKENACK or HA= NDSHAKEACK to signal success or failure to agree <br> > on a connection. A NACK reason (version too high/low or an important f= eature missing) could be optional. Implicit NACK <br> > would be disconnecting, but is discouraged because a peer doesn't = know if it should reconnect or the failure was <br> > intentional.<br> > <br> > ------<br> > <br> > 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> > are interpreted as features (and may be redundant with p2p message typ= es -- so you can literally just use the p2p <br> > message name w/o any data).<br> > <br> > I think we would want a semantic (which could be based just on message= names, but first-class support would be nice) for <br> > ACKing that a feature is enabled. This is because a transcript of:<br> > <br> > NODE0:<br> > FEATURE A<br> > FEATURE B<br> > VERACK<br> > <br> > NODE1:<br> > FEATURE A<br> > VERACK<br> > <br> > It remains unclear if Node 1 ignored B because it's an unknown fea= ture, or because it is disabled. A transcript like:<br> > <br> > NODE0:<br> > FEATURE A<br> > FEATURE B<br> > FEATURE C<br> > ACK A<br> > VERACK<br> > <br> > NODE1:<br> > FEATURE A<br> > ACK A<br> > NACK B<br> > VERACK<br> > <br> > 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> > inbound messages but knows not to send to Node 1, and A has full bilat= eral support. Maybe instead it could a message <br> > FEATURE SEND A and FEATURE RECV A, so we can make the split explicit r= ather than inferred from ACK/NACK.<br> > <br> > <br> > ------<br> > <br> > 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 <br> > send ACKS or NACKS back (which are followed by a SYNC). This allows mu= lti-round negotiation where based on the presence <br> > 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> > edge cases and the explicitness is nice given that this already introd= uces future complexity.<br> > <br> > This multi-round makes it an actual negotiation rather than a pure ann= ouncement system. I don't think it would be used <br> > much in the near term, but it makes sense to define it correctly now. = Build for the future and all...<br> > <br> > <br> > <br> > --<br> > @JeremyRubin <<a href=3D"https://twitter.com/JeremyRubin" rel=3D"no= referrer" target=3D"_blank">https://twitter.com/JeremyRubin</a>><<a h= ref=3D"https://twitter.com/JeremyRubin" rel=3D"noreferrer" target=3D"_blank= ">https://twitter.com/JeremyRubin</a>><br> </blockquote></div> --00000000000071765605ad69a4c2--