From: Pieter Wuille <bitcoin-dev@wuille.net>
To: Anthony Towns <aj@erisian.com.au>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Dhruv M <dhruv@bip324.com>
Subject: Re: [bitcoin-dev] Refreshed BIP324
Date: Mon, 20 Feb 2023 15:22:30 +0000 [thread overview]
Message-ID: <1zGcFRzB9Has9bXWlYaOXXnOy9jxwLJvhkL_46OlA8JRsx2ultkYweDdPnW3Tbf145byXb8cG8pimWBT0qBBDaKisufJufP2wssDtigKass=@wuille.net> (raw)
In-Reply-To: <Y/K3Ejkwlj4NIMMa@erisian.com.au>
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.
Cheers,
--
Pieter
next prev parent reply other threads:[~2023-02-20 15:29 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 [this message]
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='1zGcFRzB9Has9bXWlYaOXXnOy9jxwLJvhkL_46OlA8JRsx2ultkYweDdPnW3Tbf145byXb8cG8pimWBT0qBBDaKisufJufP2wssDtigKass=@wuille.net' \
--to=bitcoin-dev@wuille.net \
--cc=aj@erisian.com.au \
--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