From: "David A. Harding" <dave@dtrt•org>
To: Eric Voskuil <eric@voskuil•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup
Date: Thu, 20 Aug 2020 10:13:39 -0400 [thread overview]
Message-ID: <20200820141339.gbbr5rewi4yvoarl@ganymede> (raw)
In-Reply-To: <C18E3371-C27A-41CD-B81F-6C96FA210494@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 3602 bytes --]
On Sun, Aug 16, 2020 at 12:06:55PM -0700, Eric Voskuil via bitcoin-dev wrote:
> A requirement to ignore unknown (invalid) messages is [...] a protocol
> breaking change
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 >= 70016, and prior to sending
a VERACK
So unless you signal support for version >=70016, 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.
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.
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 Feature 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/7ea5854a3599851beffb1323544173f03d45373b#diff-c61070c281aed6ded69036c08bd08addR12
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-08-20 14:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 19:28 Suhas Daftuar
2020-08-16 17:24 ` Jeremy
2020-08-16 19:06 ` Eric Voskuil
2020-08-17 20:40 ` Suhas Daftuar
2020-08-17 21:21 ` Eric Voskuil
2020-08-20 14:13 ` David A. Harding [this message]
2020-08-18 14:59 ` Matt Corallo
2020-08-18 16:54 ` Eric Voskuil
2020-08-18 17:26 ` Matt Corallo
2020-08-18 18:11 ` Eric Voskuil
2020-08-18 18:25 ` Matt Corallo
2020-08-18 18:56 ` Eric Voskuil
2020-08-21 2:36 ` Anthony Towns
2020-08-21 4:25 ` Eric Voskuil
2020-08-21 14:15 ` lf-lists
2020-08-21 16:42 ` Eric Voskuil
2020-08-21 19:50 ` Jeremy
2020-08-21 20:45 ` Matt Corallo
2020-08-21 21:08 ` Jeremy
2020-08-21 21:17 ` Jeremy
2020-08-21 22:16 ` Matt Corallo
2020-08-23 17:49 ` Eric Voskuil
2020-08-24 9:44 ` Suhas Daftuar
2020-08-24 13:59 ` G. Andrew Stone
2020-08-24 19:58 ` Jeremy
2020-08-24 20:17 ` Eric Voskuil
2020-08-24 20:21 ` Jeremy
2020-08-24 20:33 ` Eric Voskuil
2020-08-21 21:17 ` Eric Voskuil
2020-08-23 17:45 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200820141339.gbbr5rewi4yvoarl@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox