<p>The limits of such constructs are the 520 bytes of the redeem script (its opcodes). A signature is roughly 70 Bytes (length code, r-key, s-key ...), so you can calculate what n-of-m versions fit into 520 bytes.
All your ideas are possible with bitcoin.</p>

<p>E.g. you can create a 2 out of 6 multisig for B,C,D,E,F and G.</p>

<p>When you say "A" can sign it, I believe it is the same as "H". 
Then you run into 8 keys (8x70=560 bam...), so you are beyond the limits. 
You might circumvent this when creating a simple "smart contract":</p>

<pre><code>if &lt;pubkey A&gt; OR &lt;pubkey B&gt; else &lt;2-of-6 msig&gt;
</code></pre>

<p>then you are again in the limits. These type of ideas are explained e.g. in Andreas' book "Mastering Bitcoin, 2nd edition", chapter 7 "Advanced Transactions and Scripting". </p>

CC BY-SA 3.0
2017-11-28T13:12:45.373Z
520 bytes is not the limit today with SegWit.
Claris
CC BY-SA 3.0
2017-11-28T13:17:06.930Z
yup, Pieter has explained it here: https://bitcoin.stackexchange.com/questions/51509/will-segwit-allow-for-m-of-n-multisig-with-very-large-n-and-m?rq=1
pebwindkraft
CC BY-SA 3.0
2017-11-28T13:19:18.010Z
and in this case, one could even remove the if/else stuff, and just provide two addresses for "A" and two for "H"... (but watch out for the tx fees, as it grows in size)
pebwindkraft
CC BY-SA 3.0
2017-11-28T13:01:04.863Z
2017-11-28T13:01:04.863Z
pebwindkraft
<blockquote>
  <ol>
  <li>Address A signs it, or</li>
  <li>At least 3 of B,C,D,E,F and G sign it and H also signs it</li>
  </ol>
</blockquote>

<pre><code>OP_IF
  pubA OP_CHECKSIG
OP_ELSE
  OP_3 pubB pubC pubD pubE pubF OP_5 OP_CHECKMULTISIGVERIFY
  OP_2 pubG pubH OP_2 OP_CHECKMULTISIG
OP_ENDIF
</code></pre>

CC BY-SA 3.0
2017-11-28T13:19:08.593Z
2017-11-28T13:19:08.593Z
amaclin
<p>From what I've read, M-of-N multisig addresses are possible in bitcoin. But nothing I've read talks about the limits of that (eg I'm not sure if there are limits to M and N) nor whether there are more complex forms of multisig.</p>

<p>For example, something I think I would like to do is have an address that can be spent on in the following conditions:</p>

<ol>
<li>Address A signs it, or</li>
<li>At least 3 of B,C,D,E,F and G sign it <em>and</em> H also signs it</li>
</ol>

<p>This would allow me to have an address I can use normally that <em>also</em> can be accessed by a number of trusted 3rd parties in the case that Address A gets lost or destroyed. This would be useful to back up your bitcoins by distributing some keys to a number of friends (B,C,D,E,F,G) with an explanatory note and final key in your will (H). </p>

<p>Is this kind of thing at all possible in Bitcoin? </p>

<multi-signature>
How complex can bitcoin multi-signature addresses be?
B T
# How complex can bitcoin multi-signature addresses be?

(Asked by: username_0 on 2017-11-28)

From what I've read, M-of-N multisig addresses are possible in bitcoin. But nothing I've read talks about the limits of that (eg I'm not sure if there are limits to M and N) nor whether there are more complex forms of multisig.

For example, something I think I would like to do is have an address that can be spent on in the following conditions:

1. Address A signs it, or
2. At least 3 of B,C,D,E,F and G sign it *and* H also signs it

This would allow me to have an address I can use normally that *also* can be accessed by a number of trusted 3rd parties in the case that Address A gets lost or destroyed. This would be useful to back up your bitcoins by distributing some keys to a number of friends (B,C,D,E,F,G) with an explanatory note and final key in your will (H).

Is this kind of thing at all possible in Bitcoin?

**Tags:** multi-signature


---

## 2 answers

### Answer by username_1 on 2017-11-28. Score: 2 | Accepted answer

The limits of such constructs are the 520 bytes of the redeem script (its opcodes). A signature is roughly 70 Bytes (length code, r-key, s-key ...), so you can calculate what n-of-m versions fit into 520 bytes.
All your ideas are possible with bitcoin.

E.g. you can create a 2 out of 6 multisig for B,C,D,E,F and G.

When you say "A" can sign it, I believe it is the same as "H".
Then you run into 8 keys (8x70=560 bam...), so you are beyond the limits.
You might circumvent this when creating a simple "smart contract":

```
if <pubkey A> OR <pubkey B> else <2-of-6 msig>

```

then you are again in the limits. These type of ideas are explained e.g. in Andreas' book "Mastering Bitcoin, 2nd edition", chapter 7 "Advanced Transactions and Scripting".

> **Comments:**
> **username_2**: 520 bytes is not the limit today with SegWit.  
> **username_1**: yup, Pieter has explained it here: https://bitcoin.stackexchange.com/questions/51509/will-segwit-allow-for-m-of-n-multisig-with-very-large-n-and-m?rq=1  
> **username_1**: and in this case, one could even remove the if/else stuff, and just provide two addresses for "A" and two for "H"... (but watch out for the tx fees, as it grows in size)  

---

### Answer by username_3 on 2017-11-28. Score: 3

> 1. Address A signs it, or
> 2. At least 3 of B,C,D,E,F and G sign it and H also signs it

```
OP_IF
  pubA OP_CHECKSIG
OP_ELSE
  OP_3 pubB pubC pubD pubE pubF OP_5 OP_CHECKMULTISIGVERIFY
  OP_2 pubG pubH OP_2 OP_CHECKMULTISIG
OP_ENDIF

```


---

