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
