Can we make 2-of-3 Multisigs a better user experience? \ stacker news ~bitcoin

Can we make 2-of-3 Multisigs a better user experience?

1667 sats \ 23 comments \ @josh 15 Jan bitcoin

In a single sig wallet, it's sufficient simply to know the 12 or 24 word seed phrase to recover the funds. This makes for a really nice user experience, since it's relatively easy to write them down on paper.

I thought that a 2-of-3 multisig was similarly simple, but it turns out that's not the case. Intuitively, as a user, I should only need 2 of the 3 seed phrases to recover any funds, but in reality, at least on Blue Wallet, you also need a "backup coordination file," which consists of all 3 public keys, the derivation path, and the script format. Without it, your funds are lost if you lose one of the 3 seeds.

This isn't a great user experience, especially if you're trying to explain a multisig vault to one of your grandparents. Writing seed phrases down on paper is easy for most people to understand, but having to download a bespoke file and securely save it on a thumbdrive makes everything more complicated, and frankly unintuitive. This inevitably scares people off, I fear, from what is otherwise a great way to make people more comfortable with cold storage.

Keeping the backup file on a third party provider, like Unchained, isn't really a solution, because at the end of the day, Unchained still recommends that you backup the data yourself, which is confusing and somewhat cumbersome.

The only long-term robust solution I think is for the backup file to be stored onchain, ideally in an encrypted fashion such that you only need 2 of the 3 private keys to recover the data. This could be done relatively cheaply in witness data, like a taproot inscription, and it would mean that the average user only ever needs to worry about maintaining access to 2 of the 3 seeds. In the event the multisig vault needs to be recovered, the user only needs to provide 2 seeds, and perhaps a date range of when the vault was created, and software can scan the relevant witness data and recover the file.

Do you think a scheme like this could work? Curious if others find this to be a relevant problem.

view all related items

44 sats \ 1 reply \ @BTCExecutor 15 Jan

Yes, this is a very relevant problem. Especially for inheritance.

0 sats \ 0 replies \ @030a29f333 16 Jan

Have you checked out Nunchuk? Don't use their inheritance program myself but it looks pretty interesting. Need more stuff like this to be accessible to people.

https://nunchuk.io/inheritance

13 sats \ 0 replies \ @OriginalSize 15 Jan

None of these files are very big so I think the backup coordination file should be saved with every seed. Since you need a redeem script plus signatures to spend the coin, I can't imagine they'd recommend anything less. If you're setting up multisig, you definitely want to test and know these details before funding. I agree it's complicated but if you're storing that much it's well worth it to understand.

10 sats \ 0 replies \ @lunanto 16 Jan

User experience is one of the big challenges of the Bitcoin community mostly a decade ago when you had to be tech savvy to fully understand and use the protocol, till today most features of the said protocol are still hard to circumnavigate

4 sats \ 9 replies \ @BlueSlime 16 Jan

You don't really need to store the derivation path or the script if both follow a well known convention.

You also don't need to remember or inscribe the pubkeys if you do a multisig in the output script. Segwit is optional.

100 sats \ 8 replies \ @josh OP 16 Jan

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.

0 sats \ 0 replies \ @BlueSlime 16 Jan

I am not familiar with the coinbase wallet. Do they allow sending coins to a legacy address?

A multisig output script encoded in base58chk is essentially the address.

0 sats \ 6 replies \ @supertestnet 16 Jan

"move to X then Y" doesn't sound like a dealbreaker for any reasonable person

Is your grandmother unreasonable?

If so, consider talking some sense into her

0 sats \ 5 replies \ @josh OP 16 Jan

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.

0 sats \ 4 replies \ @supertestnet 16 Jan

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.

And "move to X then Y" is not sufficiently magical and outstanding in your opinion?

Things might improve a bit if coinbase supported "bare" multisig addresses

That would eliminate the middle step, though I still maintain that if your grandma is "scared" of a middle step then she is not being reasonable. Consider calmly and rationally explaining to her why the middle step is there ("coinbase doesn't support this address type" -- see? it takes 6 words) rather than acting as if she is incapable of doing anything other than a one click experience, or incapable of overcoming irrational fears

