Weighted Asymmetric Multi-Signature Wallets

Creating weighted asymmetric multi-sig wallets comes with tons of advantages. These wallets treat keys differently instead of giving them all equal weight. Take a 3-of-5 wallet for instance; right now, all 5 keys are seen as the same. That works for a lot of situations, but it's not ideal for everything. Picture a company that has a multi-sig wallet where keys are distributed across its financial management team. The CFO's key shouldn't hold the same weight as that of a junior manager. Or think about a basic multi-sig wallet where you hand out backup keys to family members. You probably wouldn’t want their key to carry the same weight as yours. Even though you could technically set this up now by giving more keys to higher-ups (like the CFO getting two keys while others get just one), there's no proper system for that in Bitcoin yet. This basically shifts the multi-sig m-of-n keys to m-of-n 'units', so you need a certain amount of signature units to approve a transaction, and each key has a defined unit value.

This is not entirely accurate. Liana wallet which has built-in support for Miniscriptallows 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.

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.

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.

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.

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.

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)

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. 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.

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: This is a 3 of 5 multisig where the CFO pubkey and signature is mandatory and has a higher weight.