1

In a multi-sig wallet, each of the public keys is unique. Is it possible to create weighted multi-sig wallet, such that one private key has more power than the others?

Case 1: typical Example (need 2 of 3 to spend):

2 PubKeyAlice PubKeyBob PubKeyChris 3 CHECKMULTISIG

Case 2: Duplicate public key for weighted signing (need 2 of 4 to spend):

2 PubKeyAlice PubKeyAlice PubKeyBob PubKeyChris 4 CHECKMULTISIG

In this case, Alice could sign on her own (she has 2 of 4), or Bob and Chris can come together to sign.

Case 3: No duplicate public keys, but multiple public keys controlled by one person.

In this case Alice would control two private keys, and then the wallet would look like:

2 PubKeyAliceA PubKeyAliceB PubKeyBob PubKeyChris 4 CHECKMULTISIG

Certainly Case 3 works today. And Case 1 is the basic unweighted implementation.

Does Case 2 work? Or is there some alternative to make Case 2 work? (i.e. a single Private Key holder has more power / shares then others).

Improve this question

1 Answer 1

Reset to default
1

There is no restriction on what the public keys of the multisig are (assuming they are valid public keys as defined by a particular SegWit version). If you want two of the four public keys in a 2-of-4 to be the same there is nothing to stop you with OP_CHECKMULTISIG and the new Taproot multisig opcode OP_CHECKSIGADD.

You can achieve something similar with a script that effectively says "Alice signs OR 2-of-3 signs" without repeating Alice's key in a 2-of-4.

You can also repeat the same public key in threshold key aggregation schemes like FROST assuming you treat the two public keys that are the same as independent public keys for the purposes of nonce generation (Thanks to nickler for confirming).

Improve this answer
2
  • Thank you. Is there a good source for getting started with FROST? I found a paper but seemed rather dense, would be good to see something where its applied or examples of use cases.
    – miketery
    May 21, 2022 at 6:28
  • 1
    @miketery: Still a work in progress PR at this point. Links to various FROST resources are here: btctranscripts.com/sydney-bitcoin-meetup/… The use case is saving block space (only one signature goes onchain when spending from it) and updating the threshold sig arrangement without needing an onchain transaction.
    – Michael Folkson
    May 21, 2022 at 9:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.