Since the Bitfinex hack we’ve been hearing the term “multisig security” thrown around as if it were supposed to be some sort of talisman that wards off the evil eye of bitcoin theft. So it’s time we took a look at how it works, so that maybe when we find out how the hack happened, we’ll understand (maybe).
A multisig transaction, as its name implies, requires several valid signatures for it to be accepted. Traditional, simple transactions involve me sending bitcoin to another address and signing with my private key. But what if my computer was hacked and my private key was copied? Then the hacker could create a transaction with my bitcoins and sign with my private key. How can I protect my funds against that happening?
I could establish a rule that more than one signature is necessary for a transaction. Instead of just one private key, my public address could have two private keys, one held by me and one held by a trusted third party. For the transaction to go through, it has to be signed by both private keys. That way, if someone does get hold of my private key and tries to send him- or herself my bitcoins with that signature, it won’t go through unless the second signature (with the second private key) is also applied. It’s a bit like the rule in some banks that two signatures are required for withdrawals. It puts a “check” in place, and makes it much, much harder for a thief to get at my account.
That sounds simple enough, but how do I know the third party won’t disappear or go offline? And what if I don’t want to give a third party that much access to what I do with my bitcoins? Isn’t one of the cryptocurrency’s main advantages independence and anonymity? Multisig transactions can be set up to be 2-of-3. Instead an address having two private keys, it has three. Two are held by me (one easy to access, the other in cold storage, for example), and one by the third party. Normally myself and the third party would sign. But if the third party refuses or can’t for whatever reason, and I really want to enable the transaction anyway, I can dig up my other key and commit the second signature with that.
Another potential application is that of e-commerce trust. What if I bought something with bitcoin, sent the transaction, signed it with my private key and then never received the merchandise? I can ask for my money back, but it’s unlikely I’ll get it. To make both myself and the vendor more comfortable, I could send the payment to an escrow account with multisig security, for which myself, the vendor and a trusted third party hold the private keys. The vendor sees I have done this, and releases the goods. When I receive the goods, I create the payment transaction, instruct the third party to add his or her signature, and everyone is happy. If I refuse to pay, the vendor could try to convince the third party that I am behaving badly. If the third party believes that the vendor should be paid, he or she and the vendor sign the payment transaction. Presumably I’m not happy, but at least the vendor isn’t out of pocket.
Although the term “multisig transaction” is often used, it’s actually the address that is multisig. Any movement of funds from that address needs to be co-signed. The address can be a one-time public key created for a specific transaction (in which case “multisig transaction” and “multisig address” are interchangeable). Or it can be a multisig wallet, from which all transactions require more than one signature. Most multisig wallets are HD (hierarchical deterministic), which means that a sequence of addresses can be generated from a “seed”. These addresses can be re-generated at any time from that seed, but it is impossible to determine the seed from one of the addresses. Each address generated in this way can in turn generate a series of corresponding private keys. This increases security even further, by allowing each transaction from a wallet to use a different address.
The most common configuration for co-signing is 2-of-3, in which three private keys are issued for an address, and any two of them are enough to authorize the transaction. But the combination could be anything: 5-of-7, 2-of-2, 6-of-10… And the multisig feature does not always have to involve a trusted third party. It could be your partner if you have a shared account. It could be you, your Treasurer and your COO for a company address. Or you could hold both keys, but on separate computers (or one online, one offline), to reduce the possibility of a hacker getting hold of both of them.
Multisig functionality was not part of the original bitcoin platform. It was added in BIP 11 (the first standard Bitcoin Improvement Proposal) in late 2011, but did not start to be widely used until 2014, as commercial services started to make it easier to configure. At the beginning of 2014, only 0.02% of all bitcoins were multisig protected. Today the figure is up to almost 12%. (Note the big slump end-July/beginning-August – yup, that’s the Bitfinex hack, the graph shows a significant amount of bitcoins being transferred out of multisig accounts).
The first multisig wallet was commercialized by BitGo in August 2013, and had the added feature of two-factor authentication. The BitGo server would send a one-time code to the user’s phone. If the user used the correct private key and accurately typed the code into the interface, then BitGo would use its private key to countersign the transaction. In 2014 it added the HD functionality. Since then, Armory, CryptoCorp, BitPay, Circle, Coinbase, Xapo, Electrum, Ciphrex and other bitcoin services have implemented multisig protection, and several large exchanges (Kraken, Bitstamp, Bitfinex, Tera Exchange) have incorporated the functionality through collaborations.
There is no universal configuration format – each business case has different requirements, and each collaboration shares different priorities. Armory, for instance, introduced fully decentralized multisig functionality in July 2014, in which the user generates as many private keys as he or she wishes (up to 7), and can distribute and protect them separately. There is no “trusted third party” unless the user specifically designates one. As a digital custodian, Circle controls all the keys, in physical isolation, for the multisig security it uses to protect the bitcoins it holds for others. Xapo Vaults require 3-of-5 signatures from different cold storage vaults around the world.
In the bitcoin lifespan, multisig transactions are old news. They have been possible for 2/3 of bitcoin’s history (BIP11 was accepted in December 2011). But even now, they are not very widely used. Why? I suspect that it’s largely because of added complications. We’re lazy, and until we have a scare, we don’t see the point of implementing extra security measures. The recent Bitfinex hack could be enough to jolt us out of complacency, and send us searching for a safer option for our wallets. And wallet service providers will most likely continue to iterate and improve on their interfaces and their security. So multisig will increasingly become a relatively easy option, and who knows, perhaps even ending up as the default.
But the fact remains that multisig, as we have seen over the past week, is not as safe as we were led to believe. Once we know more about how the hacker managed to compromise two private keys, we’ll be able to draw conclusions about multisig’s reliability and needed updates.
Some potential weaknesses of multisig technology that come to mind:
- In many cases, the third party signing is automated, and flags are only raised in certain circumstances (large amounts, sudden high volume of transfers, etc.). It would be theoretically possible for a thief to siphon off bitcoins without raising any flags.
- Insider collusion. A hacker happens to work for a multisig wallet provider. He or she gets hold of the user’s private key, and then double-signs with the wallet’s key, diverting funds to his or her own account. Or, a hacker could be working in collusion with an insider. Or, a government could force the multisig third party to act a certain way…
- The keys could be copied at time of creation. In some cases, the user’s two keys are sent to him or her by email. How hard would it be for a hacker to access that email?
- Multisig configurations in which 2-of-3 keys are held by the user do not protect the user from coercion (sign this transaction with both of your keys or I’ll…).
- As with any wallet software, you are trusting it has no “back door” for a hacker to use. The hacker would have to be either in collaboration with the software provider, or have created a convincing replica that he or she gets you to download instead.
We can’t go through life fearing every eventuality. No system is completely infallible, and all of the above situations are extremely unlikely. But they are possible. And the Bitfinex hack has shown us that multisig isn’t always enough.
Uncertainty is never good for any ecosystem, especially when the economic risk is so high. But knowledge is power, and identifying weaknesses does lead to additional strength. Multisig is a cool feature. It’s obviously not perfect, but as with most code, it can be tweaked and worked on to become even stronger.
The incentive to steal is as old as time itself. The incentive to protect ourselves from that theft has given birth to today’s technology, society, political systems and way of life. The bitcoin community continues to pour considerable time and effort into innovating, improving and staying one step ahead of the bad guys. And they will continue to do so because they have more to gain than the bad guys. After all, safe bitcoin deposits that are also easy to transact with, that will extend the use of the cryptocurrency and encourage a reform of the way we handle value – that’s a pretty good incentive.
(This post was originally published on LinkedIn.)