you can always do what protocols usually do. 1 byte is fine for now, but reserve the top bit for "this is a two byte id" (128 choices). then when you run out of room, set the top bit which means "this is a 2 byte id (again with one reserved) and so-on. ie: how protobuf stores integers.
On Tue, Feb 28, 2023 at 1:42 PM Dhruv M via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The relevant changes from this discussion about short 1-byte message > type IDs are now in a PR for the bips repo: > https://github.com/bitcoin/bips/pull/1428 > > On 2/21/23 08:03, Anthony Towns via bitcoin-dev wrote: > > On Mon, Feb 20, 2023 at 03:22:30PM +0000, Pieter Wuille via bitcoin-dev > wrote: > >> On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns < > a...@erisian.com.au> wrote: > >>> On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via > bitcoin-dev wrote: > >>>>> I think it's probably less complex to close some of the doors? > >>>>> 2) are short ids available/meaningful to send prior to VERACK being > >>>>> completed? > >>>>> Ah, I hadn't considered this nuance. If we don't care about them > being available before VERACK negotiation, then it may be possible to > introduce a way to negotiate a different short id mapping table without > needing a mechanism for re-negotiating. > >>> I think you still need/want two negotiation steps -- once to tell each > >>> other what tables you know about, once to choose a mutually recognised > >>> table and specify any additions. > >> Right, I wasn't talking about how many steps/messages the negotiation > takes. I just meant that if all negotiation of the mapping table happens > just once (before VERACK) and that negotiation itself happens without use > of short commands, then there is no need for re-negotiating short commands > after they are already in use. Nothing concrete, but I can imagine that > that may simplify some implementations. > > Yeah; I was just thinking of the fact that currently the negotiation is: > > > > * send your VERSION message > > * see what their VERSION message is > > > > * announce a bunch of features, depending on the version (or service > > flags) > > * send the VERACK (and GETADDR and final ALERT) > > > > * wait for their announcements and VERACK > > * negotiation is finished; we know everything; we're ready to go > > > > which only gets you two steps if you send the short id stuff as part of > > the VERSION message. Obviously you could just add an extra phase either > > just before or just after the VERACK, though. > > > > I suppose being able to choose your own short id mapping from day 0 would > > mean that every bip324 node could use a single short id mapping for all > > outgoing messages, which might also make implementation marginally easier > > (no need to use one table for modern nodes, but also support the original > > table for old bip324 implementations)... > > > > Cheers, > > aj > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
