<p>What you can't do without covenants enabled on Bitcoin is impose restrictions on where funds go assuming the unlocking conditions have been met. Similarly you cannot give a party or multiple parties the ability to cancel a transaction if the unlocking conditions have been met, nor can you cancel one of the possible spending paths without moving the funds to a new output with a new set of unlocking conditions. If you want pubkey3 etc to have control over whether the funds move you have to require a signature from that pubkey in the script. Perhaps you choose to require a signature from pubkey3 in every possible spending path. That's the only way to give individual 3 the ability to impact whether those funds move or not.</p>
<p>Without this all individual 3 can do if they aren't happy with a valid transaction that has been broadcast is enter into a fee race where individual 3 tries to get a transaction into the blockchain satisfying different unlocking conditions to a competing transaction (assuming there are multiple possible spending paths) but this is clearly not an optimal outcome and security of the funds shouldn't depend on the results of such a fee race.</p>
<p>This could change with the introduction of covenants but that would be dependent on the covenant proposal and the exact functionality that you would like in your script.</p>

CC BY-SA 4.0
2022-07-30T11:39:16.913Z
2022-07-30T11:56:05.767Z
2022-07-30T11:56:05.767Z
Michael Folkson
<p>I had an idea for an optimistic multisig scheme. In a 2/2 multisig where pubkey1 could spend any time and pubkey2 could only spend after a future block number, could you have a condition that allowed pubkey3...n to make the transaction unredeemable before pubkey2 could redeem it? This would give pubkey3...n some time to verify the integrity of the transaction based on exogenous criteria before the funds could be spent.</p>

<script><multi-signature><covenants>
Optimistic Multisigs
slider
# Optimistic Multisigs

(Asked by: username_0 on 2022-07-29)

I had an idea for an optimistic multisig scheme. In a 2/2 multisig where pubkey1 could spend any time and pubkey2 could only spend after a future block number, could you have a condition that allowed pubkey3...n to make the transaction unredeemable before pubkey2 could redeem it? This would give pubkey3...n some time to verify the integrity of the transaction based on exogenous criteria before the funds could be spent.

**Tags:** script, multi-signature, covenants


---

## 1 answers

### Answer by username_1 on 2022-07-30. Score: 1 | Accepted answer

What you can't do without covenants enabled on Bitcoin is impose restrictions on where funds go assuming the unlocking conditions have been met. Similarly you cannot give a party or multiple parties the ability to cancel a transaction if the unlocking conditions have been met, nor can you cancel one of the possible spending paths without moving the funds to a new output with a new set of unlocking conditions. If you want pubkey3 etc to have control over whether the funds move you have to require a signature from that pubkey in the script. Perhaps you choose to require a signature from pubkey3 in every possible spending path. That's the only way to give individual 3 the ability to impact whether those funds move or not.

Without this all individual 3 can do if they aren't happy with a valid transaction that has been broadcast is enter into a fee race where individual 3 tries to get a transaction into the blockchain satisfying different unlocking conditions to a competing transaction (assuming there are multiple possible spending paths) but this is clearly not an optimal outcome and security of the funds shouldn't depend on the results of such a fee race.

This could change with the introduction of covenants but that would be dependent on the covenant proposal and the exact functionality that you would like in your script.


---

