<p>Your desired setup sounds very similar to a &quot;Degrading Multisig,&quot; and is possible with taproot.</p>
<p>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 <code>Taptree</code>. 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.</p>
<p>You can see an example of a similar setup here: <a href="https://github.com/bitcoinops/taproot-workshop/blob/master/3.1-degrading-multisig-case-study.ipynb" rel="nofollow noreferrer">https://github.com/bitcoinops/taproot-workshop/blob/master/3.1-degrading-multisig-case-study.ipynb</a>. 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.</p>

CC BY-SA 4.0
2023-02-01T08:17:44.570Z
2023-02-01T08:17:44.570Z
josie
<p>As Josie says in his answer a degrading/time decay multisig (also discussed <a href="https://bitcoin.stackexchange.com/questions/116035/how-do-i-set-up-a-time-decay-multisig">here</a>) seems to be the best solution to what you want.</p>
<blockquote>
<p>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 &gt; k). Hence these other spends are invalidated.</p>
</blockquote>
<p>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 &quot;This (valid) transaction should take precedence over this (valid) transaction&quot; 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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-02-01T09:26:53.763Z
2023-02-01T11:43:31.703Z
2023-02-01T11:43:31.703Z
Michael Folkson
<p>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 &gt; k). Hence these other spends are invalidated.</p>
<p>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.</p>
<p>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).</p>
<p>Does this work? Are there better ways to do it?</p>

CC BY-SA 4.0
2023-02-01T07:54:05.807Z
I'm not sure what you mean by "other spends are invalidated." Its seems like you are describing a scheme where spends using less keys _become_ valid after a timelock.
josie
CC BY-SA 4.0
2023-02-01T08:46:11.310Z
Related: https://bitcoin.stackexchange.com/questions/116035/how-do-i-set-up-a-time-decay-multisig
Michael Folkson
<transactions><script><multi-signature><taproot>
Precedence of competing multisig spends
Son Kaos999
# Precedence of competing multisig spends

(Asked by: username_0 on 2023-01-20)

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?

**Tags:** transactions, script, multi-signature, taproot

> **Comments:**
> **username_1**: I'm not sure what you mean by "other spends are invalidated." Its seems like you are describing a scheme where spends using less keys _become_ valid after a timelock.  
> **username_2**: Related: https://bitcoin.stackexchange.com/questions/116035/how-do-i-set-up-a-time-decay-multisig  

---

## 2 answers

### Answer by username_1 on 2023-02-01. Score: 2 | Accepted answer

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 by username_2 on 2023-02-01. Score: 1

As username_1 says in his answer a degrading/time decay multisig (also discussed [here](https://bitcoin.stackexchange.com/questions/116035/how-do-i-set-up-a-time-decay-multisig)) 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.


---

