ShowSN: multisigbackup.com - Recover your 2-of-3 multisig with only 2 seeds \ stacker news ~bitcoin

pull down to refresh

ShowSN: multisigbackup.com - Recover your 2-of-3 multisig with only 2 seeds

3113 sats \ 5 comments \ @josh 9h 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

view all related items

10 sats \ 0 replies \ @dtonon 9h

This is cool!

6 sats \ 1 reply \ @meduzot 8h

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.

0 sats \ 0 replies \ @josh OP 7h

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.

0 sats \ 0 replies \ @john_doe 3h

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.

0 sats \ 0 replies \ @PoolcleanerSteve 6h

This would totally also work using nostr relays for a similar effect