<p>Your question is a nice thought experiment. </p>

<p>Your example would not itself work: as CHECKSEQUENCEVERIFY is relative to the mining date or height, so in week 3, all three parties could sign at the same time.  On day 1 things work as you intend. On day 8 'X' can now sign at any point without delay but must wait a week for Y and two for Z. On day 15, 'X' and 'Y' can both sign at any point without delay but must wait a further week for Z. On day 22 all three of them can sign without delay, and it's no different to a regular multisig.</p>

<p>The direction of your thoughts seems to be that CHECKSEQUENCEVERIFY could be made relative to a previous signature. I'm not aware of any method of doing this within a single script: how can a computer tell that a signature has been made more than a week prior, other than by seeing it on the blockchain? The mempool would be wholly inappropriate a venue not least because people would be storing something for potentially long periods of time.</p>

<p>An improvement of sorts would be to have the multisig lock 10% of the funds for ten months, and each month, lock another 10%. At the start of the eleventh month, the three of them redeem to a new multisig, and so relock that original 10% for a new set of ten months. In this manner, all three of them are needed and 90% of the funds are locked for at least one month even if they're all present.</p>

CC BY-SA 4.0
2019-09-14T01:55:06.020Z
2019-09-14T01:55:06.020Z
Alistair Mann
<p>I've been wondering about cold storage multi sig security. </p>

<p>Specifically, I was wondering how secure it is with respect to a kidnapper. If a kidnapper took X hostage, and threatened to kill him, X would simply share the other members (ie Y, Z), required to submit a transaction. In that case, X could be forced to call Y &amp; Z, and tell them some arbitrary reason he needed them to sign on such short notice, (or even tell them the truth if he really feared for his life), and Y and Z would certainly sign to keep their friend X alive.</p>

<p>Please let me know if I'm missing something in the above scenario...</p>

<p>Because of the above scenario, I was wondering if it is possible to require a wait time between signatures in a multi sig.</p>

<p>That would result in a kidnapper needing to hold X hostage for, say 1 week, before Y's signature would be valid, and possibly another 1 week before Z's signature would be valid. This seems a lot safer since the attack cannot be completed as quickly and an attacker would need to 'not get caught by police' over a much longer time frame.</p>

<p>I've looked at <code>OP_CHECKSEQUENCEVERIFY</code> but I have never played with script yet so I'm not sure I totally understand. </p>

<p>Would something like the below work? </p>

<pre><code>"+1week" CHECKSEQUENCEVERIFY DROP &lt;X pubkey&gt;
"+2week" CHECKSEQUENCEVERIFY DROP &lt;Y pubkey&gt;
"+3week" CHECKSEQUENCEVERIFY DROP &lt;Z pubkey&gt;
</code></pre>

<script>
Is a multi script possible that requires relative time locks relative to each signature?
Terence Chow
# Is a multi script possible that requires relative time locks relative to each signature?

(Asked by: username_0 on 2019-08-31)

I've been wondering about cold storage multi sig security.

Specifically, I was wondering how secure it is with respect to a kidnapper. If a kidnapper took X hostage, and threatened to kill him, X would simply share the other members (ie Y, Z), required to submit a transaction. In that case, X could be forced to call Y & Z, and tell them some arbitrary reason he needed them to sign on such short notice, (or even tell them the truth if he really feared for his life), and Y and Z would certainly sign to keep their friend X alive.

Please let me know if I'm missing something in the above scenario...

Because of the above scenario, I was wondering if it is possible to require a wait time between signatures in a multi sig.

That would result in a kidnapper needing to hold X hostage for, say 1 week, before Y's signature would be valid, and possibly another 1 week before Z's signature would be valid. This seems a lot safer since the attack cannot be completed as quickly and an attacker would need to 'not get caught by police' over a much longer time frame.

I've looked at `OP_CHECKSEQUENCEVERIFY` but I have never played with script yet so I'm not sure I totally understand.

Would something like the below work?

```
"+1week" CHECKSEQUENCEVERIFY DROP <X pubkey>
"+2week" CHECKSEQUENCEVERIFY DROP <Y pubkey>
"+3week" CHECKSEQUENCEVERIFY DROP <Z pubkey>

```

**Tags:** script


---

## 1 answers

### Answer by username_1 on 2019-09-14. Score: 1

Your question is a nice thought experiment.

Your example would not itself work: as CHECKSEQUENCEVERIFY is relative to the mining date or height, so in week 3, all three parties could sign at the same time. On day 1 things work as you intend. On day 8 'X' can now sign at any point without delay but must wait a week for Y and two for Z. On day 15, 'X' and 'Y' can both sign at any point without delay but must wait a further week for Z. On day 22 all three of them can sign without delay, and it's no different to a regular multisig.

The direction of your thoughts seems to be that CHECKSEQUENCEVERIFY could be made relative to a previous signature. I'm not aware of any method of doing this within a single script: how can a computer tell that a signature has been made more than a week prior, other than by seeing it on the blockchain? The mempool would be wholly inappropriate a venue not least because people would be storing something for potentially long periods of time.

An improvement of sorts would be to have the multisig lock 10% of the funds for ten months, and each month, lock another 10%. At the start of the eleventh month, the three of them redeem to a new multisig, and so relock that original 10% for a new set of ten months. In this manner, all three of them are needed and 90% of the funds are locked for at least one month even if they're all present.


---

