Last week, we unpacked the nature of Bitcoin, breaking away from the many analogies and mental models that have appeared through the years as everyone tries to make sense of Bitcoin and simplify ways of explaining it.
We did so in order to look at the fundamentals of Bitcoin. In particular, looking at how the properties of Bitcoin are achieved in a network composed of nothing more than a series of nodes communicating with one another and adhering to a very particular set of rules.
In the same way that breaking away from analogies is important in order to understand the nature of Bitcoin, we will attempt to do the same for the nature of custody, examining what it means to “hold” bitcoin. Doing so will allow us to take a more nuanced view of some of the legal questions that surround this topic.
We will begin by understanding the information spaces from last week, and how they apply in the context of custody. Then we will look at a system like Knox, first simplifying it to its essentials. Lastly, we will see how such a system manifests, and what it is actually doing.
Something Old, Something New
Since time immemorial, people have:
- Coveted physical objects
- Noticed that some physical objects are more scarce than others
- Ascribed value to the scarce physical objects that others covet
- Used those physical objects as stores of value
- Lost those physical objects
- Stolen others’ physical objects
- Been coerced through violence to part with their physical objects
- Had others safe-keep their physical objects
As the past decade has definitively proven, an asset need not be physical for people to derive value from it. Being scarce and simultaneously coveted by others is enough, physical or not. For reasons that have been discussed at length elsewhere, this makes Bitcoin the ultimate store of value.
That said, we highlighted physical above for good reason. Since societies have been dealing in scarce and widely-coveted (and thus valuable) physical assets for so long, we have also accrued accompanying legal codifications and case law surrounding their safe-keeping. Drawing from this existing body of work may prove a useful first step when thinking through policy surrounding the safe-keeping of Bitcoin.
Ultimately, we should strive for a world where the nuances of Bitcoin are well understood, a full body of case law exists, and its nature as speech is fully appreciated. The immediate goal however will be to quickly converge on policy directions that allow the ecosystem to progress unstifled, in a clear regulatory environment. With that in mind, in the context of holding Bitcoin, there is a lot of progress that can be made.
Information Spaces
In The Nature of Bitcoin, we exposed two distinct information spaces. Briefly these are:
1. Spendable Outputs — The UTXO Information Space
A set which in the aggregate sums to a BTC value equal to all BTC currently in existence as a result of Bitcoin’s issuance schedule. A collection of outputs whose ultimate ancestral inputs were coinbase transactions representing mining rewards, the source of all BTC, or the coinbase transactions themselves. To spend any such UTXO, an entity needs to prove signing authority over the address to which it is associated, by signing with the corresponding private key.
2. The Space of Private Keys
There is also the space of public keys and addresses. These can be generated from the space of private keys, but we’ll focus on the private keys throughout.
The two spaces relate to one another per the above: As UTXOs are spent, and their outputs are associated with some address A, the new spending rights accrue to those who can sign with the private key(s) associated with A.
These two information spaces correspond to the two major functions of an entity like Knox:
1. Act as a computational service provider
Apply signatures (information, text) with secret values (information, text) propagating the results of the computation (information, speech)
2. Act as a storage service provider
Hold onto secrets (information, text), to make 1. possible
Looking at this picture from the fundamentals, the true nature and activities of a custodian are much clearer. A Bitcoin custodian does not in effect actually hold or spend Bitcoin. Those activities are maintained by the distributed Bitcoin protocol to which a custodian speaks.
It does however store and compute, which looks much more like a cloud service provider with extremely constrained storage and compute capabilities.
Physical Manifestation
We will focus on the second function for the remainder of this piece– keeping information. A private key is a piece of digital information. That just means it’s a value that can be perfectly described with a sequence of digits.
That sequence of digits can be:
- Written down
- Stored as a file
- Memorized
If you write the sequence on a piece of paper, you have made this value manifest physically. The sequence can be trivially copied. If it represents a secret, a good safekeeper is one that will not divulge the sequence. A safekeeper that renders a physical manifestation might lock the only known version of the sequence away, acting as a warehousing agent.
In the Flesh
Next, we will speak to the underlying reality of a system like ours. Being who we are, we will of course look at how Knox engages the activities described above.
But first, some simplifications. At Knox, we employ extreme levels of segregation and redundancy to achieve our security and privacy goals. Many of these are not relevant to explaining the nature of Bitcoin custody, and so we’ll scrub these away first to get to a cleaner view.
Anyone who has seen our distributed global infrastructure in full will certainly appreciate the simplification, and for others we’ll be sure to come back and explain various parts of the system in their full glory.
A Brief Primer on Entropy and Prerequisite Knowledge
Remember the private key, the sequence of digits. A good private key is one that nobody else can guess. There exist a range of possible values in an enormous space of options.
To simplify matters: Your job is to pick one of the possibilities in a way that makes it unlikely someone else will pick the same. The space of possibilities is so large that if you can manage to pick one value from it in such a way that you’re equally likely to get any of the possibilities, you have made a good random pick. It is extremely unlikely that someone else drawing from the same space will happen upon the same value as you.
When we use the word entropy below, we are loosely referring to a random number picked out of some space of possibilities. Given a random number chosen within a bounded range, we can generate a private key. When we speak about entropy or a random number, consider it a reference to some value that was picked as described above.
We will proceed assuming that readers have some familiarity with public key cryptography, HD wallets / BIP32 trees, multi-signatures, and secret sharing. If you do not, you should still be able to clear the following simplifications, as they successively wash most of this complexity away.
1. Customer Account Segregation
We take account segregation very seriously. When we use the term segregated, we are referring to segregation at the level of the entropy used to generate that account. This is important to understand because it is possible to abuse a BIP32 tree, handing off subtrees to distinct customers, and calling these segregated accounts. While that technique is not commingling addresses, it is not appropriate to refer to it as a segregated account.
This may have legal ramifications down the road. As we’ll see momentarily, the entropy generated and employed for an account can be rendered in a physical form. Anyone who has ever recorded a mnemonic for themselves has performed such an operation.
As an aside, this is a good question to ask of any system. Don’t let someone fool you into falsely conflating address commingling and account segregation by pretending they are the same thing. From the perspective of the observer of the sub-tree, their account is in fact separated from any other. However, as we’ll come to understand, the account is derived from a random number, and reusing that same number can be dangerous — should someone come to learn that one number, multiple accounts would be compromised. To avoid this, we employ accounts that are truly segregated: they do not share any information with any other.
We will from now on speak as if there is only one account in the system. It is easy to generalize from there and imagine many different accounts, but we think it important to note that not only do we not commingle addresses, we operate true segregated accounts, with no root entropy shared between them.
Simplification 1
There is only one account represented as one random number.
2. Single Signature
Our accounts are all multi-signature. With the above point in mind, this means that not only is a customer account segregated at the entropy level from all others, there are multiple distinct sources of entropy used to generate it. However, this makes describing the private and public key spaces more difficult, so we’ll back off and speak about the single-signature case. We of course do not condone single-signature Bitcoin systems.
As an aside, this is another good question to ask of any system. Holding large sums of Bitcoin in a single-signature pattern is deeply irresponsible. Never do it or allow others to do it to you.
Simplification 2
Assume that any address has exactly one private key associated to it.
3. No HD Wallets / BIP32 trees
At Knox, we make heavy use of HD wallets. When a customer sees a multi-signature address, it is the case that behind the scenes:
- The address was derived via multiple public keys (Multi-sig)
- Each such public key was derived from an HD tree of public keys (Descendents of an xpub)
- Each such tree is segregated from every other account, at the entropy level
For the sake of simplicity, we will forget about HD trees.
Simplification 3
Every address has a single private key and single random number associated to it.
4. Storage of Entropy
Entropy can be written down and locked away.
We engage a secret sharing scheme which splits this information in many chunks in a very particular way, which is then encrypted and vaulted. This adds to the redundancy and safety of our system, but only complicates the picture.
Simplification 4
Assume the entropy is recorded in one place and left unencrypted. It can then be locked in one place.
The Final Picture
We have now produced a very simple picture we can use to describe how the two activities Knox engages manifest physically. Let’s assume that there is only one account with one address.
The full picture for the information involved is then:
The Activities in Physical Space
With this simplified picture, we can turn back to how the activities of storing and computing are achieved.
1. Storing (Vaulting keys)
The custodian in this case is acting as a warehousing agent. It produces a physical manifestation of the random number, and locks it away.
2. Computing (Applying Signatures)
The private key must be used to sign a message that can then be communicated to the Bitcoin network. At Knox, we take collusion resistance seriously, so we can’t just pull the random number out of a vault to use it. From an internal theft standpoint, that is far too dangerous.
The simplified picture is that we employ a special computer, called a Hardware Security Module, or HSM for short. This computer has its own storage and compute capacity.
In this simplified picture, our HSMs do a few things very well:
- Store a private key
- Prevent anyone from observing the private key, even with physical access
- Use the private key to sign messages
- Prevent someone, even with physical access, from asking for a signature that was not asked for by a customer
At the end of the day however, this all boils down to:
1. Vaulting a random number (Physical storage)
2. Vaulting an HSM with which we can still electronically communicate (Physical storage, Computation)
3. Speaking to the Bitcoin network (Speech)
The Nature of Custody
We hope this was an informative view into the nature of custody, from the fundamentals. While our system is in reality far more complex than the final simplified view, the underlying activities remain the same.
We vault,
We compute,
We speak.
