On Sat, Nov 12, 2022 at 03:23:16AM +0000, Pieter Wuille via bitcoin-dev wrote:
> Another idea...
> This means:
> * Every alphabetic command of L characters becomes L bytes.
> * 102 non-alphabetic 1-byte commands can be assigned.
> * 15708 non-alphabetic 2-byte commands can be assigned.
(There are 128**L possible L-byte commands, 26**L alphabetic L-byte
commands, and hence 128**L-26**L non-alphabetical L-byte commands)
> * 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...
Doing:
-> VERSION
<- VERSION
<- SHORTMSG ["BIP324", "foo.org/experiment"]
<- VERACK
-> SHORTMSG ["BIP324"]
-> VERACK
-> SENDSHORTMSG "BIP324" [(13, "ADDRV3")]
<- SENDSHORTMSG "BIP324"
-> 34 (SENDHEADERS)
-> 25 (GETHEADERS)
...
where "SHORTMSG" lets you specify an array of tables you support (such as
BIP324's), and, once you know both sides supports a table, you can send
`SENDSHORTMSG` to choose the table you'll use to abbreviate messages
you send, as well as any modifications to that table (like replacing
ADDR with ADDRV3).
Then when writing BIPs, you just choose a meaningful string ("ADDRV3"),
and when implementing you send a one-time "SENDSHORTMSG" message to
optimise the messages you'll send most often... As time goes on and the
most common messages change, issue a new BIP with a new table so that
your one-time SHORTIDs message becomes shorter too, at least when you
connect to peers that also know about the new bip..
Could potentially support that without bip324, by taking over the one
byte message space, presuming you don't have any one-character messages
you actually want to send?
Could do this /as well as/ the encoding above, I guess; then you would
have bips specify alphabetic message ids, and use SENDSHORTMSG to
dynamically (and sequentially) override/allocate non-alphabetic ids?
That would presumably limit the number of non-alphabetic ids to how
many you could specify in a single SENDSHORTIDs message, which I think
would be up to something like 749k different 1/2/3/4/5/6-byte alphabetic
message ids (encoded as 1/2/3-byte non-alphabetic messages). Probably
some more specific limit would be better though.
Cheers,
aj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
