Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 23 Aug 2020 10:45:45 -0700
Message-Id: <1DE500EE-BDC7-4B36-AB12-45885D20C226@voskuil.org>
References: <b6198e1a-c30b-358a-9673-247a7c305913@mattcorallo.com>
In-Reply-To: <b6198e1a-c30b-358a-9673-247a7c305913@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p
	connections are setup
Precedence: list


> On Aug 21, 2020, at 13:45, Matt Corallo <lf-lists@mattcorallo.com> wrote:
>=20
> =EF=BB=BFThis seems to be pretty overengineered.

I agree. In fact all proposals I=E2=80=99ve seen on this are over engineered=
.

> Do you have a specific use-case in mind for anything more than simply cont=
inuing the pattern we've been using of sending a message indicating support f=
or a given feature?

Correct me if I=E2=80=99m wrong, but this pattern is what the proposal aims t=
o eliminate. There is no reason whatsoever for a message per indication. The=
 appropriate pattern is already established in the implementation of service=
 bits. In fact in this discussion it has been pointed out that the problem w=
ith service bits is simply too few bits.

> If we find some in the future,

> we could deploy something like this, though the current proposal makes it p=
ossible to do it on a per-feature case.

As does any other proposal, including passage of the full set of optional su=
b-protocols in the verack.

> The great thing about Suhas' proposal is the diff is about -1/+1 (not incl=
uding tests), while still getting all the flexibility we need.

> Even better, the code already exists.

This is neither true nor relevant. Maybe the Segwit 2X guys should have used=
 this argument.

e


> Matt
>=20
>> On 8/21/20 3:50 PM, Jeremy wrote:
>> I have a proposal:
>> Protocol >=3D 70016 cease to send or process VERACK, and instead use HAND=
SHAKEACK, 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 E=
ric that verack should come before feature negotiation, as we want to divorc=
e the idea that protocol number and feature support are tied.
>> But once this is done, we can supplant Verack with HANDSHAKENACK or HANDS=
HAKEACK 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. I=
mplicit 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 sugges=
ted, 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 na=
mes, but first-class support would be nice) for ACKing that a feature is ena=
bled. 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, o=
r 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 unkno=
wn. C has 0 support, B Node 0 should support inbound messages but knows not t=
o 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 explici=
t 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 a=
re followed by a SYNC). This allows multi-round negotiation where based on t=
he presence of other features, I may expand the set of features I am offerin=
g. I think you could do without SYNC, but there are more edge cases and the e=
xplicitness is nice given that this already introduces future complexity.
>> This multi-round makes it an actual negotiation rather than a pure announ=
cement system. I don't think it would be used much in the near term, but it m=
akes sense to define it correctly now. Build for the future and all...
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/Jeremy=
Rubin>