From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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,

I made a post on Delving Bitcoin 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.

Motivation<= 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.

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.

Impleme= ntation

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.

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!

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/4c51d18b-2444-4939-8f12-d0abe6d11e20n%40googlegroups.com.
------=_Part_325867_879650391.1730744993824-- ------=_Part_325866_557385027.1730744993824--