From: Anthony Towns <aj@erisian•com.au>
To: Pieter Wuille <bitcoin-dev@wuille•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Refreshed BIP324
Date: Fri, 18 Nov 2022 18:24:49 +1000 [thread overview]
Message-ID: <Y3dBUXPhTskCx+Fu@erisian.com.au> (raw)
In-Reply-To: <JXfTBjsA71dHE3h9wkxnWXANrwTbMADO4s2w34gEvMbiduKu4PEt5t-KA3EAIz-Xs4urjBHZ15NDFZST2a7e0x_NqyJymUnEORuTp3SNfMs=@wuille.net>
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
next prev parent reply other threads:[~2022-11-18 8:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-08 12:59 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 [this message]
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
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=Y3dBUXPhTskCx+Fu@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@wuille$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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