From: Anthony Towns <aj@erisian•com.au>
To: Pieter Wuille <bitcoin-dev@wuille•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Dhruv M <dhruv@bip324•com>
Subject: Re: [bitcoin-dev] Refreshed BIP324
Date: Mon, 20 Feb 2023 09:56:02 +1000 [thread overview]
Message-ID: <Y/K3Ejkwlj4NIMMa@erisian.com.au> (raw)
In-Reply-To: <S1zoL4CCIDVTrjmXx2JtYhO2qjgGyNIAP6X9FXRCRKPDjoQj20VcqKFCYkmmPQkNuMyNf9zp6GFVWWC7l8dBzCogUqvzmDx9D811NPheNJ8=@wuille.net>
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.
> > I think the things missing from the current list (and not currently in
> > use by bitcoin core) are:
> > bip 61: REJECT
> > bip 331: GETPKGTXNS, PKGTXNS, ANCPKGINFO
> Do you feel REJECT should be included?
I don't think it matters much; reject messages are both rare and include
a reason so you'd only be saving maybe 12 bytes out of 62 (~20%)
for maybe 6000 messages a day per peer that sends reject messages,
so 72kB/day/reject-peer?
> Perhaps a possibility is having the transport layer translate short-command-number-N to the 12-byte command "\x00\x00..." + byte(N), and hand that to the application layer, which could then do the mapping?
Presuming the transport layer also continues to reject commands that
have a '\x00' byte at the start or in the middle (ie !IsCommandValid()),
that seems pretty reasonable...
Cheers,
aj
next prev parent reply other threads:[~2023-02-19 23:56 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
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 [this message]
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=Y/K3Ejkwlj4NIMMa@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@wuille$(echo .)net \
--cc=dhruv@bip324$(echo .)com \
/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