How does the bitcoin source code define its 21 million cap?
Many of bitcoin’s staunchest critics have expressed doubt about its 21 million cap, but perhaps the most mindless criticism relates…,
Three can keep a secret, if two of them are dead. — Benjamin Franklin
No matter how much software and hardware or how many physical and legal barriers a company has built, security is ultimately provided by communication among its people. Employees reviewing each other’s code make applications secure. Guards checking in on each other with cameras and walkie-talkies can create a secure perimeter. The bodily security of a dive group depends on each diver checking their own and their partners’ equipment.
Companies that protect bitcoin are groups of people protecting a secret, and there are different challenges for groups of people protecting a secret than there are for a single individual HODLer. Both companies and individuals may value properties such as multisig, cold-storage, air-gaps, open-source, etc., but companies have to contend with additional challenges that individuals don’t:
Multisig does mitigate some of these problems, but not completely. Individual keys within a multisig quorum must still be protected. Nested multisig setups are possible, but incur great cost, complexity, and publicly reveal too much about how keys and signers are related when used to sign transactions.
A single BIP39 seed phrase, hardware wallet, or any other scenario which gives, even temporarily, a single employee full knowledge of the company’s private key without requiring the collaboration and consent of other employees is a security hole.
At Unchained Capital, we practice Collaborative Custody. We protect one of the keys in a multisig quorum, with the others held by our customers and partners. We needed a tool to bridge a gap we perceived in private key management and operations for our company. We believe other organizations protecting private keys may face similar challenges, whether they also use multisig or not.
Hermit is an open-source, sharded, air-gapped wallet designed to help groups of people safely manage and use bitcoin private keys. It has two main features:
On their own, neither feature is new, but the combination of both is unique and provides organizations with strong security (the air-gap) along with a simpler way for members to collaboratively manage signing responsibilities (the sharding).
These short videos demonstrate Hermit’s main workflows:
These videos were recorded on an unmodified commercial laptop, but we recommend running Hermit on air-gapped hardware.
You can view the code here: https://github.com/unchained-capital/hermit
Shamir Secret Sharing Scheme (SSSS) is employed in one form or another at many bitcoin businesses to split a single private key into M-of-N shards. Shamir is not a substitute for multisig; it is additive security for any private key, because M of these N shards must be co-located to reconstitute the private key.
Consider the following example of the fictional company “Bitbase,” which uses SSSS to protect a private key in cold-storage. Bitbase wants either their CEO (Arthur Armstrong), or CFO to be required in order to sign transactions from their cold storage. Executives are busy people who travel a lot, so Bitbase needs some other employees to be able to step in to sign in case one of the executives is unavailable. These other employees should NOT be able to sign on their own without either executive.
To achieve this, Bitbase uses a 3-of-6 Shamir sharding scheme. The CEO has 2 shards, the CFO 2 shards, and 2 other employees each have a shard. This setup works, but it’s clunky and difficult to scale. Different employees deserve different amounts of trust, but traditional Shamir sharding only provides one level of shards and all shards are equal in weight. As a result, the executives end up with 2 shards each to give them more signing power in this scheme.
Sign up to be notified when we publish new blog articles.
What’s needed is a way to explicitly apportion different amounts of trust through shards by letting different shards be “worth” more or less when reconstructing a secret.
SLIP-0039 gives us this ability: we can split a single private key in a way which precisely apportions trust the way we need.
SLIP-0039 uses the word family to describe the two-level hierarchy of shards and groups of shards it creates from a given private key.
At the shard level, SLIP-0039 is just like traditional Shamir sharding. M of N shards must be co-located in order to reveal their data.
The difference is that these shards are organized into some number of groups. The number of shards N and the number of required shards M can be different for each group of shards. Given P groups, Q of them must have sufficient shards co-located in order to finally reveal the original private key for the family. With Hermit, Bitbase can create a group for each executive and make it 1-of-1 shards, letting the executives sign together without coordinating with the employees, and only requiring them to hold a single shard with a unique password- Hermit encrypts shards by default. That said, the executive can still coordinate with 2-of-2 employees should the other executive be travelling. In this new scheme, the executives hold a shard worth ½ of a private key, and each employee holds a shard worth ¼ of a private key. Trust among employees has been allocated appropriately for Bitbase.
This flexibility allows for organizations to build sharding schemes that meet their exact organizational needs. Group 3 could be extended to M employees and require 2-of-M to sign, additional groups could be added, and the family structure could be changed to require M groups of N groups. Bitbase could even build an entirely different shard family to require different divisions of employees to collaborate with each other and not with the executives or employees in our example above.
Hermit also provides organizations some flexibility around rotation or replacement of trusted employees. With Hermit, if a signer in the team needs to be rotated out, and the organization trusts that that signer did not previously exfiltrate their own shard, it may be easiest to simply transfer that signer’s shard to a new employee (remembering to encrypt the shard with a new password). If the old signer is no longer trusted or unable to decrypt their shard, then the organization can create a completely new shard family from the existing key. This allows signers to each get new shards without any external consequences, such as having to change addresses or sign bitcoin transactions. Like any wallet, the absolute most secure thing to do when signers change is to swap out the key with a new one, but many organizations may find these approaches reasonable.
Hermit avoids implementing its own cryptography in favor of using trusted open-source libraries wherever possible. The SLIP-0039 standard and corresponding libraries are very new. For this reason, Hermit is currently considered alpha software.
The SLIP-0039 standard was conceived by SatoshiLabs, Christopher Allen, Mark Friedenbach, and several others. SatoshiLabs has published an open-source reference implementation in Python. C libraries have been published by Justin Lin at HTC and by Unchained Capital’s own Chris Howe.
SatoshiLabs recently announced Trezor Model T SLIP-0039 compatibility, and HTC plans to include SLIP-0039 functionality in their upcoming Exodus mobile phone, to be released in Q1 of 2020.
Unchained Capital believes SLIP-0039 is an improvement over traditional Shamir shares, yet we believe it needs further improvement and review. We are working closely with Christopher Allen and the Blockchain Commons on a Bitcoin Improvement Proposal (BIP) that will include the following:
We believe a standardized approach to Shamir sharding will improve security for all bitcoiners. We invite you to check out Hermit, SLIP-0039, and follow our work on supporting this new standard.
Many of bitcoin’s staunchest critics have expressed doubt about its 21 million cap, but perhaps the most mindless criticism relates…Ted Stevenot, Stephen Hall
When Satoshi Nakamoto created bitcoin, he established in its code a fixed number of bitcoin that will ever exist. Since…Ted Stevenot
Originally published in Parker’s dedicated Gradually, Then Suddenly publication. Bitcoin is often described as a hedge, or more specifically, a…Parker Lewis