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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 389B6C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Jan 2023 23:13:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 069C840106
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Jan 2023 23:13:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 069C840106
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 04j6kArmAbRp
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Jan 2023 23:13:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 28196400E4
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp2.osuosl.org (Postfix) with ESMTPS id 28196400E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Jan 2023 23:12:59 +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 1pDZPq-0001N1-KP; Fri, 06 Jan 2023 09:12:55 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 06 Jan 2023 09:12:50 +1000
Date: Fri, 6 Jan 2023 09:12:50 +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: <Y7dZctMlZtH6PEsz@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>
<Y3dBUXPhTskCx+Fu@erisian.com.au>
<gSxFQedPc72pTioi9vuxvLKpaRBsnKFL4gkPKPn2G-EJgz_2Y1pYQ7cHD5SnunyCaLln7UQEHIxnopqP74LlnK__Mf9BURbJW8B5MYTZvCU=@wuille.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <gSxFQedPc72pTioi9vuxvLKpaRBsnKFL4gkPKPn2G-EJgz_2Y1pYQ7cHD5SnunyCaLln7UQEHIxnopqP74LlnK__Mf9BURbJW8B5MYTZvCU=@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: Thu, 05 Jan 2023 23:13:05 -0000
On Thu, Jan 05, 2023 at 10:06:29PM +0000, Pieter Wuille via bitcoin-dev wrote:
> > > 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).
> Oh, yes. I meant this as an encoding scheme, not as a (replacement for) the negotiation/coordination mechanism. There could still be an initial assignment for 1-byte encodings, and/or an explicit mechanism to negotiate other assignment, and/or nothing at all for now.
>
> I just thought it would be interesting to have a uniform encoding without explicit distinction between "short commands" and "long commands" at that layer.
> But maybe none of this is worth it, as it's perhaps more complexity than the alternative, and the alternative already has a working implementation and written-up specification.
Heh, I was just looking at this yesterday, but failing to quite reach
a conclusion.
One thing I hadn't realised about this was that it's not actually
a restriction compared to what we currently allow with p2p v1:
CMessageHeader::IsCommandValid() already rejects commands that use
characters outside of 0x20 to 0x7E, so the high bit is already available
for signalling when we reach the last byte.
The current implementation for 324 does the aliasing
as part of V2TransportDeserializer::GetMessage and
V2TransportSerializer::prepareForTransport. That makes a lot of sense,
but particularly if we were to negotiate short commands sometime around
VERSION or VERACK, it might make more sense for the aliasing to move up
to the protocol layer rather than have it close to the wire layer. In
that case having a uniform encoding means we could just keep using
CSerializedNetMsg whether we're sending a short command or a multibyte
ascii command -- without a uniform encoding, if we wanted to move short
commands up a layer, I think we'd need to change CSerializedNetMsg to
have m_type be a `std::variant<uint8_t,std::string>` instead of just a
string, or something similar.
I think I'm leaning towards "it doesn't matter either way" though:
* if we can negotiate short commands on a per-peer basis, then once
negotiation's finished we'll only be using short commands so saving a
byte on long commands doesn't matter much
* if we've only got around 30 or 40 commands we understand anyway
(even counting one-time-only negotiation stuff), then it doesn't
matter if we can do 102, 126 or 242 short commands since those are
all more than we need
* whether we'd have to tweak an internal struct if we want to change
the way our code is structured shouldn't really be much of an influence
on protocol design...
Cheers,
aj
|
