``` BIP: ? Layer: Applications Title: Compact encryption scheme for non-seed wallet data Authors: Pyth Status: Draft Type: Specification Assigned: ? License: BSD-2-Clause Discussion: https://delvingbitcoin.org/t/a-simple-backup-scheme-for-wallet-accounts/1607 https://groups.google.com/g/bitcoindev/c/5NgJbpVDgEc/m/TtGK9sF9BgAJ ``` ## Introduction ### Abstract This BIP defines a compact encryption scheme for **output script descriptors** (BIP-0380), **wallet policies** (BIP-0388), **labels** (BIP-0329), and **wallet backup metadata** (draft [BIP](https://github.com/bitcoin/bips/pull/2130)). The payload must not contain any private key material. Users can store encrypted backups on untrusted media or cloud services without leaking addresses, script structures, or cosigner counts. The encryption key derives from the lexicographically-sorted public keys in the descriptor, allowing any keyholder to decrypt without additional secrets. Though designed for descriptors and policies, the scheme works equally well for labels and backup metadata. ### Copyright This BIP is licensed under the BSD 2-Clause License. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the above copyright notice and this permission notice appear in all copies. ### Motivation Losing the **wallet descriptor** (or **wallet policy**) is just as catastrophic as losing the seed itself. The seed lets you sign, but the descriptor maps you to your coins. For multisig or miniscript wallets, keys alone won't help: without the descriptor, you can't reconstruct the script. Offline storage of descriptors has two practical obstacles: 1. **Descriptors are hard to store offline.** Descriptors can be much longer than a 12/24-word seed. Paper and steel backups become impractical or error-prone. 2. **Online redundancy carries privacy risk.** USB drives, phones, and cloud storage solve the length problem but expose your wallet structure. Plaintext descriptors leak your pubkeys and script details. Cloud storage is often unencrypted, and even cloud encryption could be compromised, depending on (often opaque) implementation details. Its security also reduces to that of the weakest device with cloud access. Each copy increases the attack surface. This BIP therefore proposes an **encrypted**, compact backup format that: * can be **safely stored in multiple places**, including untrusted online services, * can be **decrypted only by intended holders** of specified public keys, See the original [Delving post](https://delvingbitcoin.org/t/a-simple-backup-scheme-for-wallet-accounts/1607/31) for more background. ### Expected properties * **Encrypted**: safe to store with untrusted cloud providers or backup services * **Access controlled**: only designated cosigners can decrypt * **Easy to implement**: it should not require any sophisticated tools/libraries. * **Vendor-neutral**: works with any hardware signer ### Scope This proposal targets output script descriptors (BIP-0380) and policies (BIP-0388), but the scheme also works for labels (BIP-0329) and other wallet metadata like [wallet backup metadata](https://github.com/bitcoin/bips/pull/2130). Private key material MUST be removed before encrypting any payload. ## Specification Note: in the followings sections, the operator ⊕ refers to the bitwise XOR operation. ### Secret generation - Let $p_1, p_2, \dots, p_n$, be the public keys in the descriptor/wallet policy, in increasing lexicographical order. The scheme is defined for any $n \geq 1$, in particular it supports single-signature descriptors ($n = 1$). Each $p_i$ is the x-only-normalized root public key of one *allowed* key expression (see [Descriptor key requirements](#descriptor-key-requirements)). - Let $s$ = sha256(sha256("BIPXXX_DECRYPTION_SECRET") | sha256("BIPXXX_DECRYPTION_SECRET") | $p_1$ | $p_2$ | ... | $p_n$) - Let $s_i$ = sha256(sha256("BIPXXX_INDIVIDUAL_SECRET") | sha256("BIPXXX_INDIVIDUAL_SECRET") | $p_i$) - Let $c_i$ = $s$ ⊕ $s_i$ Because $s$ and $s_i$ use distinct domain-separation tags, $s \neq s_i$ and therefore $c_i$ is never the all-zero string. **Note:** To prevent attackers from decrypting the backup using publicly known keys, explicitly exclude any public keys with x coordinate `50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0` (the BIP341 NUMS point, used as a taproot internal key in some applications). Additionally, exclude any other publicly known keys. Applications that exclude additional keys SHOULD document this, although decryption using these keys will simply fail. This does not affect decryption with the remaining keys. ### Descriptor key requirements Only key expressions of the extended-public-key type with a trailing derivation step or wildcard contribute to $\{p_1, \dots, p_n\}$. Without that derivation, the xpub's root pubkey, used to seed $s$, would also be the on-chain pubkey of every spend, so observing one spend would let anyone recompute $s$ and decrypt the backup.[^trailing-derivation] The rule generalizes to any network prefix (`xpub`/`tpub`/`Vpub`/...). [^trailing-derivation]: **Why require trailing derivation?** Any trailing derivation step, or the implicit child derivation forced by a wildcard, breaks the identity between the xpub root pubkey and the on-chain pubkey. Fixed-derivation expressions like `xpub.../0/5` are allowed because the on-chain key (`xpub/0/5`) already differs from the encryption seed (the xpub root). Literal pubkeys and bare xpubs are disallowed for the same reason: the literal value is exactly what goes on-chain, so $s$ would become recoverable from a single observed spend. Allowed forms (origin information `[...]` is optional and orthogonal): | Form | Example | |-------------------------------------------------------------|-------------------| | `/` (fixed derivation, no wildcard) | `xpub.../0/5` | | `/*` (wildcard only) | `xpub.../*` | | `//*` (fixed derivation followed by a wildcard) | `xpub.../0/*` | | `/` (multipath, no wildcard) | `xpub.../<0;1>` | | `//*` (multipath followed by a wildcard) | `xpub.../<0;1>/*` | Implementations: - MUST exclude every other form (literal pubkeys, bare xpubs, ...) from $\{p_1, \dots, p_n\}$. - MUST refuse to encode a backup if the resulting set is empty. - SHOULD make the user aware of each excluded expression, since the cosigner holding that key will be unable to decrypt the backup with their key. ### Key Normalization For each allowed expression, take the root extended public key (ignoring origin information, the trailing derivation path, the wildcard, and any multipath specifiers) and extract its x-coordinate. The result is the 32-byte **x-only public key** $p_i$.[^x-only] [^x-only]: **Why x-only keys?** X-only public keys are 32 bytes, a natural size for cryptographic operations. This format is also used in BIP340 (Schnorr signatures) and BIP341 (Taproot). ### Encryption The format uses CHACHA20_POLY1305 (RFC 8439) as the encryption algorithm, with a 96-bit random nonce and a 128-bit authentication tag to provide confidentiality and integrity. [^chacha-default]: **Why CHACHA20-POLY1305 ?** ChaCha20-Poly1305 is already used in Bitcoin Core (e.g., BIP324) and is widely available in cryptographic libraries. It performs well in software without hardware acceleration, making it suitable for hardware wallets and embedded devices. * let $nonce$ = random(96 bits) * let $ciphertext$ = encrypt($payload$, $secret$, $nonce$) ### Decryption In order to decrypt the payload of a backup, the owner of a certain public key p computes: * let $s_i$ = sha256(sha256("BIPXXX_INDIVIDUAL_SECRET") ‖ sha256("BIPXXX_INDIVIDUAL_SECRET") ‖ $p$) * for each `individual_secret_i` generate `reconstructed_secret_i` = `individual_secret_i` ⊕ `si` * for each `reconstructed_secret_i` process $payload$ = decrypt($ciphertext$, $secret$, $nonce$) Decryption will succeed if and only if **p** was one of the keys in the descriptor/wallet policy. ### Encoding The encrypted backup must be encoded as follows: `MAGIC` `VERSION` `DERIVATION_PATHS` `INDIVIDUAL_SECRETS` `ENCRYPTION` `ENCRYPTED_PAYLOAD` #### Magic `MAGIC`: 6 bytes which are ASCII/UTF-8 representation of **BIPXXX** (TBD). #### Version `VERSION`: 1 byte unsigned integer representing the format version. The current specification defines version `0x01`. #### Derivation Paths Note: the derivation-path vector should not contain duplicates. Derivation paths are optional; they can be useful to simplify the recovery process if one has used a non-common derivation path to derive his key.[^derivation-optional] [^derivation-optional]: **Why are derivation paths optional?** When standard derivation paths are used, they are easily discoverable, making them straightforward to brute-force. Omitting them enhances privacy by reducing the information shared publicly about the descriptor scheme. `DERIVATION_PATH` follows this format: `COUNT` `CHILD_COUNT` `CHILD` `...` `CHILD` `...` `CHILD_COUNT` `CHILD` `...` `CHILD` `COUNT`: 1-byte unsigned integer (0–255) indicating how many derivation paths are included. `CHILD_COUNT`: 1-byte unsigned integer (1–255) indicating how many children are in the current path. `CHILD`: 4-byte big-endian unsigned integer representing a child index per BIP-32. #### Individual Secrets At least one individual secret must be supplied.[^no-fingerprints] [^no-fingerprints]: **Why no fingerprints in plaintext encoding?** Including fingerprints would leak direct information about the descriptor participants, which compromises privacy. The `INDIVIDUAL_SECRETS` section follows this format: `COUNT` `INDIVIDUAL_SECRET` `INDIVIDUAL_SECRET` `COUNT`: 1-byte unsigned integer (1–255) indicating how many secrets are included. `INDIVIDUAL_SECRET`: 32-byte serialization of the derived individual secret. Note: the individual secrets vector should not contain duplicates. Implementations MAY deduplicate secrets during encoding or parsing. #### Encryption `ENCRYPTION`: 1-byte unsigned integer identifying the encryption algorithm. | Value | Definition | |:-------|:---------------------------------------| | 0x00 | Reserved | | 0x01 | CHACHA20_POLY1305 | #### Payload Size Limits CHACHA20_POLY1305 (per RFC 8439) supports plaintext up to 2^38 - 64 bytes. Implementations MAY impose stricter limits based on platform constraints (e.g., limiting to 2^32 - 1 bytes on 32-bit architectures). Implementations MUST reject empty payloads. #### Ciphertext `CIPHERTEXT` is the encrypted data resulting from encryption of `PAYLOAD` with algorithm defined in `ENCRYPTION` where `PAYLOAD` is encoded following this format: `CONTENT` `PLAINTEXT` #### Integer Encodings All variable-length integers are encoded as [compact size](https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer). #### Content `CONTENT` is a variable length field defining the type of `PLAINTEXT` being encrypted, it follows this format: `TYPE` (`LENGTH`) `DATA` `TYPE`: 1-byte unsigned integer identifying how to interpret `DATA`. | Value | Definition | |:-------|:---------------------------------------| | 0x00 | Reserved | | 0x01 | BIP Number (big-endian uint16) | | 0x02 | Vendor-Specific Opaque Tag | `LENGTH`: variable-length integer representing the length of `DATA` in bytes. For all `TYPE` values except `0x01`, `LENGTH` MUST be present. `DATA`: variable-length field whose encoding depends on `TYPE`. For `TYPE` values defined above: - 0x00: parsers MUST reject the payload. - 0x01: `LENGTH` MUST be omitted and `DATA` is a 2-byte big-endian unsigned integer representing the BIP number that defines it. - 0x02: `DATA` MUST be `LENGTH` bytes of opaque, vendor-specific data. For all `TYPE` values except `0x01`, parsers MUST reject `CONTENT` if `LENGTH` exceeds the remaining payload bytes. Parsers MUST skip unknown `TYPE` values less than `0x80`, by consuming `LENGTH` bytes of `DATA`. For unknown `TYPE` values greater than or equal to `0x80`, parsers MUST stop parsing `CONTENT`.[^type-upgrade] [^type-upgrade]: **Why the 0x80 threshold?** The `TYPE >= 0x80` rule means we're not stuck with the current TLV encoding. It has a nice upgrade property: you can still encode backward compatible stuff at the start. #### Encrypted Payload `ENCRYPTED_PAYLOAD` follows this format: `NONCE` `LENGTH` `CIPHERTEXT` `NONCE`: 12-byte (96-bit) nonce. `LENGTH`: variable-length integer representing ciphertext length. `CIPHERTEXT`: variable-length ciphertext. Note: `CIPHERTEXT` is followed by the end of the `ENCRYPTED_PAYLOAD` section. Compliant parsers MUST stop reading after consuming `LENGTH` bytes of ciphertext; additional trailing bytes are reserved for vendor-specific extensions and MUST be ignored. ### Text Representation Implementations SHOULD encode and decode the backup using Base64 (RFC 4648).[^psbt-base64] [^psbt-base64]: **Why Base64?** PSBT (BIP174) is commonly exchanged as a Base64 string, so wallet software likely already supports this representation. ## Rationale See footnotes throughout the specification for design rationale. ### Future Extensions The version field enables possible future enhancements: - Additional encryption algorithms - Support for threshold-based decryption - Hiding number of participants - bech32m export ### Implementation - Rust [implementation](https://github.com/pythcoiner/bitcoin-encrypted-backup) ### Test Vectors [key_types.json](./bip-encrypted-backup/test_vectors/keys_types.json) contains test vectors for key serialisations. [content_type.json](./bip-encrypted-backup/test_vectors/content_type.json) contains test vectors for contents types serialisations. [derivation_path.json](./bip-encrypted-backup/test_vectors/derivation_path.json) contains test vectors for derivation paths serialisations. [individual_secrets.json](./bip-encrypted-backup/test_vectors/individual_secrets.json) contains test vectors for individual secrets serialization. [encryption_secret.json](./bip-encrypted-backup/test_vectors/encryption_secret.json) contains test vectors for generation of encryption secret. [chacha20poly1305_encryption.json](./bip-encrypted-backup/test_vectors/chacha20poly1305_encryption.json) contains test vectors for ciphertexts generated using CHACHA20-POLY1305. [encrypted_backup.json](./bip-encrypted-backup/test_vectors/encrypted_backup.json) contains test vectors for generation of complete encrypted backup. ## Acknowledgements // TBD