From what I understand, Schnorr signatures will allow n-of-n multisignature transactions, however m-of-n isn't possible using the key path alone.
That's not quite accurate. Schnorr signatures, as described in BIP340, are purely 1-key-1-signature.
Alternative schemes, which are compatible with BIP340 validation, exist.
- One is MuSig (1,2,DN) which permit n-of-n signatures, verifiable against a single aggregated public key, which represents the agreement of all consituent keys.
- Another one is FROST, which permits arbitrary k-of-m thresholds, similarly verifiable against a single key. It needs an interactive setup however, where the (potential) cosigners need to cooperate (while having access to their private keys) to construct the aggregate key, so it isn't compatible with e.g. having a multisig wallet whose addresses are derived on the fly using BIP32 keys. It also lacks accountability: you cannot after the fact tell which parties signed.
Suppose we need a 2-of-3 scheme. As far as I can tell, we can use a 3-of-3 scheme and just give each party two of the three keys in such a way that any two parties when combined will have all three keys. (One party gets keys A and B, another one gets B and C and the last one gets A and C.)
Would this method work? Is there some problem I don't see?
Yes, this is possible. If you generate all 3 keys on one machine, you get a somewhat uninteresting security model, as you apparently all 3 have one machine you trust to do key generation honestly. You could probably equally agree to let that machine do the signing.
A variant of what you suggest is perhaps more interesting: each of the 3 parties generates 1 key, and gives the private key to their right hand neighbor. Now any subset of 2 of them has all 3 keys.
More schemes like this exist. The simplest one is an unaccountable interactive-setup 1-of-n scheme: one party generates a fresh key, and gives it to all others. Done.
I don't recommend using this though, while deceptively simple, the devil is in the details to make such schemes secure, and you're probably better off using FROST or something similar instead, as it's well analyzed.
If you want accountability, or non-interactive setup (the ability to generate addresses without having the cosigner keys online), none of these approaches are sufficient, and you should probably use (in the context of BIP341) a tree where every leaf is a 2-of-2 musig aggregate of 2-of-3 subsets.
