BIP: Standard Encrypted Wallet Payload #1981

KeysSoze commented at 2:08 AM on September 24, 2025: none

This pull request proposes a new BIP for a standard, interoperable format for encrypted wallet backups and transfers.

The core design choice is the separation of the data payload from the cryptographic container. This BIP specifies the payload format, while mandating that it must be encrypted by a container defined in companion proposals.

Key features include:

CBOR Serialisation: Uses CBOR for a compact, efficient, and extensible binary format suitable for resource-constrained devices.
Descriptor-Centric: Aligns with modern wallet architecture by using BIP 380 Output Script Descriptors as the primary method for defining accounts.
Comprehensive Data: The schema includes accounts, master secret material, transaction data, UTXOs and standardised metadata.

This proposal was previously posted to the Bitcoin-Dev mailing list: https://groups.google.com/g/bitcoindev/c/3I-qtBhzIGY

Seeking assignment of a BIP number and welcoming all feedback.

murchandamus added the label New BIP on Oct 6, 2025

bitcoin deleted a comment on Dec 17, 2025

murchandamus commented at 12:00 AM on February 28, 2026: member

Hello @KeysSoze,

This document is incorrectly formatted in a manner that makes me think that it was AI generated. If you are still interested in pursuing this proposal, could you please fix the formatting?

At this time, given the lack of replies on the mailing list and comments on this PR, it is not clear to me that this proposal is being pursued for implementation by any Bitcoin project. Given that there are several other backup related proposals in flight, perhaps some of the corresponding authors would be interested in reviewing your document if you review theirs.

I‘d be happy to provide a more thorough review when this proposal has gotten review from other parties and that review has been addressed, or the proposal otherwise distinguishes itself from its perceived AI-generated origin.

murchandamus commented at 6:24 PM on May 20, 2026: member

Hello @KeysSoze, I was referring to the unnecessary HTML tags in the document. If you are still working on this, there are some similar proposals that have been recently merged or are still in flight

which might interest you.

Standard Encrypted Wallet Payload 91771d10d1

Updated formatting

Changed preamble to more closely follow BIP standards
Removed table of contents

e2ea8c0004

Remove superfluous html `<span>` tags 7f4c32eade

KeysSoze force-pushed on May 21, 2026

KeysSoze commented at 10:25 PM on May 21, 2026: none

Hi @murchandamus,

here are some similar proposals that have been recently merged or are still in flight

BIP139: Wallet Metadata Backup Format

which might interest you.

Yes, it seems BIP139: Wallet Metadata Backup Format is quite similar to this proposal.

But rather than using JSON, this proposal defines a rigid CDDL schema with deterministic CBOR, enforcing true inter-wallet compatibility. CBOR's compact binary nature drastically reduces the payload size making air-gapped QR codes or NFC transfers highly viable if defined in a companion BIP.

Furthermore, the modular nature of this proposal delegates security to battle-tested IETF standards like COSE via a separate companion BIP. This ensures the standard is inherently future-proofed. As cryptography advances developers can seamlessly upgrade ciphers, implement multi-party authorisation or adopt post-quantum algorithms within the security container without ever needing to alter the core wallet payload format.

in bip-wallet-payload.mediawiki:7 in 7f4c32eade

   0 | @@ -0,0 +1,791 @@
   1 | +<pre>
   2 | +  BIP: ?
   3 | +  Layer: Applications
   4 | +  Title: Standard Encrypted Wallet Payload
   5 | +  Authors: Keyser Söze <keys.soze@proton.me>
   6 | +  Status: Draft
   7 | +  Type: Standards Track

murchandamus commented at 10:49 PM on May 29, 2026:

  Type: Specification

in bip-wallet-payload.mediawiki:84 in 7f4c32eade

  79 | +|-
  80 | +| 2 || genesis_hash || bstr (32 bytes)  || The hash of the genesis block. || No
  81 | +|-
  82 | +| 3 || root || map || The wallet’s master secret material. || No
  83 | +|-
  84 | +| 10 || accounts || [+ map] || An array of account maps, each defined by a descriptor. || Yes

murchandamus commented at 10:54 PM on May 29, 2026:

Above it says that an account references one or more descriptors, but here it says that the accounts are defined by descriptors. This makes it sound like the descriptors are both keys and values.

in bip-wallet-payload.mediawiki:106 in 7f4c32eade

 101 | +{| class="wikitable"
 102 | +! Integer Value !! String Name !! Description
 103 | +|-
 104 | +| 0 || mainnet || The main Bitcoin production network.
 105 | +|-
 106 | +| 1 || testnet || The primary Bitcoin test network.

murchandamus commented at 10:57 PM on May 29, 2026:

There are multiple active testnets. If they are meant to be disambiguated per type + genesis_hash that could be communicated more explicitly.

in bip-wallet-payload.mediawiki:108 in 7f4c32eade

 103 | +|-
 104 | +| 0 || mainnet || The main Bitcoin production network.
 105 | +|-
 106 | +| 1 || testnet || The primary Bitcoin test network.
 107 | +|-
 108 | +| 2 || signet || The signet test network.

murchandamus commented at 10:58 PM on May 29, 2026:

While there is one default signet, there are also popular other signets (such as e.g., MutinyNet) and they are by design easy to create for anyone.

in bip-wallet-payload.mediawiki:120 in 7f4c32eade

 115 | +=== Root Map ===
 116 | +
 117 | +The root map contains the wallet’s master secret material from which all accounts and descriptors are derived. It may include the BIP-39 mnemonic, optional passphrase, raw entropy, or the derived BIP-39 seed. The root map is optional and a wallet '''MUST NOT''' contain more than one.
 118 | +
 119 | +{| class="wikitable"
 120 | +! Integer Key !! String Key !! Type !! Description !!

murchandamus commented at 10:59 PM on May 29, 2026:

! Integer Key !! String Key !! Type !! Description !! Required

Is this missing Required?

in bip-wallet-payload.mediawiki:258 in 7f4c32eade

 253 | +uint32 = uint .le 4294967295
 254 | +uint64 = uint .le 18446744073709551615
 255 | +network-type = 0 / 1 / 2 / 3  ; 0=mainnet,1=testnet,2=signet,3=regtest
 256 | +role-type    = 0 / 1          ; 0=receive,1=change
 257 | +txid-type = bstr .size 32
 258 | +address-type = p2pkh-address / p2sh-address / segwit-address

murchandamus commented at 11:02 PM on May 29, 2026:

How about taproot?

murchandamus commented at 11:07 PM on May 29, 2026: member

I gave this a first read. Has any Bitcoin project adopted this scheme or is working on adopting it? Please add the required Backwards Compatibility section.

murchandamus commented at 11:08 PM on May 29, 2026: member

cc: @pythcoiner, I thought you might be interested in this.