0 sats \ 4 replies \ @xz 16 Jan \ on: Can we make 2-of-3 Multisigs a better user experience? bitcoin
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.
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.
reply
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?
reply
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.
reply
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.
reply