From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8D0D0C0051 for ; Fri, 21 Aug 2020 17:07:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 797868831A for ; Fri, 21 Aug 2020 17:07:54 +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 B1WGh4pBQApt for ; Fri, 21 Aug 2020 17:07:53 +0000 (UTC) X-Greylist: delayed 00:16:57 by SQLgrey-1.7.6 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by whitealder.osuosl.org (Postfix) with ESMTPS id BEC268830D for ; Fri, 21 Aug 2020 17:07:53 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id v15so1289438pgh.6 for ; Fri, 21 Aug 2020 10:07:53 -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:in-reply-to:to; bh=yQW5w2OgMMMc2/AKyoIXTOxtnfLwb/qT6MZsI1XJp0E=; b=hL4LlGaD/dEhrKYqIUFijEZ5fYYyO9XFpo+8FjQSR21GAhMQJUVZ67PVqDEGEWj/yG BZH8gpBIiLUc3BBNfxxg2W/9W6iaSzmHFsCPtUIBXqg8obnyjx5DzICovH/58bYWlyYc Do86GMWE7Bv99qQ4PZ8qIbcKdWrjjgNSq2lwq6BGOaOS78kifFiIsGCLzWSRd6cPzBxe QQnHeOaa+ZlMcABl9tprKnAma5R4AOKgdA6MKhNWqUYryFd4Dz2mXL8tG3NxAv9UCtH0 JqDeMmH9Sc9GgjUmYaHzBtoOLzBhvbvFgK7rUlZOMYy5yRWS1OICrq8Wz1wDDtKmWK8/ 9bBA== 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:in-reply-to:to; bh=yQW5w2OgMMMc2/AKyoIXTOxtnfLwb/qT6MZsI1XJp0E=; b=G63y9VfJ0Fi5YAI/uGRZrkV3PYnVuNhZ0F7E7dJWjI3/o3SiyWw9Jug63qQHBmzc/M rhxNMGEg60+a1nzo94SmPim3xtft+L7i4FQZeocTBiT7OtTYK7Jr06qe9hYCamssLPv7 EeMm3VUysMk9D/K2zdLsooyhlwBHUrS6zTMn//HdtJkpLlLUz8kWE+6VN1FcciRonwaq a0VmVibgrPdUB2xoySA5VnOGQPkTpweSG/sUO+5LTyOy9Df0nkiKSCA28LMLtWtJMYuE qmuXuh5Er2r7jQCr8bTroPRXK/Nt2/6DtUeqcIijpDTl+xZ0d++kg0ntXbsp+EJ7iO6l zD/Q== X-Gm-Message-State: AOAM530KjspP7tJ6brKh6rQK8HQfHUm4Z4tjU8riZohWEb9ikPh+wLq3 b30wJyyJ3YJINHjHhycZrbH+Qn/lCimSF3Ug X-Google-Smtp-Source: ABdhPJwf6Agj2UjeCCOMDjHcy8LHIsh99pw2xLbXrPaUI2pUy7L1gF4NRNdlcX4VsoNKoCEVsfWBaA== X-Received: by 2002:a63:741b:: with SMTP id p27mr2800814pgc.194.1598028168221; Fri, 21 Aug 2020 09:42:48 -0700 (PDT) Received: from ?IPv6:2601:602:9a00:370e:f4ae:5f8d:2cd4:9084? ([2601:602:9a00:370e:f4ae:5f8d:2cd4:9084]) by smtp.gmail.com with ESMTPSA id v128sm3036922pfc.14.2020.08.21.09.42.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Aug 2020 09:42:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Fri, 21 Aug 2020 09:42:46 -0700 Message-Id: References: In-Reply-To: To: lf-lists@mattcorallo.com, Bitcoin Protocol Discussion X-Mailer: iPhone Mail (17G68) X-Mailman-Approved-At: Fri, 21 Aug 2020 17:18:05 +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 17:07:54 -0000 I=E2=80=99m pretty sure one can run whatever they want even without a BIP. T= here is nobody here to do any =E2=80=9Callowing=E2=80=9D. On the other hand,= standards development is tedious for good reason. Generally speaking, overloading is a primary source of complexity (creating m= ore branches in code and human explanation). Nevertheless this is verack pay= load, no additional messages are necessary or helpful. e > On Aug 21, 2020, at 07:15, Matt Corallo via bitcoin-dev wrote: >=20 > =EF=BB=BFSure, we could do a new message for negotiation, but there doesn=E2= =80=99t seem to be a lot of reason for it - using the same namespace for neg= otiation seems fine too. In any case, this is one of those things that doesn= =E2=80=99t matter in the slightest, and if one person volunteers to write a B= IP and code, no reason they shouldn=E2=80=99t just decide and be allowed to r= un with it. Rough consensus and running code, as it were :) >=20 > Matt >=20 >=20 >>> On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev wrote: >>>=20 >>> =EF=BB=BFOn Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bit= coin-dev wrote: >>> In thinking about the mechanism used there, I thought it would be helpfu= l to >>> codify in a BIP the idea that Bitcoin network clients should ignore unkn= own >>> 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev