Bip draft: Bitcoin Encrypted Backup #1951

pythcoiner · 2025-09-04T06:47:33Z

This is a bip for encrypted backup, an encryption scheme for bitcoin wallet related metadata.

Mailing list post: https://groups.google.com/g/bitcoindev/c/5NgJbpVDgEc

bip-encrypted-backup.md

Sjors · 2025-09-04T08:07:49Z

bip-encrypted-backup.md

+
+#### Content
+
+`CONTENT`: 1-byte unsigned integer identifying what has been encrypted.


I would prefer to keep this secret and have multiple pieces of content in a single backup. So my suggestion is to move this inside the encrypted payload and then allow for multiple content entries.

and then allow for multiple content entries

hum, no strong opinion on this, but if the purpose is to have a single encrypted file containing descriptor(380 or 388) + labels + wallet metadata then it should fit into 0x04 Wallet Backup (yeah I'll have to write a formal spec)

In the original delving post there's no specification of the format at all. So you could also just say it should be JSON and leave it up to other BIPs or convention.

Yeah this BIP draft differ a bit from the initial post in the fact it intentionally add some formating convention

@Sjors, in aa37c4b I've moved CONTENT to the encrypted part, letting some room for extension, like for embed several content types.

Sjors · 2025-09-04T08:10:03Z

bip-encrypted-backup.md

+| 0x01   | BIP-0380 Descriptor (string)           |
+| 0x02   | BIP-0388 Wallet policy (string)        |
+| 0x03   | BIP-0329 Labels (JSONL)                |
+| 0x04   | Wallet backup (JSON)                   |


Maybe point out that unlisted types should still be decrypted and that new types may be added to the BIP.

That said, a more generic approach would be to allow a bit more space for the type. E.g. a ~4 digit number that must represent a BIP number. Or a short string like "BIP-0329". Both avoid the need to maintain a central register.

Also, if you allow multiple pieces of content in a single encrypted blob, it's useful to have a padding type.

bip-encrypted-backup.md

pythcoiner · 2025-09-04T09:42:45Z

thanks for the review! will address comments tmr!

Sjors · 2025-09-04T12:52:31Z

Open questions

Deterministic nonce: Currently the nonce is generated randomly. Is it safe to produce a deterministic nonce, e.g. hash("NONCE" || plaintext || key_1 || … || key_n), or are there known security concerns with this approach?

In general nonce reuse is unsafe because if you make multiple backups over time, e.g. as you add more transaction labels, you would be reusing the nonce with different message. By including the plaintext in the nonce, you do address that concern.

However it still seems unwise to mess with cryptographic standards. It doesn't seem worth the risk for saving 32 bytes on something that's going to be at least a few hundred bytes for a typical multisig.

shocknet-justin · 2025-09-04T17:09:38Z

Concept ACK, seems adjacent to how some lightning tools enable users to recover SCB's with just their seed to identify and decrypt the backup. Makes sense for descriptors to have something similar.

Sjors · 2025-09-05T06:59:06Z

Concept ACK

pythcoiner · 2025-09-05T09:50:54Z

(not yet finish addressing comments)

bip-encrypted-backup.md

KeysSoze · 2025-09-09T21:57:53Z

Hi @pythcoiner,

By coincidence, two weeks ago I started working on a proposal for a "Standard Encrypted Wallet Payload" to be placed inside an "Encrypted Envelope". The "Wallet Payload" contains descriptors and metadata but can also act as a full wallet backup including transactions, UTXOs and addresses. The proposal is very much a work in progress.

I only just found this discussion so am reading through it to compare it to my proposal. The descriptor backup in the "Wallet Payload" of my proposal seems to have some overlap with the BIP proposed here. If there is too much overlap I may reconsider progressing with my proposal.

As mentioned, my proposal is very much a work in progress but the wallet payload proposal can be found here:

https://gist.github.com/KeysSoze/7109a7f0455897b1930f851bde6337e3

Maybe jump to the test vector section to see what a basic backup of a descriptor and some meta data would look like prior to encryption.

https://gist.github.com/KeysSoze/7109a7f0455897b1930f851bde6337e3#test-vectors

As my proposal is designed to be modular and extensible the encryption envelopes may be extended to offer Multiparty Encryption and Authentication. See:

https://gist.github.com/KeysSoze/7109a7f0455897b1930f851bde6337e3#user-content-Expanding_the_Security_Model

I have already started documenting an encryption envelope that uses AES-256-GCM and password protection:

https://gist.github.com/KeysSoze/866d009ccd082edf6802df240154b20d

I have not written a reference implementation yet but there are well established python and Rust libraries for CBOR and COSE that should make implementing the BIPs relatively simple.

pythcoiner · 2025-09-13T10:05:44Z

Hi @pythcoiner,

By coincidence, two weeks ago I started working on a proposal for a "Standard Encrypted Wallet Payload" to be placed inside an "Encrypted Envelope". The "Wallet Payload" contains descriptors and metadata but can also act as a full wallet backup including transactions, UTXOs and addresses. The proposal is very much a work in progress.

Hi @KeysSoze, this work seems more related/parallel to the wallet_backup specs I've work on few month ago.

But I've adopted a slightly different approach by simply using JSON.

FYI we already implemented this wallet backup format in Liana wallet and I plan to work on a BIP proposal relatively soon.

abrahem79

bip-encrypted-backup.md

jp1ac4 · 2025-09-15T12:01:03Z

bip-encrypted-backup.md

+
+### Secret generation
+
+- Let $p_1, p_2, \dots, p_n$, be the public keys in the descriptor/wallet policy, in increasing lexicographical order


We might like to use a subset of the public keys in some cases, e.g. if a Taproot descriptor contains an unspendable internal key that is commonly used across multiple descriptors.
cc @bigspider @darosior

right, we also need to specify that BIP0341 NUMS MUST be sorted out

Ideally, for wallet policies, in the long term we might want to introduce a placeholder for a deterministically derived NUMS key, as discussed for example here. So there wouldn't be any xpub at all. But that's not currently specified in BIP-388.

Explicitly excluding all the pubkeys with x coordinate 50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0 seems appropriate and should be forward-compatible with variations of this scheme.

It might be worth mentioning that one could choose just a subset of it is not intended for some of these keys to be able to recover from the backup. The caveat is that it becomes application-specific which of those keys should be able to recover. So if that's mentioned, this should be discussed a bit (for example by adding a recommendation to clearly specify the details in the documentation of the application).

what i'm actually wondering: is there any constructions that have an unspendable key NOT using the BIP341 NUMS?
@hugohn @ben-kaufman @Rob1Ham

Is there some Lightning constructions using unspendable keys?

pythcoiner marked this pull request as draft September 4, 2025 06:47

pythcoiner force-pushed the encrypted_descriptor branch from 2a6e241 to d9d02ff Compare September 4, 2025 07:02

Sjors reviewed Sep 4, 2025

View reviewed changes

jonatack added the New BIP label Sep 4, 2025

qlrd mentioned this pull request Sep 4, 2025

Tópicos Setembro saopaulobitdevs/saopaulobitdevs.org#63

Open

pythcoiner force-pushed the encrypted_descriptor branch 7 times, most recently from 1e4ca34 to 3b6b6ad Compare September 5, 2025 06:30

epcgrs mentioned this pull request Sep 7, 2025

Setembro/2025 poabitdevs/poabitdevs.org#10

Open

pythcoiner mentioned this pull request Sep 8, 2025

[WIP] Encrypted backup wizardsardine/liana#1807

Draft

7 tasks

torkelrogstad reviewed Sep 8, 2025

View reviewed changes

bip-encrypted-backup.md Outdated Show resolved Hide resolved

PeterMcBTC mentioned this pull request Sep 11, 2025

Create encrypted_descriptor.md proto-at-block/bitkey#6

Open

douglaz mentioned this pull request Sep 11, 2025

Consider supporting the new descriptors-focused encrypted format douglaz/cyberkrill#95

Open

PeterMcBTC mentioned this pull request Sep 12, 2025

Create EncryptedMultisigDescriptor.java sparrowwallet/sparrow#1788

Open

pythcoiner mentioned this pull request Sep 12, 2025

move content metadata to the encrypted payload pythcoiner/encrypted_backup#5

Merged

pythcoiner force-pushed the encrypted_descriptor branch 3 times, most recently from e6be331 to ab0d14d Compare September 13, 2025 09:38

bip encrypted_backup

2ce692d

pythcoiner force-pushed the encrypted_descriptor branch from ab0d14d to 2ce692d Compare September 13, 2025 09:44

make content private

aa37c4b

abrahem79 reviewed Sep 14, 2025

View reviewed changes

jp1ac4 reviewed Sep 15, 2025

View reviewed changes


		#### Content

		`CONTENT`: 1-byte unsigned integer identifying what has been encrypted.


		### Secret generation

		- Let $p_1, p_2, \dots, p_n$, be the public keys in the descriptor/wallet policy, in increasing lexicographical order

Bip draft: Bitcoin Encrypted Backup #1951

Are you sure you want to change the base?

Bip draft: Bitcoin Encrypted Backup #1951

Uh oh!

Conversation

pythcoiner commented Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pythcoiner commented Sep 4, 2025

Uh oh!

Sjors commented Sep 4, 2025

Uh oh!

shocknet-justin commented Sep 4, 2025

Uh oh!

Sjors commented Sep 5, 2025

Uh oh!

pythcoiner commented Sep 5, 2025

Uh oh!

Uh oh!

KeysSoze commented Sep 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pythcoiner commented Sep 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

abrahem79 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bigspider Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pythcoiner commented Sep 4, 2025 •

edited

Loading

KeysSoze commented Sep 9, 2025 •

edited

Loading

pythcoiner commented Sep 13, 2025 •

edited

Loading

bigspider Sep 16, 2025 •

edited

Loading