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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
Return-Path: <RobertSpigler@protonmail.ch>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 45F4EC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 14 Mar 2021 20:46:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 1FC2583A7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 14 Mar 2021 20:46:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.ch
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 2cIrtaT5DXAr
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 14 Mar 2021 20:46:22 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18])
by smtp1.osuosl.org (Postfix) with ESMTPS id 74E9083A79
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 14 Mar 2021 20:46:22 +0000 (UTC)
Date: Sun, 14 Mar 2021 20:46:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch;
s=protonmail; t=1615754779;
bh=jiK4oKjOb1czOc0vaXBe9MehcgISI0qj2age8Uhw7sA=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=dCE6hQlJ4JL9t2WYd0fiYJHpHnHomyDwHtRnpHaCPN2Oa1DPHxde2uW7vS7Poyx1M
lhbZDBQqE0BruQEdd5Vt2VH/qHhlcxbFrtxCb3f7zrBBjXi4YKiknCAPssZP7DsOfs
gz323ysIoVyg6bKL0eM+5eez6B1Zz++NehK47gT8=
To: SomberNight <somber.night@protonmail.com>,
"bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
From: Robert Spigler <RobertSpigler@protonmail.ch>
Reply-To: Robert Spigler <RobertSpigler@protonmail.ch>
Message-ID: <QZfbtDnhhbNNFo6859MyCotRPeN-sdotrP2qM-Uitq5DYATVzqIgIb_UEtXETGk941M3HWDzxCmO9j84wjzuKndHOo6kxg3A9qCd8WWlAOI=@protonmail.ch>
In-Reply-To: <z1Vokp3jct_xwR8wt3n6r8t24DqtMpnrogF22YFc0_V3riIMWEq3WBiOriJOm2kVrVgtsu5p7wDTMrN3dLdA8DilhITMXb4tHY6wCnk3y1g=@protonmail.com>
References: <z1Vokp3jct_xwR8wt3n6r8t24DqtMpnrogF22YFc0_V3riIMWEq3WBiOriJOm2kVrVgtsu5p7wDTMrN3dLdA8DilhITMXb4tHY6wCnk3y1g=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 16 Mar 2021 12:18:47 +0000
Subject: Re: [bitcoin-dev] Signature and Script Independent Hierarchy for
Deterministic Wallets.
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: Sun, 14 Mar 2021 20:46:24 -0000
No, wallets don't and shouldn't have to check all script types on recovery.=
Descriptor Wallets solve all of this.
To back up a multisignature wallet, each cosigner stores their xprv (how yo=
u do this; BIP39, WIF, etc, is out of scope). and the wallet descriptor. T=
his is done, for example, in Yeti. To recover, simply combine `M` private k=
eys, and check the script designated in 1 of the descriptor copies.
For single signature wallets, it is the same, except only one signature is =
needed. Store xprv and descriptor.
It is not fair nor accurate to say that currently, in order to recover, wal=
lets need "just the seed words". They also need all public keys, and deriv=
ation paths.
Descriptors (and this BIP), is a much cleaner way to handle wallet creation=
and backup, by separating the two layers (keys and scripts) and getting ri=
d of redundant information.
Personal Fingerprint:=C2=A0 BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 54=
8F
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Sunday, March 14, 2021 11:13 AM, SomberNight <somber.night@protonmail.co=
m> wrote:
> See some replies inline. (quoted text from BIP draft)
>
> > Date: Sun, 14 Mar 2021 01:51:15 +0000
> > From: Robert Spigler RobertSpigler@protonmail.ch
> > Subject: [bitcoin-dev] Signature and Script Independent Hierarchy for D=
eterministic Wallets.
>
> > There are many issues with the current standards. As background, BIP 44=
/49/84 specifies:
> > `m / purpose' / coin_type' / account' / change / address_index`
> > where the BIP43 `purpose'` path is separate for each script (P2PKH, P2W=
PKH-in-P2SH, and P2WPKH respectively). However, these per-script derivation=
s are made redundant with descriptors
>
> > We should not be mixing keys and scripts in the same layer. The wallet =
should create extended private/public keys independent of the script or sig=
nature type
>
> You say that keys and scripts should not be mixed in the same layer, and =
imply that this was solely done due to these standards predating output scr=
ipt descriptors. Even if this was the case, it is not the only reason for d=
oing it. BIP44/49/84 mixing scripts and keys in the same layer makes recove=
ry from seed/mnemonic much easier.
> Note the significant overlap between the authors of BIP39 and BIP44. I am=
fairly certain BIP44 was designed with recovering from a BIP39 seed (and n=
o additional information backed up) in mind. Note the "Account discovery" s=
ection of BIP44.
> (Electrum seeds go even further, as such seeds contain a version number t=
hat encodes both the script type and the key derivation path to use.)
>
> > We define the following 5 levels in the BIP32 path:
> > `m / purpose' / coin_type' / account' / change / address_index`
>
> > [Account]
> > It is crucial that this level is increased for each new wallet joined o=
r private/public keys created; for both privacy and cryptographic purposes.
> > For example, in multisignature wallets, before sending a new key record=
to a coordinator, the wallet must increment the `account'` level. Before c=
reating it's own single signature wallet, the `account'` level must again b=
e incremented.
>
> Imagine a user who has a BIP39 (or similar) seed. Even today, recovering =
most non-singlesig scripts from that is obviously infeasible. However, all =
singlesig scripts at least can be discovered if the keys are using the sugg=
ested derivation paths.
> By trying to create a standard that mixes discoverable and non-discoverab=
le scripts in the same derivation scheme and incrementing a single index, y=
ou are turning all scripts into being non-discoverable.
> Note that even if a user only used singlesig scripts and followed this pr=
oposal, during recovery from seed the wallet would have to check all script=
types for all account indices (which is only ever going to get more expens=
ive as new script types come).
> The workaround and I imagine your suggested solution is clearly to backup=
both seed words and output script descriptors; and to keep appending new o=
utput script descriptors to existing backups when the account index is incr=
emented. While much less user-friendly than backing up just a seed, it is m=
ore generic and extendable.
>
> My point is simply that your proposal is making a tradeoff here. The trad=
eoff itself seems easy to miss on first read of the text, so I just wanted =
to explicitly point it out for the record.
>
> ghost43 / SomberNight
|
