path: root/d5/fb6b103b1db511d78ef33481150fad44dd5f0e

Return-Path: <eric@voskuil.org>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CA5B1C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Aug 2020 20:47:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id A4502204DB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Aug 2020 20:47:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id kuPj1YPVnvSW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Aug 2020 20:47:54 +0000 (UTC)
X-Greylist: delayed 00:45:48 by SQLgrey-1.7.6
Received: from mail-qv1-f66.google.com (mail-qv1-f66.google.com
 [209.85.219.66])
 by silver.osuosl.org (Postfix) with ESMTPS id B156A20347
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Aug 2020 20:47:54 +0000 (UTC)
Received: by mail-qv1-f66.google.com with SMTP id v1so5030825qvn.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Aug 2020 13:47:54 -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=LYRWL/XVPo2vIoaDJ9XUcnDY3oPgoSvkRotGYd+Mfuw=;
 b=ty+uR4wFVw0fzoyNudhlmq2unT5eLr9U8TG5+jVwgJctgobE5gUVRlqP3rqpy1tgxl
 1zx4k28m6BPNjDWkHEPXdczaHV/GziBZysIGkvgwanyIwSotdF1OcQbWk55FRmcVEvg6
 w58bAMpiwOqIbtrlSUQ2f47YQQ63SEPHIY0FfzgEy6HyMqe/XNS8zIC0ks5pU0o+dB23
 JmeJjOU1kHfJB8lf9ccjM9BuVyQYitjTV2YtWw5nM/L+JbdDva3JuPSVrtckdgxnz1Ix
 OU4voFvbATDw0zknlavADqa1L6IW9xkukplaXrRvVpj9+9XXI1aT4T9K5zU/0uJyRnkJ
 3G9g==
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=LYRWL/XVPo2vIoaDJ9XUcnDY3oPgoSvkRotGYd+Mfuw=;
 b=fj4bEpYJrGg9nncv/nyc1yU71h9sUQRcjj44iqFbeJGAvY1TmurPVo757WblzFcmCg
 8GG5XZPcQ6KIIoIF75x9e5gHvas6IoJD/rg/wV1vWKy5j3wNqyC5mmGpdweoQGZEpoZG
 hVZ28vwag3AyYQ1Y0M3N2p1pI8Q3z1Ibi6Ndmj6XBNex34jNLcAvCu09xngSOMBxH+c5
 LsYeTEyiIulXjRoAyzEI8CnS4vhUyp9Fhxrs53Wj94qhevOi9vzwXo6TOBAtJNydbn2j
 bxEs+yDYOrLoD/6xEDQgrb5hj93xzXIiDA2Gpu4m3MyijE/j+XcA4xHsx6Q8p6aMEsxj
 Z9JA==
X-Gm-Message-State: AOAM531HYd0s7BL8aMEHG8mlC/eq1fX5GkZTCUN3JMtl1v2g8aGpHnNz
 je8lev7qA9GmyFuyQyHRnpSLSI7fRVpCZw==
X-Google-Smtp-Source: ABdhPJxUGul8XWZjahXq/JKjAlJ3q9y2Y3FVnMIiVhHwSOrKDyeH5UIZDgZ/nZQqEGZFCKkMkaDzUA==
X-Received: by 2002:a17:902:c206:: with SMTP id
 6mr1479352pll.169.1597604817043; 
 Sun, 16 Aug 2020 12:06:57 -0700 (PDT)
Received: from ?IPv6:2600:380:7066:ce6e:c976:12fb:75f1:c075?
 ([2600:380:7066:ce6e:c976:12fb:75f1:c075])
 by smtp.gmail.com with ESMTPSA id r28sm16193587pfg.158.2020.08.16.12.06.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 16 Aug 2020 12:06:56 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 16 Aug 2020 12:06:55 -0700
Message-Id: <C18E3371-C27A-41CD-B81F-6C96FA210494@voskuil.org>
References: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
In-Reply-To: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
To: Suhas Daftuar <sdaftuar@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (17G68)
X-Mailman-Approved-At: Sun, 16 Aug 2020 21:26:28 +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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Aug 2020 20:47:56 -0000


--Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

A requirement to ignore unknown (invalid) messages is not only a protocol br=
eaking change but poor protocol design. The purpose of version negotiation i=
s to determine the set of valid messages. Changes to version negotiation its=
elf are very problematic.

The only limitation presented by versioning is that the system is sequential=
. As such, clients that do not wish to implement (or operators who do not wi=
sh to enable) them are faced with a problem when wanting to support later fe=
atures. This is resolvable by making such features optional at the new proto=
col level. This allows each client to limit its communication to the negotia=
ted protocol, and allows ignoring of known but unsupported/disabled features=
.

Sorry I missed your earlier post. Been distracted for a while.

e


> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>=20
> =EF=BB=BF
> Hi,
>=20
> Back in February I posted a proposal for WTXID-based transaction relay[1] (=
now known as BIP 339), which included a proposal for feature negotiation to t=
ake place prior to the VERACK message being received by each side.  In my em=
ail to this list, I had asked for feedback as to whether that proposal was p=
roblematic, and didn't receive any responses.
>=20
> Since then, the implementation of BIP 339 has been merged into Bitcoin Cor=
e, though it has not yet been released.
>=20
> In thinking about the mechanism used there, I thought it would be helpful t=
o codify in a BIP the idea that Bitcoin network clients should ignore unknow=
n messages received before a VERACK.  A draft of my proposal is available he=
re[2].
>=20
> I presume that software upgrading past protocol version 70016 was already p=
lanning to either implement BIP 339, or ignore the wtxidrelay message propos=
ed in BIP 339 (if not, then this would create network split concerns in the f=
uture -- so I hope that someone would speak up if this were a problem).  Whe=
n we propose future protocol upgrades that would benefit from feature negoti=
ation at the time of connection, I think it would be nice to be able to use t=
he same method as proposed in BIP 339, without even needing to bump the prot=
ocol version.  So having an understanding that this is the standard of how o=
ther network clients operate would be helpful.
>=20
> If, on the other hand, this is problematic for some reason, I look forward=
 to hearing that as well, so that we can be careful about how we deploy futu=
re p2p changes to avoid disruption.
>=20
> Thanks,
> Suhas Daftuar
>=20
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/=
017648.html
>=20
> [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-nego=
tiation/bip-p2p-feature-negotiation.mediawiki
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><div dir=3D"ltr">A require=
ment to ignore unknown (invalid) messages is not only a protocol breaking ch=
ange but poor protocol design. The purpose of version negotiation is to dete=
rmine the set of valid messages. Changes to version negotiation itself are v=
ery problematic.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">The only l=
imitation presented by versioning is that the system is sequential. As such,=
 clients that do not wish to implement (or operators who do not wish to enab=
le) them are faced with a problem when wanting to support later features. Th=
is is resolvable by making such features optional at the new protocol level.=
 This allows each client to limit its communication to the negotiated protoc=
ol, and allows ignoring of known but unsupported/disabled features.</div><di=
v dir=3D"ltr"><br></div><div dir=3D"ltr">Sorry I missed your earlier post. B=
een distracted for a while.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"=
>e</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><br></div></div><div dir=
=3D"ltr"><blockquote type=3D"cite">On Aug 14, 2020, at 12:28, Suhas Daftuar v=
ia bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<br><br><=
/blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div d=
ir=3D"ltr">Hi,<div><br></div><div>Back in February I posted a proposal for W=
TXID-based transaction relay[1] (now known as BIP 339), which included a pro=
posal for feature negotiation to take place prior to the VERACK message bein=
g received by each side.&nbsp; In my email to this list, I had asked for fee=
dback as to whether that proposal was problematic, and didn't receive any re=
sponses.</div><div><br></div><div>Since then, the implementation&nbsp;of BIP=
 339 has been merged into Bitcoin Core, though it has not yet been released.=
</div><div><br></div><div>In thinking about the mechanism used there, I thou=
ght it would&nbsp;be helpful to codify in a BIP the idea that Bitcoin networ=
k clients should ignore unknown messages received before a VERACK.&nbsp; A d=
raft of my proposal is available here[2].</div><div><br></div><div>I presume=
 that software upgrading past protocol version 70016 was already planning to=
 either implement BIP 339, or ignore the wtxidrelay message proposed in BIP 3=
39 (if not, then this would create network split concerns in the future -- s=
o I hope that someone would speak up if this were a problem).&nbsp; When we p=
ropose future protocol upgrades that would benefit from feature negotiation a=
t the time of connection, I think it would be nice to be able to use the sam=
e method as proposed in BIP 339, without even needing to bump the protocol v=
ersion.&nbsp; So having an understanding that this is the standard of how ot=
her network clients operate would be helpful.</div><div><br></div><div>If, o=
n the other hand, this is problematic for some reason, I look forward to hea=
ring that as well, so that we can be careful about how we deploy future p2p c=
hanges to avoid disruption.</div><div><br></div><div>Thanks,</div><div>Suhas=
 Daftuar</div><div><br></div><div>[1]&nbsp;<a href=3D"https://lists.linuxfou=
ndation.org/pipermail/bitcoin-dev/2020-February/017648.html">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html</a><br></=
div><div><br></div><div>[2]&nbsp;<a href=3D"https://github.com/sdaftuar/bips=
/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.me=
diawiki">https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-n=
egotiation/bip-p2p-feature-negotiation.mediawiki</a></div></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></body></html>=

--Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796--