The burden is on us to create the most beautiful, simplistic, and dare I say magical user experience that could possibly exist

No, that is an unnecessary and overburdensome task. No one needs an experience that perfect because good enough is good enough, and since no one needs that perfect experience, no one needs to build it.

0 sats \ 3 replies \ @josh OP 16 Jan

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.

0 sats \ 2 replies \ @supertestnet 16 Jan

Who is going to tell her to do step 1? That person can also tell her to do this alternative process:

Step 1) Write down 3 seed phrases Step 2) Create bare multisig address Step 3) Move funds from Coinbase to site that supports bare multisig Step 4) Move funds to bare multisig address

Anything more complicated than that makes it scary

It is an irrational fear and you can help any first time user overcome it easily

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

There is no service anywhere that does not require human onboarding. They all require human onboarding. Literally, every single one, there are no exceptions. That one you're thinking of that might be an exception? Yeah, that one requires human onboarding too.

0 sats \ 1 reply \ @josh OP 16 Jan

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?

view replies

0 sats \ 0 replies \ @supertestnet 16 Jan

it would mean that the average user only ever needs to worry about maintaining access to 2 of the 3 seeds

Don't forget, he also needs access to the witness data

don't expect others to store that for you

0 sats \ 4 replies \ @xz 16 Jan

The only long-term robust solution I think is for the backup file to be stored onchain

I don't see why it would be beneficial. That's not to say it couldn't work, just think it doesn't gel well personally. Could you say more about it? Not sure I follow.

I think this is more to do with mindset and usage. If you think about the last fifty or so years we've gone from completely analogue to almost the opposite. Ease-of-use is important but it's dangerous to use ones that are easily used.

Just as in the analogue world we safely guard property with keys, physical storage, passwords, cameras and security personnel, we need to re-learn that. That would need reassessing trust in protocols and standards to find which are the best fits for our individual needs.

I feel multisig works well when I've tested it. What to do with 36 words? I don't think that's a massive difference from 12. But I take your point, ideally we'd like them memorized. I think there's a lot we can do there, maybe additionally to some of things you propose. Just think many choices are better fit for all.

0 sats \ 3 replies \ @josh OP 16 Jan

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.

6 sats \ 2 replies \ @xz 16 Jan

I think I understand your point more that I did before now.

I can see why what you suggest would be advantageous as a standard, and minimize memorizing superfluous information (if that's possible to do.)

Somehow, even though it's probably a very secure and efficient way to deal with the problem, I feel relying on an internet connection to scan the blockchain to find the pub keys, feels like putting my trust in something I don't have full control over.

Or would it be possible to retrieve running a full-node?

0 sats \ 1 reply \ @josh OP 16 Jan

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.

6 sats \ 0 replies \ @xz 16 Jan

I mean, to an extent this is stenography on the blockchain, which I've always thought since inscription were a thing, as the most valid use case.

Sounds good. These things need to get mapped out, explained visually for people to start running with them. I'm still catching up. There's just so much to get comfortable with.

Originally, my point is that stenography is extremely useful in the physical space.. we just need to get more used to using it for security's sake.

0 sats \ 2 replies \ @gbks 16 Jan

The info in the coordination file is not really that sensitive, so you could just offer a print option, or a template to fill in relevant info. We have print templates for recovery phrases here, and could easily add ones for multi-sigs.

0 sats \ 1 reply \ @Bitcoiner1 16 Jan

I just saw your templates and I noticed that you are giving the option to write the seed and the passphrase in the same paper.

Is it a safe practice to do so?

IMO the passphrase have to be safe in other place, far away from the seed.

0 sats \ 0 replies \ @gbks 16 Jan

Thanks for bringing that up. There is a separate template in the same Figma file just for the passphrase further on the right. I don't think that's pushed to the public Figma community file yet, I'll take a look at that tomorrow.