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.

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.

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.

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.

I wasn't familiar with opreturnbot.com before - thanks for sharing! Looking at it, I'd say the general idea is the same, except the message is stored in a taproot inscription rather than in a OP_RETURN output, so you're not limited to 80 characters.

Two other minor differences:

Hope this helps!

Take a look at https://offline.cash. I haven't used them, but from my understanding, they ship multisig notes where one key is encrypted by the manufacturer and one key is provided by the first holder, who loads the funds. To claim the funds, you have to cut the note to access the manufacturer key and then ping their server to decrypt it.

Can't attest to the security of this setup but might be worth looking into.

A good consumer product does not require human onboarding.

The consumer downloads the app, and the rest should be seamless and intuitive to follow, walking the user through the onboarding process step by step in a way that does not require outside human intervention.

You’re correct that this application could tell the user to send funds to an address, and then once received, to transfer those funds to a multisig output. But that’s not intuitively how a vault should work. It shouldn’t require a special application to move funds into, with an intermediate location before they can be moved.

The consumer is taught that funds are stored at addresses. This is analogous to bank accounts and easy for the consumer to pick up. Why break that analogy if we don’t need to?

I disagree that we should be ok with a user experience that requires human onboarding.

Sure, I can explain to my grandmother how to move funds to a multisig output. My grandmother trusts me, and I can explain things simply enough that she can mostly follow along.

But not everyone has that. We should be making consumer experiences that are seamless to use, and seamless to understand. Bitcoin self-custody should be self-serve, and it should be designed in a way that is simple to understand.

Step 1) Write down 3 seed phrases Step 2) Create an address to receive funds Step 3) Move funds from Coinbase to that vault’s address

Anything more complicated than that makes it scary for a first time user to follow, unless they have a person they know holding their hand.

To be clear, this is not a question of reasonableness or security. You can set up a perfectly secure multisig wallet with the technology we have today.

This is purely about the user experience, and making it intuitive for a new person to understand. Bitcoin is complicated enough as it is, but it can be explained in extremely simple terms:

Your funds are stored at an address, which is a location on the Internet no different than the address that identifies the location of your house.

Your funds at the address are controlled by keys. And a key is represented by 12 words (or 24 if you choose).

In a single sig, you need only one key to unlock and move funds, but in a multisig, you can set it up so that you need 2 of 3 different keys. This provides redundancy in case you lose one.

That’s it. And the user experience should match that, at least for the average consumer.

Cold storage is terrifying for most people, but it doesn’t need to be. And there’s no reason why people should be introduced to Bitcoin through exchanges, and only later taught to move the funds to cold storage.

You don’t truly learn about Bitcoin until you take it into your possession, and we should develop an outstanding user experience that matches that behavior.

Again, this isn’t about what’s reasonable to ask someone to do. The burden is on us to create the most beautiful, simplistic, and dare I say magical user experience that could possibly exist. Technology should be like magic, and Bitcoin should be no different.

Precisely, the idea is that it’s possible to recover by running a full node. You’d simply need to scan the relevant witness data until you find the data you’re looking for.

If the user writes down the current blockheight along with the 12 word seeds, this can be done quite quickly, because we’d only need to scan blocks after that point.

True. But the user experience for moving funds directly to a multisig in an output script is quite poor today. The entire industry is setup to move funds to addresses.

The user experience for my grandmother should be as seamless as possible. If she wants to move funds to and from Coinbase, she should be able to do that directly. To use a multisig output, she would need to type in an address on Coinbase, moving funds to a personal single sig, then make a transaction moving funds to a multisig output script.

The ideal multisig setup would require nothing more than writing down 36 words on three slips of paper of 12, and securing them in three different locations. Setting up a wallet to move the funds should then require exactly 24 words (2 of the slips of paper).

The problem is that today, a backup configuration file containing the 3 public keys must also be stored. Without it, you need all 3 slips of paper to set up a new wallet and move the funds.

If we want a user to be able to recover funds with only 2 seed phrases, the backup file containing the 3 public keys must be stored in a way that anyone on the Internet can access it.

Imagine a multisig mobile app where the user only needs to input two seed phrases, and the wallet is completely set up for the user, without them needing to import a backup file.

To do this, the three public keys in the backup file must be stored on the Bitcoin blockchain, to guarantee that they can be accessed by wallet software in the future. To provide privacy, this data can be encrypted such that you need 2 of the seed phrases to decrypt it. The software then runs a simple scan over the relevant data on chain until it finds the configuration file that the two seed phrases can decrypt.