Multisig to Musig2 Migration Guide? \ stacker news ~bitcoin

1858 sats \ 9 comments \ @zapomatic 16 Mar bitcoin

Has anyone been able to migrate a personal m/n multisig offline storage to a taproot MuSig2 storage?

I know that wallet integrations are waiting for MuSig2-PSBT but isn't that just a user experience issue for ease of use?

For the case of a single person creating and managing multiple keys (say a 3/5) for the purpose of legacy management and distribution to family and friends, the initial setup can handle multiple rounds of communication and trust. Is this doable today? If so, it would be valuable to have a detailed guide that could be performed on testnet.

view all related items

1305 sats \ 6 replies \ @oomahq 16 Mar

The time it's taking to see m of n Taproot multisig support integrated in mainstream wallets is something that irks me too, but I've recently learned that MuSig2 is simply not the tool for the job.

Apparently in Taproot there are 2 kinds of multisig schemes: aggregate signatures and threshold signatures. Aggregate signatures look like regular single-sig signatures but are always n of n. MuSig2 is a protocol that co-signing parties can follow to produce this kind of signatures, but from the MuSig2 draft you linked:

(MuSig2 is a n-of-n multi-signature scheme and not a t-of-n threshold-signature scheme.)

Enter threshold signatures. These are the m of n multi signatures we are all familiar with. My understanding is that Taproot threshold signatures will be done with FROST, but apparently it's not yet standardized or even proved cryptographically safe.

Worth commenting that I'm not sure if Taproot threshold signatures will have a lower onchain footprint, like Taproot aggregate signatures do (I can't read the FROST paper, to be honest).

Edit: happy to be corrected/provided with more information about this topic.

1292 sats \ 5 replies \ @supertestnet 16 Mar

Worth commenting that I'm not sure if Taproot threshold signatures will have a lower onchain footprint, like Taproot aggregate signatures do (I can't read the FROST paper, to be honest).

They do have a lower footprint. Frost signatures are the same size as musig2 signatures, which are themselves the same size as "regular" schnorr signatures. That is, they are all 64 bytes.

One of the difficulties with using frost is that it doesn't support "bringing your own key." If 3 people want to generate a 2 of 3 "frost multisig" together, they cannot each independently generate a keypair and then "combine" their pubkeys together. They have to come together to generate a keypair together in a kind of "key generation ceremony." The ceremony involves doing some math that allows every keyholder to ensure everyone followed the protocol properly so that they all know for sure they'll be able to sign later.

Not only is frost not standardized yet, there is also not yet any standardized way to do the key generation ceremony. And if companies like Unchained and Hodlhodl want to support this new form of multisig, some of them will probably have to change how they do business. Any of them that ask their users to provide 2 keys and let the company provide the third can't really do that anymore. They'll have to participate in a key generation ceremony that involves interacting with both users to generate a key and do the aforementioned math to ensure it's safe.

It's all quite involved and I don't expect much fruit to come out of it anytime soon. "Regular" multisig works well so I don't see much motivation to code up the fancier version that taproot enabled. Consequently the number of people working on it is small, and progress is slow.

10 sats \ 0 replies \ @_b_o_n_e_s_ 18 Mar

thank you for explaining sir.

0 sats \ 3 replies \ @oomahq 16 Mar

That was very informative, thank you ST.

If FROST has that big downside, do you know if there is any particular reason we don't see wallet support anywhere for regular m of n in Taproot with the usual OP_CHECKMULTISIG script sequence?

Even that traditional "wasteful" version of threshold multisig (in comparison to an aggregate signature) would save quite some vBytes compared to the ECDSA signatures used in P2SH and P2WSH multisig, no?

168 sats \ 2 replies \ @supertestnet 16 Mar freebie

You are correct that taproot's "regular" multisig is more efficient than ecdsa multisig. This is mostly because schnorr signatures are usually about 8 bytes smaller than ecdsa signatures, and if you have (for example) 15 signatures, that adds up to about 120 bytes saved.

I don't know why more wallets aren't adding "regular multisig" (with taproot) as a feature. But if you want to play around with it, check out bitpac.org, which is one of my demos. You can use it to create a taproot multisig (not frost) using nostr keys and then spend it by having keyholders "vote" on what to do with the money. It wasn't hard for me to build so I don't know what other wallet developers are waiting for. But everyone's got stuff to work on, maybe it's lack of demand.

0 sats \ 0 replies \ @Scoresby 17 Mar

Do you know what I'm doing wrong here? I can't seem to make a taproot multisig with commands in core's terminal.

0 sats \ 0 replies \ @oomahq 16 Mar

I wish Craig Raw was here and I could tag him :(

110 sats \ 0 replies \ @Scoresby 16 Mar

I was thinking the same thing. Tried to figure it out on my own, but got stuck.

Then I heard that it is possible that a threshold musig2 wallet in its current state requires some interactivity between signers, so that you would need each key to sign the psbt twice.

I'm also a little fuzzy on this, but I think what it means is that there's a bit of work to be done before we can all convert our multisigs to fancy taproot addresses that look just like any other singlesig.

0 sats \ 0 replies \ @0245c6246c 16 Mar freebie

Pregúntasle a @btcandres. El sabe la respuesta.