Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5BF2FC0051 for ; Mon, 24 Aug 2020 13:59:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 49D8D86969 for ; Mon, 24 Aug 2020 13:59:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZED8z3+gVgod for ; Mon, 24 Aug 2020 13:59:38 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by whitealder.osuosl.org (Postfix) with ESMTPS id DC835866CA for ; Mon, 24 Aug 2020 13:59:38 +0000 (UTC) Received: by mail-pj1-f41.google.com with SMTP id mw10so4268901pjb.2 for ; Mon, 24 Aug 2020 06:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eq+UPc9tlJXcHBgzPTUsrazNFFfW7Jdo2wrMTFY10k8=; b=g7v4AtyLcGQh7anmBjnOfLBi+4MFmO6x4YMBoYXrgjQufUP4PfNTLtaifk5kffseOP gE/IgTBCwurlh1pAznSqtiQPJOKnpp0NcOkedsLLBQkmGz4J8d/T2y8GGerkHEc5Lo0i QjmpQE46f4tEwTsiJAfNtMlzWbDIzDygS0pRKhPWBzhx2wpbGDsvYqgiBilR3KhX+sFH LJmAFSA+2McPg1N5cVlgkWmVzZwoVCeitOb40klxnU2Owudv50wduNioCRDdPudOuACz 3JSkJt5SfDhwdNmGSBS7SCPnIvyUx2qIAvmJN3AU03xNZ9Rkzz4EOkRwSrwX/K/w1R8e GT6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eq+UPc9tlJXcHBgzPTUsrazNFFfW7Jdo2wrMTFY10k8=; b=AXLoD2T88ktt+qrC0gWgNlyoujSkbf3QO9AHXpTuo2d+J3r3XQ+a0q80mXNfha8geX WQWvF4yX6BLOQZIdNQY2XAgSAce/OGASVeM+yAtmcX2YA3gFgSYOjXlicgpf4IchVTY7 9SSux8Eip1qWhXjOCk+yKjABMdpuy2fJADipunEbo288gvWI7bpaU+aEbAT8+ttISxWr Nv2XtyjN5OtNqRpnISfqM5YkcV2MGeOXPUAc4RigSH2jFORgjGWpm800Ms/QHegC2Ti+ oj4fXYQsnHfP9A5NquyK/Tw0AzMKT3364KUc2VOGHj7Mno7WLqXyBckOVMwAg3ra693t NM8g== X-Gm-Message-State: AOAM533vAgiKV+yQG8jhp+JrVEQOZ9glRSXH46Wo2G2N7hS90+K5jGEV e2EH5sriuz2Q0UvvRxVsOBYeSOWwYw7AoPAQjYI= X-Google-Smtp-Source: ABdhPJyhQBGh/ycegeMfYjsKSJaKaMjJxeCsgL3A7hSYogeQbNyaHLl/BhTgeGXsVU8A9iBYblTMUrAJbyroR8AUT+s= X-Received: by 2002:a17:90a:4214:: with SMTP id o20mr4712371pjg.232.1598277578379; Mon, 24 Aug 2020 06:59:38 -0700 (PDT) MIME-Version: 1.0 References: <27FE83C7-0269-4DEB-82E4-486FAFFA0DE5@voskuil.org> In-Reply-To: From: "G. Andrew Stone" Date: Mon, 24 Aug 2020 09:59:26 -0400 Message-ID: To: Suhas Daftuar , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000004fd46805ad9fff06" 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: Mon, 24 Aug 2020 13:59:40 -0000 --0000000000004fd46805ad9fff06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since discussion around allowing unknown messages or not allowing them seems contentious, I'd like to offer up another possibility: create a single new message, XVERSION, (and bump the protocol rev) which is a key-value array of arbitrary data. Any protocol extension can then choose a new key (with a 32 or 64 bit keyspace you can basically hand out prefixes to any implementation that wants one) and publish custom data via this message without needing to bump the protocol rev field. Typical "custom data" would be the min and max supported version of some specific extended protocol, but any data is possible since the "value" field can be serialized via the same network serialization format. It therefore doubles as a "configuration" message as well as protocol extension negotiation. For example, we use it to communicate the maximum unconfirmed chain a node will commit to the mempool, and peers don't bother to send transactions that exceed this limit. You can find a specification here: https://gitlab.com/bitcoinunlimited/BCHUnlimited/-/blob/dev/doc/xversionmes= sage.md Code has been deployed for a long time. Regards, Andrew On Mon, Aug 24, 2020 at 5:44 AM Suhas Daftuar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > > Thanks for the helpful discussion. > > My primary motivation in starting this thread was to establish what the > expectations are for new feature deployment (particularly whether the > protocol version should continue to be bumped or not), and I think I have > that answer -- different from what I proposed when I started this thread, > but not in a way that I think meaningfully hinders future work. So I'm > happy to leave it at that and withdraw my suggestion. > > Cheers, > Suhas > > > On Sun, Aug 23, 2020 at 1:51 PM Eric Voskuil via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> > On Aug 21, 2020, at 15:16, Matt Corallo >> wrote: >> > >> > =EF=BB=BFHmm, could that not be accomplished by simply building this i= nto new >> messages? eg, send "betterprotocol", if you see a verack and no >> "betterprotocol" from your peer, send "worseprotocol" before you send a >> "verack". >> > >> > Matt >> > >> >> On 8/21/20 5:17 PM, Jeremy wrote: >> >> As for an example of where you'd want multi-round, you could imagine = a >> scenario where you have a feature A which gets bugfixed by the introduct= ion >> of feature B, and you don't want to expose that you support A unless you >> first negotiate B. Or if you can negotiate B you should never expose A, = but >> for old nodes you'll still do it if B is unknown to them. >> >> This seems to imply a security benefit (I can=E2=80=99t discern any othe= r >> rationale for this complexity). It should be clear that this is no more >> than trivially weak obfuscation and not worth complicating the protocol = to >> achieve. >> >> >> An example of this would be (were it not already out without a featur= e >> negotiation existing) WTXID/TXID relay. >> >> The SYNC primitve simply codifies what order messages should be in an= d >> when you're done for a phase of negotiation offering something. It can b= e >> done without, but then you have to be more careful to broadcast in the >> correct order and it's not clear when/if you should wait for more time >> before responding. >> >> On Fri, Aug 21, 2020 at 2:08 PM Jeremy > jlrubin@mit.edu>> wrote: >> >> 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> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000004fd46805ad9fff06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since discussion around allowing unknown messages or = not allowing them seems contentious, I'd like to offer up another possi= bility: create a single new message, XVERSION, (and bump the protocol rev) = which is a key-value array of arbitrary data.=C2=A0 Any protocol extension = can then choose a new key (with a 32 or 64 bit keyspace you can basically h= and out prefixes to any implementation that wants one)=C2=A0 and publish cu= stom data via this message without needing to bump the protocol rev field.= =C2=A0 Typical "custom data" would be the min and max supported v= ersion of some specific extended protocol, but any data is possible since t= he "value" field can be serialized via the same network serializa= tion format.=C2=A0 It therefore doubles as a "configuration" mess= age as well as protocol extension negotiation.=C2=A0 For example, we use it= to communicate the maximum unconfirmed chain a node will commit to the mem= pool, and peers don't bother to send transactions that exceed this limi= t.

