Delivery-date: Mon, 04 Nov 2024 10:34:40 -0800
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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&quot; 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--