From: Jeremy <jlrubin@mit•edu>
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: Fri, 21 Aug 2020 12:50:21 -0700 [thread overview]
Message-ID: <CAD5xwhi9zVp3nOhFy3Hia_Md++Gdz+F5Kat_bbbZwBcmPhMGZA@mail.gmail.com> (raw)
In-Reply-To: <B514142F-382B-4D49-B68D-0115ECBD1D79@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]
I have a proposal:
Protocol >= 70016 cease to send or process VERACK, and instead use
HANDSHAKEACK, which is completed after feature negotiation.
This should make everyone happy/unhappy, as in a new protocol number it's
fair game to change these semantics to be clear that we're acking more than
version.
I don't care about when or where these messages are sequenced overall, it
seems to have minimal impact. If I had free choice, I slightly agree with
Eric that verack should come before feature negotiation, as we want to
divorce the idea that protocol number and feature support are tied.
But once this is done, we can supplant Verack with HANDSHAKENACK or
HANDSHAKEACK to signal success or failure to agree on a connection. A NACK
reason (version too high/low or an important feature missing) could be
optional. Implicit NACK would be disconnecting, but is discouraged because
a peer doesn't know if it should reconnect or the failure was intentional.
------
AJ: I think I generally do prefer to have a FEATURE wrapper as you
suggested, or a rule that all messages in this period are interpreted as
features (and may be redundant with p2p message types -- so you can
literally just use the p2p message name w/o any data).
I think we would want a semantic (which could be based just on message
names, but first-class support would be nice) for ACKing that a feature is
enabled. This is because a transcript of:
NODE0:
FEATURE A
FEATURE B
VERACK
NODE1:
FEATURE A
VERACK
It remains unclear if Node 1 ignored B because it's an unknown feature, or
because it is disabled. A transcript like:
NODE0:
FEATURE A
FEATURE B
FEATURE C
ACK A
VERACK
NODE1:
FEATURE A
ACK A
NACK B
VERACK
would make it clear that A and B are known, B is disabled, and C is
unknown. C has 0 support, B Node 0 should support inbound messages but
knows not to send to Node 1, and A has full bilateral support. Maybe
instead it could a message FEATURE SEND A and FEATURE RECV A, so we can
make the split explicit rather than inferred from ACK/NACK.
------
I'd also propose that we add a message which is SYNC, which indicates the
end of a list of FEATURES and a request to send ACKS or NACKS back (which
are followed by a SYNC). This allows multi-round negotiation where based on
the presence of other features, I may expand the set of features I am
offering. I think you could do without SYNC, but there are more edge cases
and the explicitness is nice given that this already introduces future
complexity.
This multi-round makes it an actual negotiation rather than a pure
announcement system. I don't think it would be used much in the near term,
but it makes sense to define it correctly now. Build for the future and
all...
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 8900 bytes --]
next prev parent reply other threads:[~2020-08-21 19:50 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
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 [this message]
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=CAD5xwhi9zVp3nOhFy3Hia_Md++Gdz+F5Kat_bbbZwBcmPhMGZA@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--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