Lesson 17


VIDEO: Maciej Trebacz - Multi-Signature

What are multi-signature addresses?

Bitcoin includes a multi-signature feature that allows a transaction to require multiple independent approvals to be spent. A multi-signature address is a Bitcoin address that is associated with more than one ECDSA private key. The simplest type is an m-of-n address - it is associated with n private keys, and sending bitcoins from this address requires signatures from at least m keys. A multi-signature transaction is one that sends funds from a multi-signature address.

Why they are needed?

The primary use case is to secure coins against theft. With a 2-of-2 address, you can keep the two keys on separate machines, and then theft will require compromising both, which is much harder - especially if the machines are not in the same network and are not vulnerable to the same malware (e.g. have different OS, hardware, internet connection etc).

It can also be used for additional precautions to protect against key loss - with 2-of-3 address you can lose any key out of 3 but still be able to spend funds. You can even give some keys to the trusted party(-ies) which is supposed to verify your intentions every time you initiate the payment. This allows for more flexible options than just backups. It can also be used for more advanced scenarios such as an address shared by multiple people (family or non-profit), where agreement of some particular group of people is required to spend funds.

Advantages for Web Wallet security

More than $500M dollars were stolen from wallets and exchanges that stored users’ money. People are still using them because it is even harder to manage private keys themselves. But multisignature allows to build solutions that combine security and usability at the same time. Let see how it is done:

  1. Security

    1. The service cannot spend funds without user’s approval

    2. If hacker steals the user’s password/private key she is not able to steal funds

    3. Malware on the user’s computer cannot steal funds

  2. Usability

    1. The user can access his funds from any computer

    2. The user does not need to remember his private key and can access funds with a password and two-factor authentication.

  3. Trustless

    1. The user can get access to the funds even if the service is shut down or disappear

    2. The user can lose his website password and not lose his funds


Conditions needed to implement such a requirements:

  • A service that is accessible over TLS.

  • Usage of 2-factor authentication

  • Usage of strong passwords

  • Usage of backup transactions

  • Usage of backup private key


Ways of usage of multi-signature for web wallets

There are two approaches to build a secure online wallet: 1) using 2-of-2 signatures and 2) 2-of-3 signatures. Lets discuss how do the work.


In case of 2-of-2 both keys are needed to sign the transaction. It means that it is important not to loose any of them. User generates one key on his computer, the other one is generate on the server side. The user encrypts his private key using some password and stores it either on hardware device or on the web-service. To protect from service shutdown backup transactions are used - after changing a balance of the user server generates backup transaction that sends money back to user-controlled address. Server then signs the transaction and sends to user’s email. But even if attacker gets access to mailbox and private key of the user simultaneously this transaction cannot be spent immediately - it has locktime that is somewhere in the future (for example 2 weeks). It is ensured during normal workflow that before locktime is expired funds should be moved to the other address and new backup transaction is generated. Normal use case is that user possesses only one key and every transaction should be signed by the server as well. Server will sign the transaction only if 1) user signed it themselves and 2) 2-factor authentication is successful.

In 2-of-3 scheme the user will generate 2 keys while the server will generate one. Address creation time is the only time when two or more of the keys are on the same computer concurrently. These two keys have different purpose - one of them is working key and the other is backup key. The backup private key will be printed out and stored completely offline only on the user’s machine. It could be used only for fund recovery if server is down. Server is not needed to create backup transactions in this case.

The user’s private key will be encrypted on the user’s machine with a strong password of the user’s choice. The encrypted private key and the public key could be stored in the service or on hardware device. The service cannot get access to the funds if encryption is done in the trustworthy environment.

Withdrawing Funds from the 2-of-3 Address

To withdraw funds from the multisig address:

1. The user logins to the service, and makes the request to move funds signing transaction with his private key.

2. The service asks the user to authenticate with a 2-factor authentication code to a smartphone or mobile device. Usage of some other device and channel of communication is a good practice to reduce the risk that attacker controls the whole environment.

3. After validation of the 2-factor authentication, the service the service applies the 2nd signature using its private key. However, service can apply certain transaction limits that increases security.

Implementation of multisignature - Pay To Script Hash (P2SH)

P2SH is a new type of bitcoin address which was introduced as part of Bitcoin Improvement Proposal 16 (BIP 16) in early 2012. P2SH addresses can be secured by more complex algorithms than traditional bitcoin addresses. P2SH addresses were created to let a spender create a pubkey script containing a hash of a second script, the redeem script.

The basic P2SH workflow, illustrated below, looks almost identical to the normal P2PKH workflow. Bob creates a redeem script with whatever script he wants, hashes the redeem script, and provides the redeem script hash to Alice. Alice creates a P2SH-style output containing Bob’s redeem script hash.

When Bob wants to spend the output, he provides his signature along with the full (serialized) redeem script in the signature script. The peer-to-peer network ensures the full redeem script hashes to the same value as the script hash Alice put in her output; it then processes the redeem script exactly as it would if it were the primary pubkey script, letting Bob spend the output if the redeem script does not return false.

The hash of the redeem script has the same properties as a pubkey hash—so it can be transformed into the standard Bitcoin address format with only one small change to differentiate it from a standard address. This makes collecting a P2SH-style address as simple as collecting a P2PKH-style address. The hash also obfuscates any public keys in the redeem script, so P2SH scripts are as secure as P2PKH pubkey hashes.


Pic. 1 - Spending from a P2SH address


In multisig pubkey scripts, called m-of-n, m is the minimum number of signatures which must match a public key; n is the number of public keys being provided. Both m and n should be op codes OP_1 through OP_16, corresponding to the number desired.

Because of an off-by-one error in the original Bitcoin implementation which must be preserved for compatibility, OP_CHECKMULTISIG consumes one more value from the stack than indicated by m, so the list of secp256k1 signatures in the signature script must be prefaced with an extra value (OP_0) which will be consumed but not used.

The signature script must provide signatures in the same order as the corresponding public keys appear in the pubkey script or redeem script.


Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL

Signature script: <sig> [sig] [sig...] <redeemScript>


Pubkey script: <m> <A pubkey> [B pubkey] [C pubkey...] <n> OP_CHECKMULTISIG

Signature script: OP_0 <A sig> [B sig] [C sig...]


Although it’s not a separate transaction type, this is a P2SH multisig with 2-of-3:


Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL

Redeem script: <OP_2> <A pubkey> <B pubkey> <C pubkey> <OP_3> OP_CHECKMULTISIG

Signature script: OP_0 <A sig> <C sig> <redeemScript>

Maintaining Privacy

To maintain maximal privacy, it is important to not re-use bitcoin addresses. However, re-generating such keys with each transaction would make many of the backup benefits that come with this system difficult. Users of bitcoin standard addresses already face this problem today and use a variety of deterministic wallet mechanisms to generate multiple keys from a single source. The same techniques can be applied to the multisig addresses. Any key used as a signature should be rotated to a new address based on the next sequence in the deterministic key.

Achieving maximum security

The weakest point in website multisignature implementation is a key generation in the browser - Malware that specifically targeted can steal one or two user’s private keys depending on scheme used. It is a common problem for JavaScript environment. To prevent this either desktop applications (or browser extension) or hardware wallets should be used.


What is special about Bitalo's Multi-Signature Architecture?

A very good example on how multi-signature can be used to create really secure web based services is Bitalo.

In contrast to the single-key model, multi-signature Bitcoin wallets use multiple keys. Bitalo uses multi-signature wallets that consist of TWO keys to access bitcoins:

A) Your Key which is generated in your browser, completely outside of the remit of Bitalo

B) A Bitalo Key which is generated on the bitalo server.

The User key is NOT stored as such on the Bitalo server. Instead, it is first encrypted on your device with your passphrase. (READ MORE: Since the encryption of private keys and signing of transactions is done in the browser using unobfuscated and non-minified JavaScript, technically savvy users can easily examine and verify the code step by step.)

To send bitcoins, the following steps are taken:
- the Bitalo server creates an unsigned transaction
- your browser reads the unsigned transaction and your encrypted user key
- your browser decrypts the the user key using your passphrase
- your browser signs the transaction with the unencrypted user key
- the half-signed transaction is sent to the server
- the server signs the transaction with the Bitalo key
- you confirm the transaction with your two-factor authentication
- the server publishes the transaction to the Bitcoin network
This allows users to easily send transactions while also allowing a maximum level of security.

Since Bitalo only holds one key out of the two required ones, it cannot send your bitcoins without explicit confirmation. Even in scenarios where a hacker or malicious site administrator would like to steal bitcoins, the attacker would be unable to access your bitcoins, since he can only see the encrypted key. This is state-of-the art bitcoin security and provides far better security than traditional single-key wallets that are used by most bitcoin websites.

Similarly, the security model also extends to the user's computer. If an attacker manages to fully compromise the your computer, thanks to proper two-factor authentification it is not possible to confirm the transaction, unless the two-factor device (like the mobile phone) is also compromised at the same time.

Bitalo offers the following additional security features:

Mandatory Two Factor Authentication
Bitalo has a mandatory two-factor authentication via MePIN, either by SMS or a dedicated mobile App. This is required for the case that your computer is compromised. Since MePIN can be setup completely on a external device like your Ipad or your mobile phone you can safely set up your Bitalo account on a fully compromised computer.

Rescue Transaction
Bitalo has furthermore foreseen a rescue plan for extreme circumstances like the whole website goes offline, Bitalo refuses to relase bitcoins or the complete database is erased. For this purpose you can enter a secure (e.g. offline) bitcoin address that only you can access. Bitalo will pre-sign a transaction that you will receive by email and can redeem it at any time independently from the existence of Bitalo. This is a highly secure method, since even when the backup transaction is stolen by a hacker, all the hacker can do is, to redeem the bitcoins to your address

At Bitalo you do not depend on the reliability of a third party. Since we use real addresses, you can verify the correctness of your balance at anytime by simply viewing the public blockchain. There is absolutely no need for third party audits to prove that your bitcoins exist.




comments powered by Disqus

You will get an awesome place to trade your
Bitcoin and more. Click for further information!

Choose your topic

and start the journey