Asymmetric Weighted Multi-Signature Wallets

[u8A8]

There are a lot of benefits in creating Asymmetric weighted multi-sig wallets. These are wallets where not all keys are equal.

Currently, in a 3-of-5 wallet, all 5 keys are treated as equals. While this may be fine for a majority of uses, it might not be best for all.

Imagine a system where a corporation has a multi-sig wallet with keys held throughout the financial management structure, the CFO's key should not be weighted the same as a manager's key.

Or a traditional multi-sig wallet where you give contingency key(s) to family. You may not want their key to be worth as much as one of your own.

While these systems are *technically* possible right now by just giving higher-weighted entities more keys (e.g. the CFO gets two keys, everyone else gets one), there is no real system for this in Bitcoin.

This essentially moves multi-sig m-of-n keys to be m-of-n 'units', where a threshold of signature units must be met, and each key is worth a set number of units.

[satscraper]

~
 there is no real system for this in Bitcoin.

This is not entirely accurate.

Liana wallet ^{which has built-in support for Miniscript}allows users to create the wide range of advanced multisig schemes including the one you mentioned. With Liana, you can define flexible spending conditions and set up multiple backup keys, distributing them however you like.

[NotATether]

But how are you going to implement this with conventional threshold signature algorithsm?

I don't know of any multisig algorithms that work in fractions, they all work in terms of singular units.

I think the best way to go about this is to "emulate" fractions using a numerator (the number of keys YOU are assigned) and a denominator (total number of keys issued by the system).

It can be done right now, with no code changes required.

[ABCbits]

But how are you going to implement this with conventional threshold signature algorithsm?
--snip--

It's ugly approach, but you could create Taproot address where it's tapscript contain all possible spending condition based on weight/rule chosen by the user. I specifically mentioned Taproot, since Taproot doesn't reveal whole path/spending condition which is needed to maintain some privacy and reduce TX size.

[1440000bytes]

Currently, in a 3-of-5 wallet, all 5 keys are treated as equals. While this may be fine for a majority of uses, it might not be best for all.

Lets assume there are 5 users (alice, bob, carol, david and eva). You can create a 3-of-5 multisig using miniscript in which alice and bob should be a part of 3 users that sign the spending transaction. The third signer could be anyone among the remaining.

It was possible to test miniscript and visually see different policies using bdk playground but it doesn't exist anymore.

[Ambatman]

I would come from an angle that isn't explicitly on it's complexity or technicality.
Multisig is usually done for security and sharing responsibility
Using weight same as concentrating power in fewer hands
Which can potentially increase the risk of targeted attacks on high value key holders.
Say compromising the CFO key could  weaken the wallet's security compared to a standard multisig setup.

Take using a 2 of 3 multisig and one with the highest weight becomes inactive.
It means the funds are lost forever.

[NotATether]

Lets assume there are 5 users (alice, bob, carol, david and eva). You can create a 3-of-5 multisig using miniscript in which alice and bob should be a part of 3 users that sign the spending transaction. The third signer could be anyone among the remaining.

It was possible to test miniscript and visually see different policies using bdk playground but it doesn't exist anymore.

Damn, I don't really know miniscript that much but I think I should revive this. Maybe I'll put it on my old site (notatether.com)

[Obim34]

Take using a 2 of 3 multisig and one with the highest weight becomes inactive.
It means the funds are lost forever.

In this case you can't use 2 of 3. If the wallets used has customizable m of n then it can be adjusted until balance. According to how OP explained using a 3 of 5 is best, the higher weights gets double the keys.

Which can potentially increase the risk of targeted attacks on high value key holders.

If the multisig is set up by the CFO, to keep informations discrete he doesn't need to mention the part where he holds the bigger weight.

[pooya87]

Currently, in a 3-of-5 wallet, all 5 keys are treated as equals. While this may be fine for a majority of uses, it might not be best for all.

Imagine a system where a corporation has a multi-sig wallet with keys held throughout the financial management structure, the CFO's key should not be weighted the same as a manager's key.

While these systems are *technically* possible right now by just giving higher-weighted entities more keys (e.g. the CFO gets two keys, everyone else gets one), there is no real system for this in Bitcoin.

You don't need to give them more keys, you just have to modify the smart contract aka the script that is used to lock those coins up. For example in a 3 of 5 setup you want the CFO's key to have a "higher weight" then do something like this:

Code:

<CFO pubkey> OP_CHECKSIGVERIFY
OP_2 <pubkey 2> <pubkey 3> <pubkey 4> <pubkey 5> OP_4 OP_CHECKMULTISIG

This is a 3 of 5 multisig where the CFO pubkey and signature is mandatory and has a higher weight.