Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-05 🗒️ Summary of this message: Pieter suggests ...
📅 Original date posted:2023-01-05
🗒️ Summary of this message: Pieter suggests a uniform encoding scheme for commands in the p2p protocol, but acknowledges it may not be necessary and could add complexity.
📝 Original message:------- Original Message -------
On Friday, November 18th, 2022 at 3:24 AM, Anthony Towns <aj at erisian.com.au> wrote:
> > * etc
> > So this gives a uniform space which commands can be assigned from, and there is no strict need for thinking of the short-binary and long-alphabetic commands as distinct. In v2, some short ones would be treated as aliases for old long-alphabetic ones. But new commands could also just be introduced as short ones only (even in v1).
>
> Isn't that optimising for the wrong thing? Aren't the goals we want:
>
> 1) it should be easy to come up with a message identifier without
> accidently conflicting with someone else's proposal
>
> 2) commonly used messages on the wire should have a short encoding
> in order to save bandwidth
>
> Depending on how much the p2p protocol ossifies, which messages are
> "commonly used on the wire" might be expected to change; and picking an
> otherwise meaningless value from a set of 102 elements seems likely to
> produce conflicts...
Oh, yes. I meant this as an encoding scheme, not as a (replacement for) the negotiation/coordination mechanism. There could still be an initial assignment for 1-byte encodings, and/or an explicit mechanism to negotiate other assignment, and/or nothing at all for now.
I just thought it would be interesting to have a uniform encoding without explicit distinction between "short commands" and "long commands" at that layer.
But maybe none of this is worth it, as it's perhaps more complexity than the alternative, and the alternative already has a working implementation and written-up specification.
Cheers,
--
Pieter
🗒️ Summary of this message: Pieter suggests a uniform encoding scheme for commands in the p2p protocol, but acknowledges it may not be necessary and could add complexity.
📝 Original message:------- Original Message -------
On Friday, November 18th, 2022 at 3:24 AM, Anthony Towns <aj at erisian.com.au> wrote:
> > * etc
> > So this gives a uniform space which commands can be assigned from, and there is no strict need for thinking of the short-binary and long-alphabetic commands as distinct. In v2, some short ones would be treated as aliases for old long-alphabetic ones. But new commands could also just be introduced as short ones only (even in v1).
>
> Isn't that optimising for the wrong thing? Aren't the goals we want:
>
> 1) it should be easy to come up with a message identifier without
> accidently conflicting with someone else's proposal
>
> 2) commonly used messages on the wire should have a short encoding
> in order to save bandwidth
>
> Depending on how much the p2p protocol ossifies, which messages are
> "commonly used on the wire" might be expected to change; and picking an
> otherwise meaningless value from a set of 102 elements seems likely to
> produce conflicts...
Oh, yes. I meant this as an encoding scheme, not as a (replacement for) the negotiation/coordination mechanism. There could still be an initial assignment for 1-byte encodings, and/or an explicit mechanism to negotiate other assignment, and/or nothing at all for now.
I just thought it would be interesting to have a uniform encoding without explicit distinction between "short commands" and "long commands" at that layer.
But maybe none of this is worth it, as it's perhaps more complexity than the alternative, and the alternative already has a working implementation and written-up specification.
Cheers,
--
Pieter