Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-28 🗒️ Summary of this message: A proposal to ...
📅 Original date posted:2023-02-28
🗒️ Summary of this message: A proposal to use 1-byte message type IDs with a reserved top bit for 2-byte IDs, similar to how protobuf stores integers.
📝 Original message: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 at 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 <
> aj at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230228/e41051b1/attachment.html>;
🗒️ Summary of this message: A proposal to use 1-byte message type IDs with a reserved top bit for 2-byte IDs, similar to how protobuf stores integers.
📝 Original message: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 at 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 <
> aj at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230228/e41051b1/attachment.html>;