pull down to refresh

ShowSN: multisigbackup.com - Recover your 2-of-3 multisig with only 2 seeds
3204 sats \ 11 comments \ @josh 21 Nov bitcoin
Hi all! I made a post a few months ago titled “Can we make 2-of-3 multisigs a better user experience?” (#389403). In summary, I found it frustrating and confusing as a user to learn that 2 seed phrases wasn’t actually enough to recover a 2-of-3 multisig. Without the descriptor, containing all three extended public keys, the funds can’t be accessed. This requirement is not intuitive and runs counter to the “2-of-3” moniker, which implies that 2 seed phrases should be enough.
The lack of a standard way to back up a multisig descriptor puts users’ funds at risk and makes inheritance more challenging that it needs to be. Expensive tools like SeedHammer exist to try to solve this problem, by splitting the descriptor into shares and inscribing those shares onto steel, but this isn’t the best user experience, and at $600 a piece, this isn’t practical for most users.
I built this tool as a way for me to easily encrypt and inscribe my 2-of-3 descriptor on Bitcoin, so I can always recover it with 2 seeds. All sensitive data in a k-of-n descriptor (master fingerprints, xpubs) is stripped from the descriptor and encrypted such that it can’t be decrypted without k xpubs.
To recover, the user simply inputs two master fingerprints, which are hashed and used to find the encrypted descriptor onchain. An open source indexer makes this near instantaneous. Once the user has the encrypted descriptor, they use the derivation paths in the descriptor template to derive k xpubs, decrypt the encrypted data, and reassemble the original descriptor.
The cost of using this tool on a 2-of-3 descriptor is the same as inscribing about 0.5kb of data, which is about 400vb or 2000 sats at 5 sats/vb (~$2 at current prices). Even at higher fee rates, I think this is a no-brainer for anyone storing a significant amount in a conventional multisig, especially if you don't want to rely on a third party like Unchained, Casa, or Nunchuk to store your descriptor.
Try it out at multisigbackup.com and let me know what you think! Appreciate any and all feedback.
Source code: https://github.com/joshdoman/multisig-backup https://github.com/joshdoman/multisig-recovery (indexer)
Example inscription: https://mempool.space/tx/af752b0e22506b9a60ac467186e27fa1f41e2d9f833fc3cd148ec9de3a838c2f https://ordinals.com/content/af752b0e22506b9a60ac467186e27fa1f41e2d9f833fc3cd148ec9de3a838c2fi0
write
preview
related posts
10 sats \ 1 reply \ @joko 22 Nov
Very interesting! Does the backup include all 3 possible combinations of fingerprints?
reply
0 sats \ 0 replies \ @josh OP 22 Nov
Yes! Every possible pair of fingerprints is hashed and appended to the encrypted data. That way you can easily find it with any pair of seeds, without exposing the master fingerprints onchain.
reply
10 sats \ 0 replies \ @aS7017ur5 22 Nov
This is great.
reply
10 sats \ 0 replies \ @dtonon 21 Nov
This is cool!
reply
6 sats \ 1 reply \ @meduzot 21 Nov
First of all, kudos for the novel idea to do this because it is a legitimate problem. I'm torn that you're using OP_RETURN because normally I think it should be used very sparingly but this might be a use case that is deserving. However, I feel this doesn't scale and is ultimately the wrong approach.
You mentioned the SeedHammer project but they're actually using the Uniform Resources standard which need not be stamped onto metal. So in a multisig setup where you store each private key (in whatever medium) you should also store the descriptor in UR format to allow for proper recovery (and aide privacy).
I think the bigger issue here is that the backup procedure of wallets should also include the descriptor (and for multisig in UR) in addition to the seed. This seems to be a cultural change though.
reply
0 sats \ 0 replies \ @josh OP 22 Nov
Thanks for the support. I see this first and foremost as a solution to a UX problem. A whole ecosystem already exists guiding users through the process of creating and backing up seeds, either on paper or on metal. Asking an already cautious user to back up additional data offline doesn't make for the best user experience and adds additional risk, where none needs to exist. Why go through the hassle when your descriptor can be inscribed once and forgotten about? A third party provider could even do this behind the scenes during setup, making for a more seamless user experience.
People are rightfully weary of applications that involve inscribing data on Bitcoin, either because they congest the network or because they get priced out when fee rates go up. In this case, the data is directly related to the security of user's funds, and the actual amount of data is small. The cost of inscribing is the same as making ~4 taproot transactions, so if you can afford a multisig, you can probably afford to inscribe your descriptor.
I should clarify that the data is inscribed in a taproot witness, not in a OP_RETURN output. The difference is minor, since I create the reveal transaction with a single OP_RETURN output, which avoids bloating the UTXO set. Meanwhile, we benefit from the witness discount and avoid the 80 byte OP_RETURN limit.
reply
0 sats \ 1 reply \ @john_doe 22 Nov
It may be a silly question, but why not just put the descriptor on a server like Nextcloud and save the seeds as usual? I didn't verify why but with Specter I didn't even use my backup on Nextcloud to recover my setup when I had to. Maybe the order of the keys was not a problem there (can't say for sure as I didn't check). Also on Liana they do the backup of the descriptor for you if you are lazy. For people interested I use Qloud for Nextcloud. It is a little bit slow but useful.
reply
22 sats \ 0 replies \ @josh OP 22 Nov
The goal of this project is to eliminate the need for the average user to do anything beyond backing up their seeds. You can certainly put the descriptor on Nextcloud or a hosted cloud provider, but you're creating unnecessary risk. If the data gets purged, or if you die and your heirs don't know how to access it, your funds could be lost.
A 2-of-3 multisig should be recoverable with only 2 seeds - anything else is an added liability.
reply
0 sats \ 1 reply \ @PoolcleanerSteve 22 Nov
This would totally also work using nostr relays for a similar effect
reply
0 sats \ 0 replies \ @josh OP 22 Nov
Nostr relays can't guarantee data availability, unfortunately. You can broadcast to multiple relays to improve redundancy, but relays can purge data at any time, or go offline completely. Inscribing the data on Bitcoin solves this problem.
reply
4 sats \ 0 replies \ @Satoshi__Nakamoto 22 Nov
It is useful no really tho
reply