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
132
133
|
Return-Path: <dp@simplexum.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id B4177C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Jul 2022 09:46:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7A32183E8A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Jul 2022 09:46:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7A32183E8A
Authentication-Results: smtp1.osuosl.org;
dkim=pass (1024-bit key) header.d=simplexum.com header.i=@simplexum.com
header.a=rsa-sha256 header.s=mail header.b=nIM3gnfA
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id uYP1GAIrEe6o
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Jul 2022 09:46:06 +0000 (UTC)
X-Greylist: delayed 00:05:12 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 342F983381
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
by smtp1.osuosl.org (Postfix) with ESMTPS id 342F983381
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Jul 2022 09:46:06 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
by mail.ruggedbytes.com (Postfix) with ESMTPS id DFAF22600185
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Jul 2022 09:40:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
s=mail; t=1659001250;
bh=TFKG82utdwIk0ndJ6iE1won/RQ4yXuajZwqqoBX48dk=;
h=Date:From:To:Subject:In-Reply-To:References;
b=nIM3gnfApgRnrJvCbW+zuHO1zkgdzapd45J1w7FWqaAqGxPZ+KpEERuQJ613K+H4j
/UKQtoJF6xE3nRvm2JHdNA6RVGdXl/MPq2beodSJQcFRMKlEJ8dl2ozF1ZXbIRGN0W
ke1Mb5VHnQTq70nwoqryzG92Fh1JBqLMk8iRtM3E=
Date: Thu, 28 Jul 2022 11:40:16 +0200
From: Dmitry Petukhov <dp@simplexum.com>
To: Andrew Chow via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220728114016.2ff78722@simplexum.com>
In-Reply-To: <7bded922-5067-caee-e5be-9f620cfc7404@achow101.com>
References: <7bded922-5067-caee-e5be-9f620cfc7404@achow101.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 28 Jul 2022 10:14:49 +0000
Subject: Re: [bitcoin-dev] BIP Proposal: Receiving and Change Derivation
Paths in a Single Descriptor
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, 28 Jul 2022 09:46:10 -0000
The issue with tuples of lenth more than two is that the purpose for
indexes beyond 'receive' and 'change' are not established, and
therefore various software might start to use extra indexes in a tuple
for their own non-standard purposes. This is bound to create
incompatibilities where different wallet software that import the same
descriptor would use those addresses for different purposes.
Even if some auxiliary standard emerges for the meanings of extra
indexes, since the indexes in the tuple are listed without omissions (no
"<0;1;;;3>" allowed), all software will need to be aware of the
existence of these purposes and define indexes for them: if one wishes
to utilize position 3 in such a tuple, they will need to define an index
for position 2 as well.
I'd expect that emergence of new widely-used purposes for indexes would
be a very rare event, and a separate BIP for each purpose wouldn't be
excessive.
I'd say that bip-multipath-descs should say that extra indexes are OK
for address discovery (for scanning of the addresses of a wallet), but
it should say that any interpretation of the purpose of such indexes
and deriving new addresses at these indexes are strongly discouraged.
Wallet software that wishes to utilize non-standard extra indexes beyond
'receive' and 'change' should use separate descriptors instead for
these extra indexes.
And when a new established purpose emerges for the next position in the
index tuple, a new BIP should be made that defines such position.
The BIP for position 3 would naturally come after the BIP for position
2, and thus software that implemnents BIP for position 3 would be aware
of the previous BIP and will at least know to choose some index for
position 2.
=D0=92 Wed, 27 Jul 2022 14:58:28 +0000
Andrew Chow via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
wrote:
> I've updated the BIP text to allow arbitrary length tuples.
>=20
> On 07/27/2022 04:44 AM, Pavol Rusnak wrote:
>=20
> > On Wed, 27 Jul 2022 at 00:28, Andrew Chow
> > <achow101-lists@achow101.com> wrote:=20
> >> However I don't see why this couldn't generalize to any sized
> >> tuples. As long as the tuples are all the same length, and the
> >> limit is one tuple per key expression, then we don't get any
> >> combinatorial blowup issues. =20
> >
> > I think it's worthwhile to generalize for any sized tuples. I don't
> > have any existing particular use case in mind, because BIP-44,
> > BIP-84, etc. are fine with just using <0;1>, but there might be
> > some upcoming standards in the future that will want to introduce
> > more sub-paths.
> >
> > --
> >
> > Best Regards / S pozdravom,
> >
> > Pavol "stick" Rusnak
> > Co-Founder, SatoshiLab =20
|
