From: Christopher Allen <ChristopherA@lifewithalacrity.com>
To: pyth <pyth@pythcoiner.dev>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] [BIP Draft] Wallet Backup Metadata Format
Date: Fri, 27 Mar 2026 12:04:55 -0700 [thread overview]
Message-ID: <CACrqygAGiX9R3Fw+b7cD81_6Cov=j2CCPZbKGFBcywv9xs4SbA@mail.gmail.com> (raw)
In-Reply-To: <28c7570dc6f833551780c7ea0773ad33cd5a966d.camel@pythcoiner.dev>
[-- Attachment #1: Type: text/plain, Size: 6170 bytes --]
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
<https://developer.blockchaincommons.com/animated-qrs/> and SSKR
<https://developer.blockchaincommons.com/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
<https://developer.blockchaincommons.com/ur/>, which have been implemented
by more than a dozen companies
<https://developer.blockchaincommons.com/ur/implementations/>, 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 <https://foundation.xyz/>. We most recently worked with them to
support QuantumLink <https://community.foundation.xyz/t/quantumlink/291>, a
Post-Quantum-Cryptopgraphy (PQC) method of Bluetooth communication that’s
in their new Passport Prime device
<https://foundation.xyz/buy-passport-prime/>, 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
On Fri, Mar 27, 2026 at 4:38 AM pyth <pyth@pythcoiner.dev> wrote:
> 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
>
> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/28c7570dc6f833551780c7ea0773ad33cd5a966d.camel%40pythcoiner.dev
> .
>
--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACrqygAGiX9R3Fw%2Bb7cD81_6Cov%3Dj2CCPZbKGFBcywv9xs4SbA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 10242 bytes --]
prev parent reply other threads:[~2026-03-27 19:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 10:41 pyth
2026-03-27 19:04 ` Christopher Allen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACrqygAGiX9R3Fw+b7cD81_6Cov=j2CCPZbKGFBcywv9xs4SbA@mail.gmail.com' \
--to=christophera@lifewithalacrity.com \
--cc=bitcoindev@googlegroups.com \
--cc=pyth@pythcoiner.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox