2

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?

Improve this question

1 Answer 1

Reset to default
3

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.

Improve this answer
7
  • 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
    Commented Nov 8, 2015 at 15:24
  • 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
    Commented Nov 8, 2015 at 15:35
  • 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
    Commented Nov 8, 2015 at 16:03
  • 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
    Commented Nov 8, 2015 at 16:06
  • 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
    Commented Nov 8, 2015 at 16:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.