1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 769CBC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 03:20:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 5E725408A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 03:20:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5E725408A6
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id s-vHpCyJoO99
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 03:20:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6334840516
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp2.osuosl.org (Postfix) with ESMTPS id 6334840516
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 03:20:32 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1osFA4-0006BR-6c; Tue, 08 Nov 2022 13:20:29 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Tue, 08 Nov 2022 13:20:23 +1000
Date: Tue, 8 Nov 2022 13:20:23 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y2nK99fHUKxbPHmw@erisian.com.au>
References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
<zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net>
Cc: Dhruv M <dhruv@bip324.com>
Subject: Re: [bitcoin-dev] Refreshed BIP324
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2022 03:20:33 -0000
On Wed, Oct 26, 2022 at 04:39:02PM +0000, Pieter Wuille via bitcoin-dev wrote:
> However, it obviously raises the question of how the mapping table between the
> 1-byte IDs and the commands they represent should be maintained:
>
> 1. The most straightforward solution is using the BIP process as-is: let BIP324
> introduce a fixed initial table, and future BIPs which introduce new
> messages can introduce new mapping entries for it. [...]
> 3. Yet another possibility is not having a fixed table at all, and negotiate
> the mapping dynamically. E.g. either side could send a message at
> connection time with an explicit table of entries "when I send byte X, I
> mean command Y".
FWIW, I think these two options seem fine -- maintaining a purely local
and hardcoded internal mapping of "message string C has id Y" where Y
is capped by the number of commands you actually implement (presumably
less than 65536 total) is easy, and providing a per-peer mapping from
"byte X" to "id Y" then requires at most 512 bytes per peer, along with
up to 3kB of initial setup to tell your peer what mappings you'll use.
> Our idea is to start out with approach (1), with a mapping table effectively
> managed by the BIP process directly, but if and when collisions become a
> concern (maybe due to many parallel proposals, maybe because the number of
> messages just grows too big), switch to approach (3), possibly even
> differentially (the sent mappings are just additions/overwrites of the
> BIP-defined table mappings, rather than a full mapping).
I guess I think it would make sense to not start using a novel 1-byte
message unless you've done something to introduce that message first;
whether that's via approach (3) ("I'm going to use 0xE9 to mean pkgtxns")
or via a multibyte feature support message ("I sent sendaddrv3 as a
10-byte message, that implies 0xA3 means addrv3 from now on").
I do still think it'd be better to recommend against reserving a byte for
one-shot messages, and not do it for existing one-shot messages though.
Cheers,
aj
|