You can find a specification here:
https://gitlab.com/bitcoinunlimited/BCHUnlimited/-/bl= ob/dev/doc/xversionmessage.md

Code has been de= ployed for a long time.

Regards,
Andrew<= br>


On Mon, Aug 24, 2020 at 5:44 AM Suhas Daftuar via = bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> wrote:
Hi all,

<= div>Thanks for the helpful discussion.=C2=A0

My pr= imary motivation in starting this thread was to establish what the expectat= ions are for new feature deployment (particularly whether the protocol vers= ion should continue to be bumped or not), and I think I have that answer --= different from what I proposed when I started this thread, but not in a wa= y that I think meaningfully hinders future work.=C2=A0 So I'm happy to = leave it at that and withdraw my suggestion.

Cheer= s,
Suhas


On Sun, Aug 23, 2020 at 1= :51 PM Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.o= rg> wrote:
lf-lists@mattcorallo.com> wrote:=
>
> =EF=BB=BFHmm, could that not be accomplished by simply building this i= nto new messages? eg, send "betterprotocol", if you see a verack = and no "betterprotocol" from your peer, send "worseprotocol&= quot; before you send a "verack".
>
> Matt
>
>> On 8/21/20 5:17 PM, Jeremy wrote:
>> As for an example of where you'd want multi-round, you could i= magine a scenario where you have a feature A which gets bugfixed by the int= roduction of feature B, and you don't want to expose that you support A= unless you first negotiate B. Or if you can negotiate B you should never e= xpose A, but for old nodes you'll still do it if B is unknown to them.<= br>
This seems to imply a security benefit (I can=E2=80=99t discern any other r= ationale for this complexity). It should be clear that this is no more than= trivially weak obfuscation and not worth complicating the protocol to achi= eve.

>> An example of this would be (were it not already out without a fea= ture negotiation existing) WTXID/TXID relay.
>> The SYNC primitve simply codifies what order messages should be in= and when you're done for a phase of negotiation offering something. It= can be done without, but then you have to be more careful to broadcast in = the correct order and it's not clear when/if you should wait for more t= ime before responding.
>> On Fri, Aug 21, 2020 at 2:08 PM Jeremy <jlrubin@mit.edu <mailto:jlrubin@mit.edu>> wrote: >>=C2=A0 =C2=A0 Actually we already have service bits (which are sadl= y limited) which allow negotiation of non bilateral feature
>>=C2=A0 =C2=A0 support, so this would supercede that.
>>=C2=A0 =C2=A0 --
>>=C2=A0 =C2=A0 @JeremyRubin <https://twitter.com/JeremyRubi= n><https://twitter.com/JeremyRubin>
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000004fd46805ad9fff06--