Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 17E0CC0051 for ; Mon, 24 Aug 2020 09:44:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 00AE686DBD for ; Mon, 24 Aug 2020 09:44:21 +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 UixTxPmQFuZ6 for ; Mon, 24 Aug 2020 09:44:20 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by whitealder.osuosl.org (Postfix) with ESMTPS id E681C86BC4 for ; Mon, 24 Aug 2020 09:44:19 +0000 (UTC) Received: by mail-il1-f173.google.com with SMTP id 77so6662993ilc.5 for ; Mon, 24 Aug 2020 02:44:19 -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=8MR6NUcVN3lkLTwCc6cUlLoBNyKL8lTVn0sho4kQgw8=; b=Kp54LCIWI99jAGFki1W++JAEFhnBeciO49S8s3GhP3JB7tpvRMpszJW73gPeAUyFv6 b7TM7ZPFtGAeoJSfh8S+JIk4irHkNHsiUf4Xf4FweW61UJdBqfcmdIm09bql9YCCkf9x txwD2F8mgRsRphq5pQsbyMomRvQlFW+atElaXVkS55MPVsGlJtCM2EY7u3oEG2BXhcce fWlCDUPQX15mFC5y/eeWvoyUreKq/fjEZLQSCxzuTPpuSQMgL+jbd4jerhaGGtF6PGWx fzsOjFTw+bO8ZAmztJ5Wwo5nnrvi5u7vAU2qiVP2vfuGJCEVilmvQMa4soP0hn1pNDFg +MXA== 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=8MR6NUcVN3lkLTwCc6cUlLoBNyKL8lTVn0sho4kQgw8=; b=sTgkTkq4i3NW5GYQJMWLyM6t6IMtspqocGtMNy5QN10kUD//VAmtWVJqAM9dzCjW2S YpjY4zOhaPfcqIfQobwtstJMdHEGR5yvVFUIujxuWVO0PNoDEV5TQomE9Xjm60bfg6tA /f+BSppWjmsVqHstBqV+S6jik5jJsHdcUj7lxwPAGWAp00s2k1VHZHXgNZvcuz8oqY1L fypySFD59KhgkriJpXUH9R6VYOyBCvD9RfJRzD4yX5vCa6tQh9Ig8T3kWpzYWaiBvCZJ JNsNbPEhOq3yyzd+hzPnsrDS586uPsJNiv4+UVElJUtQiyCVIrSkjA6hrMDPiChIXXQg yfDQ== X-Gm-Message-State: AOAM532j4TfpOlRc4RAbIg/IQlt97sbiEqn9zJForyaU+roiIwrk2rNy LlejPuxLgvoPJa8Zad0BGvLzMV5yHml3Z4eJoGMjq7U5JYaSNw== X-Google-Smtp-Source: ABdhPJyslvM9nIqRjePdstLy3CsTrL9lsGSVaCerUiU7cS7Qfh6tpjMBEG/gzESZYd79x3aca2FOPI7HtCElbZYAIrM= X-Received: by 2002:a05:6e02:673:: with SMTP id l19mr4109978ilt.121.1598262258949; Mon, 24 Aug 2020 02:44:18 -0700 (PDT) MIME-Version: 1.0 References: <27FE83C7-0269-4DEB-82E4-486FAFFA0DE5@voskuil.org> In-Reply-To: <27FE83C7-0269-4DEB-82E4-486FAFFA0DE5@voskuil.org> From: Suhas Daftuar Date: Mon, 24 Aug 2020 05:44:07 -0400 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000033e3f505ad9c6e9e" 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 09:44:21 -0000 --00000000000033e3f505ad9c6e9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 in= to 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 introducti= on > 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, b= ut > 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 other > rationale for this complexity). It should be clear that this is no more > than trivially weak obfuscation and not worth complicating the protocol t= o > achieve. > > >> An example of this would be (were it not already out without a feature > 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 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 > --00000000000033e3f505ad9c6e9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks for the helpful discussi= on.=C2=A0

My primary motivation in starting this t= hread 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 whe= n I started this thread, but not in a way that I think meaningfully hinders= future work.=C2=A0 So I'm happy to leave it at that and withdraw my su= ggestion.

Cheers,
Suhas


On Sun, Aug 23, 2020 at 1:51 PM Eric Voskuil via bitcoin-de= v <bitcoin-dev@= lists.linuxfoundation.org> wrote:

> On Aug 21, 2020, at 15:16, Matt Corallo <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
--00000000000033e3f505ad9c6e9e--