Great to see musig2 coming into production ready tools. I loved the invisible cosigner idea there. I wonder if one could have more than one invisible cosigner? This will reduce risk of the one invisible cosigner being hacked. Then you could have two keys that you control via a ledger and electrum to secure your coins.
Am sure the above is a shitty scheme. So much to think through to be sure schemes are secure.
Can TLA+ help to figure out vulnerabilities in schemes?
Yep, you can definitely have multiple invisible cosigners!
For example, one could be self-hosted if you have an always-online machine.
Of course, since MuSig2 is an AND of all the cosigners, having more increases the chance of at least one of them failing, so in practice I expect a single cosigner managed by a professional entity to be a very popular option. In that direction, an interesting thing to explore is: how private can this be? It should be possible to combine MuSig2 with Schnorr blind signing, so that the cosigner doesn't necessarily have to learn about your transactions, while still being able to check predicates in them (this paper does it for single-sig: https://eprint.iacr.org/2022/1676 but smarter people tell me it should be generalizable for MuSig/FROST).
Good point about the AND. So maybe only one is enough.
The problem with new crypto, is that well, it is new 😉
I wonder if instead of a centralised large entity signing and thus requiring privacy, if we can let people run such services anywhere they want. What we want is plausible deniability of such a service existing for the user. IDK if such fantastical setups are even possible.
Thanks for sharing that there is some work being done on blinded Schnorr sigs. It could get interesting as things mature. Forza! Avanti!
There are two failure modes for the cosigner:
- it stops signing. Then your primary spending path is frozen, but if you're in a liana-like setup, that's no big deal.
- it signs things it shouldn't sign. Then you basically fall back to the security model you'd have without the cosigner - for example a single-sig with you hardware wallet.
Unlike on-chain usage of moon math like ZKPs (roll ups, bridges, etc.), where failure is catastrophic, here you'd just fallback to a weaker security model.
Also, I think the fact that all the complexity can be handled in the software wallets (without needing any new features from hardware signers) makes it a lot more likely to happen. It's not easy to build, but once built, it's basically a library that can be used as a black box by software wallets. Bullish!
Liana like setups are really cool, but they can be hard to grok for normies.
If cosigner stops signing, doesn't a frost based setup look better then?
I'm not sure. I think the fact that the recovery paths can be a completely different set of keys (and spending conditions) is very useful in practice, and you can't do it with FROST.
Also, I don't think moving to MuSig2/FROST for deep cold storage is that compelling, as the added interactivity (multiple rounds) is likely a dealbreaker.
Normies will be fine with 1 cold key + 1 (invisible) cosigner, plus recovery paths to protect from loss. The cherry on top would be OP_VAULT- (or OP_CHECKCONTRACTVERIFY-)based recovery paths, as that would almost entirely remove the learning curve about 'recovery paths' and refreshing timelocks, which is what confuses normies using liana.
But maybe we figure how to get a good enough approximation with cosigners...
