BIP Draft: Standard Encrypted Wallet Payload

[KeysSoze]

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]

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]

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

• BIP391 Binary Output Descriptors
• BIP138: Compact Encryption Scheme for Non-seed Wallet Data
• BIP139: Wallet Metadata Backup Format

which might interest you.

[KeysSoze]

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.

[murchandamus]

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]

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

[KeysSoze]

Hi @murchandamus,

Thanks again for reviewing this.

To date, no Bitcoin project has implemented this scheme. Because BIP-138 and BIP-139 overlap significantly with large portions of this proposal, we have intentionally slowed our updates while we observe how those developments unfold.

However, in our completely biased opinion, this proposal offers distinct advantages over alternative approaches. As mentioned above, utilising the IETF standard CBOR yields a format substantially more compact than JSON. Furthermore, its modular design allows us to leverage existing IETF specifications (such as COSE for encryption), ensuring we don't reinvent the wheel while keeping the framework highly future-proof

[murchandamus]

You’re welcome, @KeysSoze. It seems distinct enough to me, that both could move forward. Although it would of course be better if the ecosystem settled on one standard, that is not usually how these things play out.

[murchandamus]

Hey @KeysSoze, this still has unaddressed review. Please process the review comments and mark them as resolved as you get through them.