From: Erik Aronesty <erik@q32.com>
To: Dhruv M <dhruv@bip324.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Refreshed BIP324
Date: Tue, 28 Feb 2023 16:02:41 -0500 [thread overview]
Message-ID: <CAJowKg+gOTCE=S2KYTF9j-uPYysUZJsJty5CHkkVp6+Ugy6Vtw@mail.gmail.com> (raw)
In-Reply-To: <f57b879d-a1f1-43c8-2557-874b1456d972@bip324.com>
[-- Attachment #1: Type: text/plain, Size: 3314 bytes --]
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 <
> aj@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
>
[-- Attachment #2: Type: text/html, Size: 4507 bytes --]
next prev parent reply other threads:[~2023-02-28 21:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-08 12:59 [bitcoin-dev] Refreshed BIP324 Dhruv M
2022-10-26 16:39 ` Pieter Wuille
2022-10-27 7:28 ` Vasil Dimov
2022-11-03 17:53 ` Murch
2022-11-03 22:26 ` Jonas Schnelli
2022-11-08 3:20 ` Anthony Towns
2022-11-10 21:23 ` Pieter Wuille
2022-11-12 3:23 ` Pieter Wuille
2022-11-12 18:52 ` Yuval Kogman
2022-11-18 8:24 ` Anthony Towns
2023-01-05 22:06 ` Pieter Wuille
2023-01-05 23:12 ` Anthony Towns
2023-01-09 8:11 ` Anthony Towns
2023-02-16 17:43 ` Dhruv M
2023-02-17 15:51 ` Anthony Towns
2023-02-17 22:13 ` Pieter Wuille
2023-02-19 23:56 ` Anthony Towns
2023-02-20 15:22 ` Pieter Wuille
2023-02-21 16:03 ` Anthony Towns
2023-02-28 18:07 ` Dhruv M
2023-02-28 21:02 ` Erik Aronesty [this message]
2023-10-11 20:52 ` Tim Ruffing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJowKg+gOTCE=S2KYTF9j-uPYysUZJsJty5CHkkVp6+Ugy6Vtw@mail.gmail.com' \
--to=erik@q32.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=dhruv@bip324.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox