From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 66599C0051 for ; Fri, 21 Aug 2020 22:16:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 59F3088776 for ; Fri, 21 Aug 2020 22:16:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQ6fT5uWojBb for ; Fri, 21 Aug 2020 22:16:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by hemlock.osuosl.org (Postfix) with ESMTPS id 97FE78863E for ; Fri, 21 Aug 2020 22:16:06 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id 0980B2F1832; Fri, 21 Aug 2020 22:16:02 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1598046064; t=1598048163; bh=2CID0qSEwsxTfi1NcLmJz0UGOsdBXWfHB+s/t/EwLIo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=K64JsMHp5gDIpNIbkXAkrFbTg1gk00GoSe3OktIqBLcygVMgCP4rqkGKUJf4G19ZS dWBGiHRTwqMEHVqp4UozwJWxvIDUNNGkcoX4uKwkdF3wi7gPcfteC1aGDIAAPrOsV0 93TCyKo7zE+g7lXc+TjjeB03ssFrvfD53CK2n2KNgnNNiEyAMdn6cALu4EzMEnp7Mt 9fW8i4Z2tXZHW/rOvwHDKqVCrGlpoiUhJFjEe/nCHcOzCnQEYOsUe6MKVX+GaTkd7J XgBg9yIpQbMuRbsAjOihMgM7ybhc//+0Dmrr+nQKihZr31IEMiM5sViS258jBGcuwm XmWBLPP+SfmKw== To: Jeremy References: From: Matt Corallo Message-ID: Date: Fri, 21 Aug 2020 18:16:02 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 22:16:07 -0000 Hmm, could that not be accomplished by simply building this into 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 introduction 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. 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 > 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 >