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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
|
Delivery-date: Mon, 04 Nov 2024 10:34:40 -0800
Received: from mail-ot1-f64.google.com ([209.85.210.64])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBCHPZ5PLQIPBBOFHUS4QMGQEY56WGNA@googlegroups.com>)
id 1t81uS-0001l3-DH
for bitcoindev@gnusha.org; Mon, 04 Nov 2024 10:34:40 -0800
Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7180fe954a7sf2317794a34.3
for <bitcoindev@gnusha.org>; Mon, 04 Nov 2024 10:34:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1730745274; x=1731350074; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=a6LueT5YAtH94ooFft0aFVkK8d7oFk0r33YxIU975lA=;
b=cmi6U6SnQP6cMEz8huoVwZ6UTzj6l1XI9AAIRMZYs8Fv3GNLRmNLhha4QMEh3PiXSz
+XTzE/pycGLqyMw9JMNtzrmO4EeiIdIcmfJlAjWSGRNJfXbXFdFAVBf/xWuDnD8b9jTT
SkZOLlM2pH8EnNbCnBKpbgNK88z25NpYU3ro2sidnODBLxBndKlxacXtc8j0WPObtZJn
H15yrNQ1NID5fKTnEj5nfLrn0eDKJKoW1cj8GDC1P1widqClK2iV1hxRH7SCEKvWhlU5
lY81InXC8uVUhbZD+q5W1oq5oAqAzEY5e2VH6fxeIAPQ/NWuER9D22+aD/mKhPRMFU4c
tFZw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1730745274; x=1731350074; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:from:to:cc:subject:date:message-id
:reply-to;
bh=a6LueT5YAtH94ooFft0aFVkK8d7oFk0r33YxIU975lA=;
b=btpjYzWISuoAldiVkvfbriouC6w9C3jMEeeQHNub5PbhOKSpjMj8Ya7r3ZFUfcZzZ4
As+H5RJnBW36JTJuANiIbx5F7Q1yGupTM5K2ApYdAVPWeDVyfgIdxCJmctLzyzxLYXYK
N5L6VPRO+WnMHf5X1U63FIEqrtumHf5yKaxgBNDJw93xfzpWxTEb0PujmS3BLvuFgqhl
IcE5tn2BHzUOv3EjQ7cmq/nC3wZUpYv1VOUz5THQP9efWwYU3jvZSsBnC5ua6juI7xjo
A8S6UcuNSC40hXp/OrWRZgiJcPJr7ELY4VDD+Xu6VfB7W9vVDDTYHI0JKHEZutbQD0gn
Ja1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1730745274; x=1731350074;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:x-beenthere:x-gm-message-state
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=a6LueT5YAtH94ooFft0aFVkK8d7oFk0r33YxIU975lA=;
b=NQK4ot26Trcrm6eq8Of1wT+4onFy4FInoa04NuZUsGZQpjK88EdE03IT1rrdOExx40
0G8LuMgsv0BjwGX7/gFa1XCQC839kV0DKmCldCyIV9mY81K/zJCU+qhXJ+XKuSK9DA6e
3gaAl2dv3YgkwDLjXadsGHe1Eim6c8jhjU/zYGwS5WImbIJN8P9E1ej60C6DazFVt4nq
pRtNmOzvs2dHR17iigCCCKhClfF8yA6bM4kLjSV7ikwaIcFG+Q0XLcpScTI57mZcqQcC
7P0plI7dEJ7mSc6Z8XnKq42Qw2n1u9efvCVCWIrfi6r8w0LVftkPhgykDlBnr0x8lmuP
vvBQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXS8VTX5HYmB6Zdf+6t6V4C3a4vmt6OlRg5q179Tlk41fOL7Hj0umkHeRMTUVjDGqgbfcJwDLn0WkIs@gnusha.org
X-Gm-Message-State: AOJu0YzBnCZOAz0kho8OjtRJQLIlFrZYX9GrribyIyU6WNT+tBAsr7nE
s4jSDueiiLItvrUWO2HyNfCLVKU4ts+kusFfaRM3b4WtNIMUmXnm
X-Google-Smtp-Source: AGHT+IGxbcF1Oh2keaTu8uusGM802xd1wWzxd4g+v6LiTcFLBpmok7LwzZtL6IiGMfq0krOg4kitNg==
X-Received: by 2002:a05:6830:2b1e:b0:718:9989:efac with SMTP id 46e09a7af769-719ca1c95cdmr11990217a34.18.1730745274186;
Mon, 04 Nov 2024 10:34:34 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a4a:bd91:0:b0:5ec:5a17:c5e with SMTP id 006d021491bc7-5ec6d2a5929ls307033eaf.1.-pod-prod-01-us;
Mon, 04 Nov 2024 10:34:32 -0800 (PST)
X-Received: by 2002:a05:6808:f13:b0:3e4:d3f6:6c97 with SMTP id 5614622812f47-3e6583e2b8bmr16731531b6e.46.1730745272199;
Mon, 04 Nov 2024 10:34:32 -0800 (PST)
Received: by 2002:a05:6808:1c1:b0:3e0:34ec:bb48 with SMTP id 5614622812f47-3e759dc8bcemsb6e;
Mon, 4 Nov 2024 10:29:56 -0800 (PST)
X-Received: by 2002:a05:6830:3789:b0:718:15a9:505a with SMTP id 46e09a7af769-719ca2428cfmr13587287a34.23.1730744994092;
Mon, 04 Nov 2024 10:29:54 -0800 (PST)
Date: Mon, 4 Nov 2024 10:29:53 -0800 (PST)
From: Robert Netzke <rob.netzke@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <4c51d18b-2444-4939-8f12-d0abe6d11e20n@googlegroups.com>
Subject: [bitcoindev] File Format for Wallet Inheritance and Recovery
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_325866_557385027.1730744993824"
X-Original-Sender: rob.netzke@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_325866_557385027.1730744993824
Content-Type: multipart/alternative;
boundary="----=_Part_325867_879650391.1730744993824"
------=_Part_325867_879650391.1730744993824
Content-Type: text/plain; charset="UTF-8"
Hello,
I made a post on Delving Bitcoin
<https://delvingbitcoin.org/t/file-format-for-recovering-descriptor-wallets/1115>
describing a file format for importing and exporting descriptor-based
wallets. After further discussion, I believe it is suitable to propose as a
BIP, and I am seeking further feedback.
*Motivation*
As to not simply repeat the motivation section in my reference
implementation, I will try to include some new thoughts after leaving this
proposal alone for a while. Inheritance is a difficult problem when
considering heirs that may not be technically apt. There are many services
indeed that build around a smooth inheritance model, yet these entities may
also terminate operations in the future. My feeling is the missing
component of truly robust inheritance is an open standard for backing up
wallet data. Mnemonic phrases are great, however a set of mnemonics is not
sufficient to recover the descriptor for any number of potential
configurations.
A simple file type to backup the public metadata about a wallet,
potentially including directions, notes, and public descriptor data, would
alleviate challenges for heirs when attempting to recover funds. Further
still, the file would also allow interoperability between semi-custodial
services that offer inheritance services. One service may fall as another
one rises, but customers may simply export their wallet metadata with a few
clicks if contained in a file. Importantly, an heir need not know what a
descriptor is, only that their benefactor has given them the specified
file.
*Implementation*
I wrote a reference implementation in Rust with the link contained in the
Delving Bitcoin post. After further thought, I am thinking it makes more
sense to closely follow, or even adopt, the data encoding used in PSBT.
Reading and writing to files should be made as easy as possible for
developers, so I believe a simple key-value mapping would see the most
adoption.
Thank you for reading, and if you have further feedback or would use such a
file for managing a wallet, please let me know!
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4c51d18b-2444-4939-8f12-d0abe6d11e20n%40googlegroups.com.
------=_Part_325867_879650391.1730744993824
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello, <br /><br />I made a post on <a href=3D"https://delvingbitcoin.org/t=
/file-format-for-recovering-descriptor-wallets/1115">Delving Bitcoin</a>
describing a file format for importing and exporting descriptor-based=20
wallets. After further discussion, I believe it is suitable to propose=20
as a BIP, and I am seeking further feedback. <br /><br /><b>Motivation</b><=
br /><br />As
to not simply repeat the motivation section in my reference=20
implementation, I will try to include some new thoughts after leaving=20
this proposal alone for a while. Inheritance is a difficult problem when
considering heirs that may not be technically apt. There are many=20
services indeed that build around a smooth inheritance model, yet these=20
entities may also terminate operations in the future. My feeling is the=20
missing component of truly robust inheritance is an open standard for=20
backing up wallet data. Mnemonic phrases are great, however a set of=20
mnemonics is not sufficient to recover the descriptor for any number of=20
potential configurations. <br /><br />A simple file type to backup the=20
public metadata about a wallet, potentially including directions, notes,
and public descriptor data, would alleviate challenges for heirs when=20
attempting to recover funds. Further still, the file would also allow=20
interoperability between semi-custodial services that offer inheritance=20
services. One service may fall as another one rises, but customers may=20
simply export their wallet metadata with a few clicks if contained in a=20
file. Importantly, an heir need not know what a descriptor is, only that
their benefactor has given them the specified file. <br /><br /><b>Impleme=
ntation</b><br /><br />I
wrote a reference implementation in Rust with the link contained in the
Delving Bitcoin post. After further thought, I am thinking it makes=20
more sense to closely follow, or even adopt, the data encoding used in=20
PSBT. Reading and writing to files should be made as easy as possible=20
for developers, so I believe a simple key-value mapping would see the=20
most adoption. <br /><br />Thank you for reading, and if you have further f=
eedback or would use such a file for managing a wallet, please let me know!
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/4c51d18b-2444-4939-8f12-d0abe6d11e20n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/4c51d18b-2444-4939-8f12-d0abe6d11e20n%40googlegroups.com</a>.<br />
------=_Part_325867_879650391.1730744993824--
------=_Part_325866_557385027.1730744993824--
|
