Precedence of competing multisig spends

Question

Imagine I want to create a multisig threshold (k-of-n) scheme where a spending transaction with more signatures takes precedence over other spending transactions with less signatures (but in both cases number of signatures is > k). Hence these other spends are invalidated.

For example in a 3-of-9 multisig, a transaction with signatures from 6 keys takes precedence over a transaction with signatures from 3 keys.

I think this can be created used timelocks. Each spending path is encumbered with a timelock such that after some time t only 9-of-9 is valid, after t+1 8-of-9 is also valid, and so on (until 3-of-9 is reached at t+6).

Does this work? Are there better ways to do it?

Answer 1

Your desired setup sounds very similar to a "Degrading Multisig," and is possible with taproot.

In your example, the 9-of-9 spend would be the key-path spend. You would then create spending conditions for each of the other possible combinations with their appropriate timelocks and place them into a Taptree. Any script path where the timelock has expired is available to be used and more script paths (presumably requiring fewer keys to spend) would become available as time passes. It is worth mentioning that security gets worse over time in the scheme you are describing.

You can see an example of a similar setup here: https://github.com/bitcoinops/taproot-workshop/blob/master/3.1-degrading-multisig-case-study.ipynb. In this example, the key-path is meant to be used by keys that can participate in an interactive MuSig session and the script path allows spending with a separate set of backup keys after a timelock has passed. The script path keys are assumed to be in cold storage and thus unable to participate in an interactive protocol.

Answer 2

As Josie says in his answer a degrading/time decay multisig (also discussed here) seems to be the best solution to what you want.

Imagine I want to create a multisig threshold (k-of-n) scheme where a spending transaction with more signatures takes precedence over other spending transactions with less signatures (but in both cases number of signatures is > k). Hence these other spends are invalidated.

In Bitcoin a transaction is either a valid spend or it isn't. You can have competing transactions (e.g that spend the same outputs from another transaction) but ultimately only one of these competing transactions can be confirmed and included in the blockchain. If a competing transaction is broadcast and propagated whilst the original transaction is still unconfirmed this has zero impact on the validity of the original transaction. They are both potential valid spends until one of them is mined, confirmed and included in a block. Hence it is impossible to enforce "This (valid) transaction should take precedence over this (valid) transaction" other than through the use of transaction fees. You can try to incentivize miners to include one of the competing transactions in a block by increasing the transaction fee of that transaction but there is no guarantee that the lower fee transaction won't get mined.

It is possible that other blockchains using account rather than UTXO models and with more expressive scripting languages could do this but this kind of thing isn't possible with Bitcoin today.