Multi-Sig Models That Work
A visual language for reasoning about multi-sig Bitcoin security.
It used to be so simple, didn’t it? One coin, one key, one user. Not too many ways to get that wrong. Except, you know, when somebody else suddenly got hold of the key. That sucked.
Now it’s gotten so complicated. Seems like everybody decided that maybe one key just isn’t enough after all. “We want multi-sig! It will save us!” cried the masses. “Good thing we built that 3 years ago,” replied Gavin. “How about you try actually using it?”
All kidding aside, multi-sig (via P2SH) does open a dramatically new set of possibilities for security and custody models for Bitcoin. But with multiple keys, apps, users, and signing oracles, there is quite the combinatorial explosion of ways to organize the keys and participants. And to complicate matters further, multi-sig models may incorporate arbitrary off-blockchain policies regarding who is allowed to do what, when, on behalf of whom.
How do we reason about the security characteristics of the various ways to implement multi-sig security? Given a certain end goal, how do we determine the best approach out of all the possibilities? The first step is being able to clearly understand the components and relationships that make up the system.
At BitGo, we operate a multi-sig platform API, allowing companies and individuals to build Bitcoin security solutions that meet the needs of their applications. In working with various partners implementing applications on our platform, we’ve had to address the above questions. In order to talk about different approaches, we’ve come up with a visual language for expressing multi-sig models, that we think is broadly useful.
We like to represent multi-sig setups as directed graphs:
- Nodes represent various entities: the bitcoin, the keys, users, oracles, exchanges, etc.
- An arrow from A to B means that A has some measure of control over B.
- An arrow without annotation represents complete control.
- An arrow with annotation represents partial control, subject to policy.
Okay, enough jibber-jabber, let’s get to some pictures.
The above diagram is about the simplest model possible. An amount of bitcoin is controlled by a single key, which is controlled by a single user, in other words, classic single-key security. This model can only get simpler if the user loses his key or gets hit by a bus. Let’s see something a bit more interesting.
Figure B represents bitcoin controlled by 2 keys, both required to transact. For example, a single user maintains one key on a laptop, and a second key on a phone or hardware wallet. The immediate benefit of this model is that there is no longer a single point of failure except for the user himself. Note: The 2-of-2 configuration is not directly specified in the diagram, but could be annotated.
Figure C again represents a 2-of-2 setup, but this time, the keys are controlled by separate users. In order to transact, both users must apply signatures with their respective keys. A 2-of-2 wallet established using software such as Copay would follow this model. Excercise for the reader: What happens if User 2 has a tragic kayaking accident in Guatemala?
Figure D shows the classic 2-of-3 trustless escrow model enabled by multi-sig, using a third-party as arbitrator. The two users (seller & buyer, typically) can release funds on their own if all goes smoothly with a transaction. If there is a dispute, then the arbitrator can step in to make a judgment, and can transact along with either the buyer or the seller. Importantly, the arbitrator does not have to be trusted with the funds themselves! This model is used by apps such as HashTrust, BitRated and OpenBazaar. It is a model that is not used often today, but is lying in wait for a truly successful peer-to-peer marketplace to emerge.
Figure E is a single-user 2-of-3 model which uses a co-signing service often called an “oracle” or alternatively, a co-signing service. The user controls 2 keys, one of which is kept completely offline. By controlling 2 keys, only the user always has full ability to transact, and thus complete custody of the bitcoin. The job of the oracle is to determine under what circumstances it should or should not apply its co-signature to a transaction. The oracle can apply arbitrary authorization requirements on the user, and enforce spending policies which the user has pre-configured. Note: This model was pioneered by BitGo and is still used today in its multi-sig web wallet. We think it’s pretty good.
Figure F is again a 2-of-3 model using a signing oracle, but adds multiple users, as well as a custodian who holds a cold backup key. The custodian might be a third individual within the same company as the other two users, or might be an outside custodian which contractually agrees to release the key to the user or organization under a certain set of circumstances (such as loss of key 2).
The two users actually share only a single key, meaning neither can transact independently, and they cannot even transact together, without involving the signing oracle. By arranging keys this way, the oracle can enforce rules that require only a request from a single user, or can require that both users approve of a given transaction before agreeing to co-sign. Another advantage is that users may be added to the wallet at any time, since no new keys need to be provisioned. Note: This diagram represents the basic architecture of BitGo’s multi-user wallets.
Figure G represents one way to implement a segregated on-blockchain account at a Bitcoin exchange. The exchange (E) has an end-user (U). The user does not directly control a key — the exchange controls it on the user’s behalf. The oracle’s policies can be set such that the exchange’s automated systems can move funds out of the segregated wallet without the end-user’s approval, but only to a designated white-listed settlement wallet. Additional rules involving multiple humans can protect the funds in the settlement wallet.
In order to make a withdrawal, the user requests it through the exchange’s web site. The user does not have a key, but the exchange crafts a half-signed transaction on behalf of the user, and submits it as the user using OAuth credentials for the user, who has a direct identity relationship with the signing oracle. Importantly, the user must also provide a 2-step verification code in order for the oracle to accept the request. Because the withdrawal list is not on the target address white-list, the exchange must also submit an approval as itself to the oracle.
This model provides a great number of benefits for both the exchange and its users:
- The user is not in possession of a key, and therefore cannot lose it.
- The exchange can perform automated settlement in a secure way.
- Withdrawals require user involvement via 2FA direct to the oracle.
- The user can see all his/her funds segregated on the blockchain, and conversely, the exchange can provide assurance of 100% reserve.
- The user can recover funds with help from the oracle and the custodian in the event the exchange disappears or loses its keys.
- The exchange getting hacked cannot result in an immediate total loss of all customer funds.
- The oracle can put a temporary freeze on signing any transaction from the exchange.
- No single party holds enough keys to transact independently. No entity has complete custody except for the blockchain itself.
- Security through obscurity. No attacker will figure out all those arrows. Ha ha, kidding — just seeing if you’re still paying attention.
As I mentioned earlier, the ways to combine the various relevant pieces into coherent security models only expand from here. That doesn’t mean that most of them are good ideas, just that there are a lot of them. It takes a good deal of thought to fully understand the security implications of any one of these models, particularly as they get more complex. Did you notice that none of these models even involved more than 3 keys?
At BitGo, we’ll continue to explore the space to find useful new models. And we hope that the Bitcoin community finds this way of visualizing multi-sig security enlightening and useful while trying to separate the wheat from the chaff. And by the way, if you really made it this far, and it all made sense (or you found a mistake!), maybe you ought to think about coming to work with us.
Ben Davenport is co-founder and Chief Product Officer at BitGo.
Diagrams were produced with draw.io
