paritytech
support MuSig with subkey
Currently, the multisig pallet must be used for multisig use cases. That requires each signer to at least have the existential deposit on their account and also comes with higher total fees than sending the final extrinsic directly.
We'd like to pool funds by individuals with very little capital and let them participate in our ecosystem with a joint account.
As Schnorrkel supports MuSig, I was wondering if subkey could support that as a golden model for further UI integrations downstream
I dislike my musig implementation in schnorrkel, so please do not use what is there now, at least no publicly. I wrote it before we proved security for my two-round multi-signature, so I wrote it for the three-round multi-signature, but provided an optional two-round multi-signature flavor. A two-round only multi-signature should be cleaner & simpler.
It'll need threshold multi-signatures too, for which others have written nice DKGs which we can rip off. We'll intentionally never support the FRO par of FROST though, because that shit is just a stupidly dangerous foot gun. We'll see secret keys being compromised plenty by miss-used FROST deployments.
At some point @Lederstrumpf should rewrite the schnorrkel in the way I'd like to see. I'm doing a better flavor in the ring_vrf crate too, but not yet pushed, but surely before anything happens on schnorrkel itself. I hope the ring_vrf flavor gives an even nicer code path for schnorrkel too.
Also..
Are you asking about account keys or session keys? Account keys should really become a parity signer and polkadot.js feature, in which polkadot.js plays the coordinator role, which'll require some heavier backend on polkadot.js. Session keys are much more complex, but the ring_vrf crate should wind up doing vrf multi-sigs eventually.
We need "native" threshold multisig for account keys, not session keys.
We wouldn't mind to do coordination of signature aggregation ourselves as long as we have some way to generate a valid sr25515 signature.
If polkadot.js does this anytime soon, all the better
I posted this on the relevant Schnorrkel issue, yet you may also find it useful: https://github.com/w3f/schnorrkel/issues/11#issuecomment-1382598449
You'd still need to apply it to Substrate (let me know if you do!), and it isn't exactly coded around Substrate key types, but it's available now.
