> On Aug 21, 2020, at 13:45, Matt Corallo <lf-li...@mattcorallo.com> wrote: > > This seems to be pretty overengineered.
I agree. In fact all proposals I’ve seen on this are over engineered. > 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? Correct me if I’m wrong, but this pattern is what the proposal aims to 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 with 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 > possible to do it on a per-feature case. As does any other proposal, including passage of the full set of optional sub-protocols in the verack. > 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. This is neither true nor relevant. Maybe the Segwit 2X guys should have used this argument. e > 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
