[BIP Draft] Wallet Backup Metadata Format

[pyth]

Hi all,
While implementing the backup format for Liana last year, I ran into
the lack of any real specification for a proper wallet backup format.

Because of that, I wrote a BIP draft for a structured wallet backup
format.

Several wallet implementations have already signaled interest in
something like this.

Draft PR: https://github.com/bitcoin/bips/pull/2130

Feedback welcome on the structure, fields, or anything else.

Thanks,
Pyth

[Christopher Allen]

When Zcash needed to deprecate its old bitcoind-based wallet, the Zcash ecosystem commissioned us to create tools to parse all of (old) bitcoind’s structures. This enabled all wallets in the ecosystem to recover all private data (Zcash has more data than Bitcoin). The Zcash community also wanted to enable all wallets to have some common ability to export all fundamental wallet data to preserve choice and prevent vendor lock-in.

I have an article on the topic, “Interop: What Is It Good For?” that details the project:

https://www.blockchaincommons.com/musings/musings-interop/

In it I say:

> This isn’t Blockchain Commons’ first rodeo. Creating interoperability has been Blockchain Commons’ goal since the start, and we’ve done most of our interop work to date with Bitcoin.

Our two biggest successes for Bitcoin have been Animated QRs and SSKR. Animated QRs are a standardized way to move large files across airgaps. That’s the exact sort of intercommunication that has always required interoperability. SSKR is a standardized way to shard a secret, currently focused on Shamir’s Secret Sharing. Because it isn’t just about intercommunication, getting a variety of companies to use it was a bigger victory, because it ensures those secrets will remain accessible and resilient into the far future. Both technologies are integrated with our Uniform Resources, which have been implemented by more than a dozen companies, offering true interoperability.

But these successes have unfortunately been piecemeal. There’s just one company that I’m aware of that’s adopted a pretty wide swath of Blockchain Commons’ Gordian specifications, and that’s our long-time sponsor, Foundation Devices. We most recently worked with them to support QuantumLink, a Post-Quantum-Cryptopgraphy (PQC) method of Bluetooth communication that’s in their new Passport Prime device, but they’ve also implemented URs, Animated QRs, SSKR, and other Blockchain Commons interop specs. As a result, they’ve got well-studied, mature specifications that they didn’t roll themselves and that should be resilient and reliable far into the future. I think that adding in a variety of linked interop specs like this has a multiplicative effect.

I’d love to see more of this in the Bitcoin community, but a lot of people are resistant.

...

The primary reason that we see people fight interoperability is market dominance. The Bitcoin ecosystem has grown large enough that some of the bigger players have stepped back from interoperability.

...

But I think the recent release of Ledger Recover was even more of a tragedy. Here they were offering a big innovation: a way to recover seeds by splitting them up and distributing them off device, similar to Blockchain Commons’ own Collaborative Seed Recovery (CSR). But by keeping their protocol for distributing and recovering seed shares non-interoperable, they kept anyone else from offering seed vaults of their own, instead locking their users into their choices—which were very unpopular due to privacy-busting requirements for KYC information.

The exact opposite approach is taken by another of Blockchain Commons’ long-time developer partners, Craig Raw of the Sparrow wallet. He’s working hard to make Sparrow compatible with everything out there, but the difficulty he faces underlines the issues with the semi-interoperable state of bitcoin. He has to make NASCAR-like lists of otherwise incompatible products and introduce secret sauce to interoperate with each of them. We’re very luck to have the Sparrow wallet working with all of these different devices, but it’s something that would never happen if there weren’t someone as dedicated as Craig working on the project.

In any case, we have three open source repositories associated with ZeWIF -- in particular, if you are trying to parse old bitcoind, you might find some useful code there. https://github.com/search?q=org%3ABlockchainCommons+zewif&type=repositories

I'd love to see financial support from the Bitcoin community to enable us to work with more wallet vendors and together be able to do better in the Bitcoin ecosystem. But at this point, we can't do it given the current state of financial support in Bitcoin today (slow, insufficient, or partial), thus we cannot proceed at alone this point. 

-- Christopher Allen

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/28c7570dc6f833551780c7ea0773ad33cd5a966d.camel%40pythcoiner.dev.