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 4079CC0051 for ; Fri, 21 Aug 2020 04:31:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 2726C88650 for ; Fri, 21 Aug 2020 04:31:01 +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 fHAM9VMUg6AU for ; Fri, 21 Aug 2020 04:31:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by hemlock.osuosl.org (Postfix) with ESMTPS id 4B59F88642 for ; Fri, 21 Aug 2020 04:31:00 +0000 (UTC) Received: by mail-vs1-f49.google.com with SMTP id r7so216578vsq.5 for ; Thu, 20 Aug 2020 21:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=uPv6TbVPz2mJZmx+d29NzowPvlk1FW2ahb1OQx5U6gI=; b=PAQU7etb11SxxI2oYlCeqt2ai3pxmKxOKrclD1rjl/9anIG00oB78dfjpTIzndB/sL cfW6cJpIYIgLSA5S04DgBmOO6ZRb9qUpKRhiTF/mDS1ZOM1L3i/8mn5Ds901HWBjUNK7 yd37aWLzRsgNb7dLwIDyK/pkp4FzyS6WD06rYoZQFdM0mnpbXOq50Arl09QY0MWfE0SS LT1tMlkiptlxs8Z1BGZe3SmVSRB5TYpgyFfscW94FStIcNPdheRiMW5UvVRAkjuiIyb7 H7kHwx5aslzkBPZNvygU72MqxtN7MOhjfw1RDs+YiwAQNot4RY09EBl9HfZGiFpnJ294 tpZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=uPv6TbVPz2mJZmx+d29NzowPvlk1FW2ahb1OQx5U6gI=; b=uHTKJcfMWEKnW1RYHP+C0++QuSZeWdIOSiRLwJ3QM2vbHa2syHBF3AzITppziYeAhx Yxp9rNl7u59HPlgOuorXRWCOG2Zl8F4Wr+azM0U7FN/bye9ZAOzyznI3DfWr6bh8Ri0E UEVUJ6X//sCb9Uuny1lYvC4iLtv5+/3psDLKjnJrSdWeu8BEa3aauZl0uZiUJM4tE+hh JfZsQSHCzf4DvtIBIZDIhjmfIvFGVpb0w3zXqvuX2la4Kex9sd1UWLvYVdHxiJyuINyk rOTuvwKl92FRjMgDOwHX83A8VuEe7JM7cc/ZaZkNDJeDOzZK7pPp6UKYjZXiygiVO5OI Eewg== X-Gm-Message-State: AOAM531+zmc7iJc+bi/BjcO1zMg4ppiaLp8KSWdmQpaUnriCX/ZN7EbW h4YP/+AKpQF9xUa6pAZx5IiaYQLMW7ADJQ== X-Google-Smtp-Source: ABdhPJzCzCALHrdSXrV7KLIl+XG6IwZ3NdKw/pvjlwp29ez/dFX5UEYn369b2+mg/wyHX6LUP3yzOw== X-Received: by 2002:a17:902:b497:: with SMTP id y23mr846846plr.251.1597983909971; Thu, 20 Aug 2020 21:25:09 -0700 (PDT) Received: from ?IPv6:2600:380:7066:ce6e:7435:a47f:2958:b337? ([2600:380:7066:ce6e:7435:a47f:2958:b337]) by smtp.gmail.com with ESMTPSA id h18sm735746pfo.21.2020.08.20.21.25.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2020 21:25:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Thu, 20 Aug 2020 21:25:08 -0700 Message-Id: References: <20200821023647.7eat4goqqrtaqnna@erisian.com.au> In-Reply-To: <20200821023647.7eat4goqqrtaqnna@erisian.com.au> To: Anthony Towns , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (17G68) X-Mailman-Approved-At: Fri, 21 Aug 2020 08:00:08 +0000 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 04:31:01 -0000 Hi Anthony, This is what I was implying in my last post (the reference to the unnecessar= y overload of message typing). However, if one imagines a sequence diagram f= or this communication it becomes obvious that all such messages are 100% red= undant with verack. e > On Aug 20, 2020, at 19:37, Anthony Towns via bitcoin-dev wrote: >=20 > =EF=BB=BFOn Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitco= in-dev wrote: >> In thinking about the mechanism used there, I thought it would be helpful= to >> codify in a BIP the idea that Bitcoin network clients should ignore unkno= wn >> messages received before a VERACK. A draft of my proposal is available h= ere >> [2]. >=20 > Rather than allowing arbitrary messages, maybe it would make sense to > have a specific feature negotiation message, eg: >=20 > VERSION ... > FEATURE wtxidrelay > FEATURE packagerelay > VERACK >=20 > with the behaviour being that it's valid only between VERSION and VERACK, > and it takes a length-prefixed-string giving the feature name, optional > additional data, and if the feature name isn't recognised the message > is ignored. >=20 > If we were to support a "polite disconnect" feature like Jeremy suggested,= > it might be easier to do that for a generic FEATURE message, than > reimplement it for the message proposed by each new feature. >=20 > Cheers, > aj >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev