<blockquote>
  <p>From what I understand, it looks like multi-signature 2-of-3 addresses require three public keys to generate</p>
</blockquote>

<p>The requirement is for <em>private</em> keys, the public keys are well, public: everybody knows them. A 2 of 3 script requires that any two of the three mentioned keys is needed, and you can use variations of this such as 2 of 2, 3 of 3, 1 of 3, etc. </p>

<blockquote>
  <p>are spent via raw transactions</p>
</blockquote>

<p>It's also worth nothing that "raw transactions" is just a term used in Bitcoin Core when taking about anything which is not Pay to Pubkey Hash, it's pretty meaningless unless you're talking about the client itself. </p>

<blockquote>
  <p>So why do these services not allow you to keep all three keys? </p>
</blockquote>

<p>The intention in multi signature wallets is that you can have a requirement for multiple parties to authorize a transaction. In the case of this model, you would have a 2-of-2 system, where there are two parties and both are required to sign in order to spend the related funds. This has the following properties:</p>

<ul>
<li><p>The service can not outright steal the money from the user, as the user needs to sign the transaction as well. </p></li>
<li><p>The user can have restrictions placed on them by the third party, say, they won't sign transactions which spend more than $10 a day, or without the requirement of additional authorization. </p></li>
<li><p>Transactions can be authored in such a way that if the service refuses to sign any transactions (randoms the user, or goes out of business), after a significant passing of time the requirement is reduced to just a single signature from the user. </p></li>
</ul>

<p>With these properties you can author very powerful systems with arbitrary spending requirements without risking the loss of money by giving complete of your money to anybody else. </p>

<p>In the case of web wallets however, this system is almost completely snake oil cryptography as the third party is also the one serving the code to the users. At any time they can alter this to different code which just sends the private keys back to them, or blindly signs any transaction they want. There's absolutely no way of making web wallets safe in light of this property. </p>

<blockquote>
  <p>So why do these services not allow you to keep all three keys? </p>
</blockquote>

<p>Then it would be pointless having multisignature transactions where one party holds all the keys, it would cost a lot less to just use regular transactions. Multisignature scripts tend to have significantly higher costs for use compared with regular transactions. </p>

CC BY-SA 3.0
2015-11-08T15:24:28.030Z
Sorry, I should have been clearer - you need N public keys to create a multisignature address (individual addresses themselves are hashes of the public keys which can't be derived from the address, which is why you can't create a multisignature address without having access to the private key and thus the actual public key) if I'm not mistaken.

So the short answer to my question, leaving out the issue of the security of the code being served to the user, is that there's no reason the service has to hold any of the private keys if they're simply acting as a full node proxy, correct?
Nate Simpson
CC BY-SA 3.0
2015-11-08T15:35:08.687Z
Also, as a side question, is the situation with code security really that much different from the fact that if you acquire an actual desktop wallet from any third-party source rather than building one yourself (perhaps literally from nothing), you're trusting the source to some degree to handle your money correctly?
Nate Simpson
CC BY-SA 3.0
2015-11-08T16:03:45.457Z
What's more dangerous, downloading a wallet binary or downloading a wallet binary with no validation or verification every single time you open the application? Web wallets are a broken concept that should be used by nobody.
Claris
CC BY-SA 3.0
2015-11-08T16:06:24.677Z
The multi signature bit is irrelevant if the user owns all of the keys on one device, but they can happily do multisig between multiple of their own devices if they want. You can create public keys for a HD wallet without the private keys, see BIP32. P2SH addresses are often used for multisignature scripts but they can contain anything else as well, there's no such thing as a multisig address.
Claris
CC BY-SA 3.0
2015-11-08T16:16:04.500Z
I'm aware that P2SH addresses are literally scripts - I was only interested in the multisig implementation, and not referring to BIP32. I still don't see a simple answer to my core question: is there any reason that 1 or more of the private keys in a P2SH address _must_ reside in the wallet of the client handling the transfer, or is passing them in as extra parameters to a raw transaction sufficient, and thus is there any reason why the client service needs any of the private keys at all, encrypted or no, stored on that service in the simplest use case of a proxy transaction?
Nate Simpson
CC BY-SA 3.0
2015-11-08T16:20:20.560Z
It's difficult to gauge your competency if you intentionally misuse technical terminology. What is "handling the transfer"? Moving a transaction does not require any signatures, making the script hash requires the public keys, signing a spend using that p2sh script requires the relevant private key/s they are signing for but not the others. You can pass partially signed transactions between parties if necessary.
Claris
CC BY-SA 3.0
2015-11-08T16:23:59.377Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/31265/discussion-between-nate-simpson-and-bitcoin).
Nate Simpson
CC BY-SA 3.0
2015-11-08T13:16:57.643Z
2015-11-08T13:16:57.643Z
Claris
<p>I've been researching multi-signature transactions and am wondering, as the title says, why a web wallet offering multi-signature transactions (2-of-3, for example) like blockchain.info would need any of your private keys at all. From what I understand, it looks like multi-signature 2-of-3 addresses require three public keys to generate, and are spent via raw transactions. </p>

<p>So why do these services not allow you to keep all three keys? </p>

<p>Is there some reason that one of the keys must be kept by the wallet provider? It doesn't seem like any of the keys are required to be in the provider's wallet so long as they are available to sign the raw transaction before sending -- and in theory the raw transaction could be created by the client in the browser and submitted for transmission via sendrawtransaction without involving the provider in any sense other than raw connectivity to the network.</p>

<p>What am I missing?</p>

<multi-signature><raw-transaction>
Why do web wallets using multi-signature need 1 of N keys?
Nate Simpson
# Why do web wallets using multi-signature need 1 of N keys?

(Asked by: username_0 on 2015-11-08)

I've been researching multi-signature transactions and am wondering, as the title says, why a web wallet offering multi-signature transactions (2-of-3, for example) like blockchain.info would need any of your private keys at all. From what I understand, it looks like multi-signature 2-of-3 addresses require three public keys to generate, and are spent via raw transactions.

So why do these services not allow you to keep all three keys?

Is there some reason that one of the keys must be kept by the wallet provider? It doesn't seem like any of the keys are required to be in the provider's wallet so long as they are available to sign the raw transaction before sending -- and in theory the raw transaction could be created by the client in the browser and submitted for transmission via sendrawtransaction without involving the provider in any sense other than raw connectivity to the network.

What am I missing?

**Tags:** multi-signature, raw-transaction


---

## 1 answers

### Answer by username_1 on 2015-11-08. Score: 3 | Accepted answer

> From what I understand, it looks like multi-signature 2-of-3 addresses require three public keys to generate

The requirement is for *private* keys, the public keys are well, public: everybody knows them. A 2 of 3 script requires that any two of the three mentioned keys is needed, and you can use variations of this such as 2 of 2, 3 of 3, 1 of 3, etc.

> are spent via raw transactions

It's also worth nothing that "raw transactions" is just a term used in Bitcoin Core when taking about anything which is not Pay to Pubkey Hash, it's pretty meaningless unless you're talking about the client itself.

> So why do these services not allow you to keep all three keys?

The intention in multi signature wallets is that you can have a requirement for multiple parties to authorize a transaction. In the case of this model, you would have a 2-of-2 system, where there are two parties and both are required to sign in order to spend the related funds. This has the following properties:

* The service can not outright steal the money from the user, as the user needs to sign the transaction as well.
* The user can have restrictions placed on them by the third party, say, they won't sign transactions which spend more than $10 a day, or without the requirement of additional authorization.
* Transactions can be authored in such a way that if the service refuses to sign any transactions (randoms the user, or goes out of business), after a significant passing of time the requirement is reduced to just a single signature from the user.

With these properties you can author very powerful systems with arbitrary spending requirements without risking the loss of money by giving complete of your money to anybody else.

In the case of web wallets however, this system is almost completely snake oil cryptography as the third party is also the one serving the code to the users. At any time they can alter this to different code which just sends the private keys back to them, or blindly signs any transaction they want. There's absolutely no way of making web wallets safe in light of this property.

> So why do these services not allow you to keep all three keys?

Then it would be pointless having multisignature transactions where one party holds all the keys, it would cost a lot less to just use regular transactions. Multisignature scripts tend to have significantly higher costs for use compared with regular transactions.

> **Comments:**
> **username_0**: Sorry, I should have been clearer - you need N public keys to create a multisignature address (individual addresses themselves are hashes of the public keys which can't be derived from the address, which is why you can't create a multisignature address without having access to the private key and thus the actual public key) if I'm not mistaken.  So the short answer to my question, leaving out the issue of the security of the code being served to the user, is that there's no reason the service has to hold any of the private keys if they're simply acting as a full node proxy, correct?  
> **username_0**: Also, as a side question, is the situation with code security really that much different from the fact that if you acquire an actual desktop wallet from any third-party source rather than building one yourself (perhaps literally from nothing), you're trusting the source to some degree to handle your money correctly?  
> **username_1**: What's more dangerous, downloading a wallet binary or downloading a wallet binary with no validation or verification every single time you open the application? Web wallets are a broken concept that should be used by nobody.  
> **username_1**: The multi signature bit is irrelevant if the user owns all of the keys on one device, but they can happily do multisig between multiple of their own devices if they want. You can create public keys for a HD wallet without the private keys, see BIP32. P2SH addresses are often used for multisignature scripts but they can contain anything else as well, there's no such thing as a multisig address.  
> **username_0**: I'm aware that P2SH addresses are literally scripts - I was only interested in the multisig implementation, and not referring to BIP32. I still don't see a simple answer to my core question: is there any reason that 1 or more of the private keys in a P2SH address _must_ reside in the wallet of the client handling the transfer, or is passing them in as extra parameters to a raw transaction sufficient, and thus is there any reason why the client service needs any of the private keys at all, encrypted or no, stored on that service in the simplest use case of a proxy transaction?  
> **username_1**: It's difficult to gauge your competency if you intentionally misuse technical terminology. What is "handling the transfer"? Moving a transaction does not require any signatures, making the script hash requires the public keys, signing a spend using that p2sh script requires the relevant private key/s they are signing for but not the others. You can pass partially signed transactions between parties if necessary.  
> **username_0**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/31265/discussion-between-username_0-and-bitcoin).  

---

