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
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6733EC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Nov 2022 08:25:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 34DD260B6F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Nov 2022 08:25:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 34DD260B6F
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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id z5sjFX6kjHs7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Nov 2022 08:24:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org BFBF56063B
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp3.osuosl.org (Postfix) with ESMTPS id BFBF56063B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Nov 2022 08:24:57 +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 1ovwg9-0005q8-6B; Fri, 18 Nov 2022 18:24:54 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 18 Nov 2022 18:24:49 +1000
Date: Fri, 18 Nov 2022 18:24:49 +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: <Y3dBUXPhTskCx+Fu@erisian.com.au>
References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
<zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net>
<Y2nK99fHUKxbPHmw@erisian.com.au>
<wDqcIVw-YGTsjdf5M2GO9NNRl_UQuBeka2CUQUyQ329u6u-o7RabW_7S4FD3EDfk02kUczb3bXf8LtHhKLtx773UhQ7djKOl-JPOIrXqBSc=@wuille.net>
<JXfTBjsA71dHE3h9wkxnWXANrwTbMADO4s2w34gEvMbiduKu4PEt5t-KA3EAIz-Xs4urjBHZ15NDFZST2a7e0x_NqyJymUnEORuTp3SNfMs=@wuille.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <JXfTBjsA71dHE3h9wkxnWXANrwTbMADO4s2w34gEvMbiduKu4PEt5t-KA3EAIz-Xs4urjBHZ15NDFZST2a7e0x_NqyJymUnEORuTp3SNfMs=@wuille.net>
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: Fri, 18 Nov 2022 08:25:02 -0000
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
|
