<p>You are right, multisig as implemented in Bitcoin right now requires M participants out of N to sign. However, the use case you want is doable with more complex scripting.</p>

<p>For example, K1 + (K2 or K3 or K4) could be done with something like:</p>

<p><code>&lt;pk1&gt; CHECKSIGVERIFY 1 &lt;pk2&gt; &lt;pk3&gt; &lt;pk4&gt; 3 CHECKMULTISIG</code></p>

<p>That script can be redeemed with the signature of K1 and a signature of one of K2, K3 or K4.</p>

CC BY-SA 3.0
2017-11-09T14:40:24.937Z
It looks amazing. I will take a look in the scripting. But, if one client have multiples keys (so `K1 + ((K2A + K2B) + K3 + K4)`, one client (K2) have multiples key (K2A and K2B), it is possible using the scripting for it too?
Inkeliz
CC BY-SA 3.0
2017-11-09T19:53:19.337Z
For the client keys, you can also look at secret schemes like [Shamir's Shared Secret](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). It even simplifies the whole thing by making the transaction a multisig of K1 and a key split in several parts, any number of which can be used to reconsruct the key.
alcio
CC BY-SA 3.0
2017-11-09T20:13:32.607Z
But, with this method (if I understand correctly) the reconstruction will occur in one device. My priority having multiples keys per client is to store key in separate places, so one in computer and another in the smartphone. In fact, if an attacker stole (or get control) of one device, we still secure, until the second key is unknown. I don’t know if I will implement this multiples keys in my software, but have a high possibility. Anyway, I’m trying to understand more about the Bitcoin Scripting.
Inkeliz
CC BY-SA 3.0
2017-11-09T20:25:14.127Z
One future enabler of your use case is MAST (Merkelized Abstract Syntax Tree). With them, you can create a script which has many possible branches ```(K1 + K2) or (K1 + K3) ... or (K1 + Kn)``` but only publish the executed branches.
alcio
CC BY-SA 3.0
2017-11-09T14:04:48.310Z
2017-11-09T14:04:48.310Z
alcio
<p>At least for your example, it seems you could just use 2 multi-sig wallets that are both m-of-n equals 2-of-3. No?</p>

CC BY-SA 3.0
2018-04-08T14:39:34.710Z
2018-04-08T14:39:34.710Z
Aaron Perlmutter
<p>I search about multisignature wallets, but it seems very limited. Far I understand, we can create a wallet with N keys, and specify how many keys is needed to create a transactions.</p>

<p>So, I can create one wallet with 5 keys (K1, K2, K3, K4, K5) and I can specify how many keys (but not which keys!) are needed, so is possible to say: “you need 3 of 5 keys”. However, it makes a K1 + K2 + K3 and K5 + K4 + K2 a valid signature. </p>

<p><strong>It’s possible to specify that which keys are needed rather than how many?</strong></p>

<p>Imagine that have three people (K2, K3, K4) and have a server (K1). Only with K1 + (K2 or K3 or K4) will be valid. It means that K2 + K3 or K4 + K3 can’t be able to create a valid transaction. To be a valid signature we need two signatures, but one of that two need to be the K1.</p>

<p>It’s possible?</p>

<hr>

<p>One alternative is creating a multiples multi-signatures wallets. I mean, create three addresses one with (K1 + K2), another with (K1 + K3) and so on. But, it will have multiples address, it is what I'm trying to avoid. Another solution is need all keys (4 of 4), but it will need the signature of the three clients, but it’s not easy and will need to wait everyone sign it.</p>

<hr>

<p>For the background of the history, I trying to use the OP_RETURN. Everyone can access one single address and view all the information, about the three clients. The OP_RETURN value will be generated by the server (K1) and need to be signed with one of the client (K2, K3, K4). But, the client itself can't be able to create a transaction alone, so K2 + K3 need to be an invalid signature. </p>

<multi-signature>
Is possible especify the keys rather how many in multisignature wallets?
Inkeliz
# Is possible especify the keys rather how many in multisignature wallets?

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

I search about multisignature wallets, but it seems very limited. Far I understand, we can create a wallet with N keys, and specify how many keys is needed to create a transactions.

So, I can create one wallet with 5 keys (K1, K2, K3, K4, K5) and I can specify how many keys (but not which keys!) are needed, so is possible to say: “you need 3 of 5 keys”. However, it makes a K1 + K2 + K3 and K5 + K4 + K2 a valid signature.

**It’s possible to specify that which keys are needed rather than how many?**

Imagine that have three people (K2, K3, K4) and have a server (K1). Only with K1 + (K2 or K3 or K4) will be valid. It means that K2 + K3 or K4 + K3 can’t be able to create a valid transaction. To be a valid signature we need two signatures, but one of that two need to be the K1.

It’s possible?

---

One alternative is creating a multiples multi-signatures wallets. I mean, create three addresses one with (K1 + K2), another with (K1 + K3) and so on. But, it will have multiples address, it is what I'm trying to avoid. Another solution is need all keys (4 of 4), but it will need the signature of the three clients, but it’s not easy and will need to wait everyone sign it.

---

For the background of the history, I trying to use the OP\_RETURN. Everyone can access one single address and view all the information, about the three clients. The OP\_RETURN value will be generated by the server (K1) and need to be signed with one of the client (K2, K3, K4). But, the client itself can't be able to create a transaction alone, so K2 + K3 need to be an invalid signature.

**Tags:** multi-signature


---

## 2 answers

### Answer by username_1 on 2017-11-09. Score: 1 | Accepted answer

You are right, multisig as implemented in Bitcoin right now requires M participants out of N to sign. However, the use case you want is doable with more complex scripting.

For example, K1 + (K2 or K3 or K4) could be done with something like:

`<pk1> CHECKSIGVERIFY 1 <pk2> <pk3> <pk4> 3 CHECKMULTISIG`

That script can be redeemed with the signature of K1 and a signature of one of K2, K3 or K4.

> **Comments:**
> **username_0**: It looks amazing. I will take a look in the scripting. But, if one client have multiples keys (so `K1 + ((K2A + K2B) + K3 + K4)`, one client (K2) have multiples key (K2A and K2B), it is possible using the scripting for it too?  
> **username_1**: For the client keys, you can also look at secret schemes like [Shamir's Shared Secret](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). It even simplifies the whole thing by making the transaction a multisig of K1 and a key split in several parts, any number of which can be used to reconsruct the key.  
> **username_0**: But, with this method (if I understand correctly) the reconstruction will occur in one device. My priority having multiples keys per client is to store key in separate places, so one in computer and another in the smartphone. In fact, if an attacker stole (or get control) of one device, we still secure, until the second key is unknown. I don’t know if I will implement this multiples keys in my software, but have a high possibility. Anyway, I’m trying to understand more about the Bitcoin Scripting.  
> **username_1**: One future enabler of your use case is MAST (Merkelized Abstract Syntax Tree). With them, you can create a script which has many possible branches ```(K1 + K2) or (K1 + K3) ... or (K1 + Kn)``` but only publish the executed branches.  

---

### Answer by username_2 on 2018-04-08. Score: 0

At least for your example, it seems you could just use 2 multi-sig wallets that are both m-of-n equals 2-of-3. No?


---

