Actually we already have service bits (which are sadly limited) which allow negotiation of non bilateral feature support, so this would supercede that. -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin>
On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo <lf-li...@mattcorallo.com> wrote: > This seems to be pretty overengineered. Do you have a specific use-case in > mind for anything more than simply continuing > the pattern we've been using of sending a message indicating support for a > given feature? If we find some in the future, > we could deploy something like this, though the current proposal makes it > possible to do it on a per-feature case. > > The great thing about Suhas' proposal is the diff is about -1/+1 (not > including tests), while still getting all the > flexibility we need. Even better, the code already exists. > > Matt > > On 8/21/20 3:50 PM, Jeremy wrote: > > 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> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
