Date: Thu, 20 Aug 2020 10:13:39 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Eric Voskuil <eric@voskuil.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200820141339.gbbr5rewi4yvoarl@ganymede>
References: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
 <C18E3371-C27A-41CD-B81F-6C96FA210494@voskuil.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="br7d5rqh26itcatr"
Content-Disposition: inline
In-Reply-To: <C18E3371-C27A-41CD-B81F-6C96FA210494@voskuil.org>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p
 connections are setup
Precedence: list


--br7d5rqh26itcatr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 16, 2020 at 12:06:55PM -0700, Eric Voskuil via bitcoin-dev wrot=
e:
> A requirement to ignore unknown (invalid) messages is [...] a protocol
> breaking change=20

I don't think it is.  The proposed BIP, as currently written, only tells
nodes to ignore unknown messages during peer negotiation.  The only case
where this will happen so far is BIP339, which says:

    The wtxidrelay message must be sent in response to a VERSION message
    from a peer whose protocol version is >=3D 70016, and prior to sending
    a VERACK

So unless you signal support for version >=3D70016, you'll never receive an
unknown message.  (And, if you do signal, you probably can't claim that
you were unaware of this new requirement, unless you were using a
non-BIP protocol like xthin[1]).

However, perhaps this new proposed BIP could be a bit clearer about its
expectations for future protocol upgrades by saying something like:

    Nodes implementing this BIP MUST also not send new negotiation
    message types to nodes whose protocol version is less than 70017.

That should promote backwards compatibility.  If you don't want to
ignore unknown negotiation messages between `version` and `verack`, you
can just set your protocol version to a max of 70016.

> A requirement to ignore unknown (invalid) messages is [...] poor
> protocol design. The purpose of version negotiation is to determine
> the set of valid messages.=20

To be clear, the proposed requirement to ignore unknown messages is
limited in scope to the brief negotiation phase between `version` and
`verack`.  If you want to terminate connections (or do whatever) on
receipt of an unknown message, you can do that at any other time.

> Changes to version negotiation itself are very problematic.

For whom?

> The only limitation presented by versioning is that the system is
> sequential.=20

That seems like a pretty significant limitation to decentralized
protocol development.

I think there are currently several people who want to run long-term
experiements for new protocol features using open source opt-in
codebases that anyone can run, and it would be advantageous to them to
have a flexible and lightweight feature negotiation system like this
proposed method.

> As such, clients that do not wish to implement (or operators who do
> not wish to enable) them are faced with a problem when wanting to
> support later features. This is resolvable by making such features
> optional at the new protocol level. This allows each client to limit
> its communication to the negotiated protocol, and allows ignoring of
> known but unsupported/disabled features.

I don't understand this.  How do two peers negotiate a set of two or
more optional features using only the exchange of single numbers?  For
example:

- Node A supports Feature X (implemented in protocol version 70998) and Fea=
ture Y (version 70999).

- Node B does not support X but does want to use Y; what does it use for its
  protocol version number when establishing a connection with node A?

---

Overall, I like the proposed BIP and the negotiation method it
describes.

Cheers,

-Dave

[1] This is not a recommendation for xthin, but I do think it's an example
    of the challenges of using a shared linear version number scheme for
    protocol negotiation in a decentralized system where different teams
    don't necessarily get along well with each other.
    https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544=
173f03d45373b#diff-c61070c281aed6ded69036c08bd08addR12

--br7d5rqh26itcatr
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl8+hRMACgkQ2dtBqWwi
adMRDBAAm9Dim9S9a75qEoL8dRKDBDO+WMvLP2jqL3VktNjpc6amrftQURKBipiy
0FKNxSG0wKXxg7ZKrxUy8/NpJXqwp7BewG5atX4YwpNLJrhcGSQESIYcTVR5ssNs
tRsVCR0vYW2gsOt9Jc/43FEa5Ed5wxtnhk3uRn/+OyPCqk3zbCaRcXlaMbmrVezY
FHnYEYtRtsiQDkJKdY2liviIAv3R5Kgch3T7CMuSFvWDLRxFyYXTlwI1cNzRmWyR
/u78NwCyR0QhhJYyZmWgYUcODu/4+1bjVzW17CabdGlQ6Z32hfN69OyMHyqisNbv
IqN8fGsc44tr+wz7ZkIWTCshNbfUDd0FGwLYndhQLu4EUszpYHMuXPeVGq7zwpKv
pYH30KlyflFRnkFQtvtK5cxa8n5w+3dapXyK0H7TSDJUe2PU2uIw9qZkBlhBgdei
aWBfIZq4wEyHpAHmv954ZpEPZgRD/xU7FX2dm/ebwOTebIJM4ayVzmbdqa+qiMiQ
PlqiMfA9/rzA3cqarRJCLyJcyvXo4Q4CLfINWyZlw0Wk9liO+49L+cqKEKNwEwIz
iIr4U9UXY88Ttw+jn15eGaU/WJgU4gSwTgTn3vPcZ6UU+JkUjmj8IXZtJiN1zrFu
3wLhw1iMaPc2gmYy3b/KxgGj1on7iitYIZo54GwTemHi4PcrzT8=
=XgyK
-----END PGP SIGNATURE-----

--br7d5rqh26itcatr--