This article was originally published in 2016, in response to the Bitfinex / BitGo hack.
“How did multisig fail? Why did people lose their money? I thought multisig was secure.” Through the Bitfinex hack it’s become apparent that people don’t really understand bitcoin’s multisig feature. There seems to be a lot of confusion over what multisig is and isn’t, what it inherently does or does not do. This article aims to clarify some of the most common misconceptions, explain how multisig actually works today, why policy controls aren’t a substitute for organizational security, and what you can do to protect yourself.
Multisig is a tool. Just like any other tool, it can be used to achieve a number of different results. This tool can be used to distribute and dilute risk of key compromise or loss, for redundancy as a backup, and to create joint-accounts where each party can spend from the same pool, or to separate duties within an organization.
Multisig is not a security plan. It can be a powerful component of a well designed security plan, but it is only ever one component. To simply say “multisig” without exploring the implementation, how it’s being used, and what goals are trying to be achieved, is meaningless. It’s not a security incantation, though it would be so much easier if it was.
In order to understand what it can and cannot do, we need to understand a bit about how it works. Don’t worry if you’re not a techie, this isn’t written for them – it’s written for everyone else.
Creating a multisig address. In order to create a multisig address, you simply need more than one public key. Let’s look at an example. Alice, Bob, and Charlie are all organizers of a local bitcoin and open blockchain meetup. They want to collect funds to support the meetup but don’t want any one of them, alone, to control the funds. They set up a multisignature address, using CoPay software, that allows them to select a 2-of-3 configuration, meaning two of the three of them must authorize the transaction before it will be valid. In this instance the possible signing combinations can be A&B, B&C, A&C.
What’s actually happening behind the scenes? Their software is constructing two things: a script that contains the instructions of how many signatures are required and what public keys correspond to private keys that are authorized to sign (m-of-n), and a hash which is the bitcoin address, starting with the number 3, corresponding to the script. The script is often called the “redeem script” because it contains the requirements to redeem or spend payments from the multisig address.
You can think of a redeem script as a set of permanent, unchangeable access controls. These limited access controls are embedded into the bitcoin address itself. Meaning when funds are sent to the corresponding address, the redeem script must be satisfied in order to move funds. The rules are set when the address is created and can never be changed. The rules are, literally, part of the address itself. This one of the most powerful parts of multisig, this is why many believe it is more secure than a traditional single-signer bitcoin address. When multisig is used as part of an overall security plan, it can provide additional protection against embezzlement, mistake, loss, fraud, single point of failure, by requiring multiple parties or multiple devices (multi-factor multi-sig) to approve a transaction.
But notice what it does not do.
There are no spending limits; you can withdraw all funds with one, properly signed, transaction.
There are no time limits; you can withdraw funds immediately with a properly signed transaction.
There are no daily transaction limits: you can create thousands of transactions per minute.
There are no notifications; you will not receive an email or text notification when funds are spent.
Policy controls are not inherently part of multisig today. At this point you may be confused because many wallets provide these types of added services. They’re advertised as additional security measures, as additional controls. What’s not so clear is that these services are implemented by the company’s software and internal policies – not by the bitcoin protocol. That’s important because it means the controls can be bypassed, the limits can be changed. While Bitcoin’s scripting language continues to evolve, and some protocol based policy controls, like lock-time, are available, they haven’t been widely implemented yet.
The take away: today’s policy controls aren’t as secure as they may seem. In fact, they’re only as secure as the system controlling policy changes. Unfortunately, that’s less secure than most people believe.
Sometimes keyholders automate signing, based on policy controls. Many multisignature wallets (but not all) now include automated transaction signing based upon policy controls as a feature of their wallets. In these implementations, the wallet company controls one of the keys used to create a multisignature address. That key, and it’s related signing functions, are controlled by software written by the company – the software is often called an oracle or signing oracle. At the time the address is created, in addition to the public keys, the wallet company collects the user defined policy controls. For example, a user might set a maximum daily limit of $1,000.00 USD withdraw. The address is created and the signing parameters of the signing oracle are set.
The signing process usually looks something like this – the user creates a transaction (say for $500.00 USD), signs it, and sends it to the wallet provider for countersigning. The oracle sees the transaction, checks for policy controls (here the $500 is less than $1000.00), countersigns and broadcasts the transaction to the bitcoin network. Speedy, convenient, efficient. Secure? Maybe. Maybe not. Maybe it seems more secure than it actually is.
Security depends on a lot of factors – not just how many keys are required to sign a transaction. It depends on processes and policies defining the policy controls: Who can change spending limits? Time limits? Notifications? When can they be changed? Is there a cooling-off period after they’re changed when no transactions will be signed? It also depends on the company’s internal security: Who has access to the oracle or signing keys? Where are the backups and who has access to those? Who writes the oracle software and is it open-source? These are just some examples of security concerns that aren’t addressed by multisig. Multisig means more than one key was used to create the address. Nothing more. It is not a euphemism for security. Alone, it’s not enough to keep our funds secure.
Security cannot be outsourced. As an industry, we need to stop confusing outsourcing signing keys with outsourcing security. Simply turning over signing keys and process controls to a third party will not protect you or your customers from theft. We need opt-in security standards, like CCSS, and annual security audits. Most importantly, we need to focus on understanding the risks and accurately explaining them to users.
Finally, always remember: “Not your keys, not your money.”