An earlier post looked at limitations inherent in a do-it-yourself audit of cryptocurrency custodians, such as the recent Proof of Keys event. Left unanswered is what better solutions exist for achieving the same objective. It turns out there is a wide-range of options here, ranging from very low-tech, traditional solutions relying on trusted third-parties to sophisticated cryptographic protocols relying on customers to individually verify their balances.
To better appreciate the challenge involved in proving control of funds, it is instructive to tackle a simplified scenario first before looking at more realistic custody scenarios. Suppose Alice is storing bitcoin on behalf of Bob. Bob requires periodic assurance that the funds are still there. In other words, that Alice did not suffer a security breach, abscond with the funds or start an unauthorized lending business on the side, using the funds under management as operating capital. One would expect that if there is any advantage to using a public blockchain, this would be it: since the blockchain is a public, transparent ledger of all balances in the ecosystem, it ought to be possible for Alice to verify her own balance. That intuition is accurate but there are a number of qualifications and pitfalls.
First, Alice must reserve dedicated addresses for Bob and share those addresses with Bob. It does not have to be a single address; Bob’s funds can be spread across multiple Bitcoin addresses but they must never be commingled with other funds such as Alice’s own money. Armed with knowledge of the addresses, Bob can periodically check blockchain state to verify those addresses still have the expected balance, with the understanding that the whole balance belongs to him.
But this is only one piece of the puzzle. Presumably Bob seeks assurance over time that Alice is still in full control of those addresses. That is, if Bob were to ask for his funds back, Alice would be able to execute a transfer. Since control of funds in cryptocurrency boils down to control of cryptographic keys, this is a question of key management: does Alice still have control over the secret keys corresponding to those addresses? (Note this is a decidedly different from proving that Alice would execute such a transfer if asked; it is only proving capability. In a custodial arrangement, Alice can always choose to hold funds hostage. That is a contractual risk Bob is accepting, outside the purview of blockchain rules.) Again there are different ways for Alice to provide this assurance.
Naive solution with test transactions
One obvious solution is to conduct a round-trip transaction for a nominal amount. For each address used, Alice sends a tiny small of assets in custody to an address controlled by Bob and Bob returns them back immediately to the same address. Completing that two-way exchange creates a persuasive that Alice is in possession of private keys.
While this naive approach provides solid proof of solvency, it has significant limitations. It is wildly inefficient; blockchain transfers incur transaction fees and compete for scarce block space. Bob is stuck with handling bitcoin, even if temporarily and for small amounts— the very obligation he hoped to outsource to Alice in the first place. The pattern of round-trips visible on the blockchain undermines the privacy of participants, by linking their addresses over recurring transactions. Finally a single round-trip can not establish redundancy of keys used in multi-signature addresses. Recall that the multisig feature in Bitcoin allows using a quorum of keys to control funds. Commonly designated as M-of-N, the designation stands for having a total of N different keys, of which any subset M are sufficient to authorize transactions. This creates a complication for proofs: signing a transaction requires only M keys and therefore can not prove that the signer had access to all N keys unless M=N. The distinction matters, because one of the major benefits of multisig is redundancy. For example in 2-of-5 arrangement, the custodian can lose access to three keys and still retain control of funds. Such redundancy is highly desirable in custody scenarios for additional peace of mind of the customer, and so is being able to demonstrate control over all keys. Using the naive approach would introduce even greater inefficiency, by repeating the transaction with different subsets of keys until all N make an appearance on the blockchain.
Refinements with cryptographic protocols
A better approach involves directly proving possession of private keys. Again this can be done with varying degrees of sophistication. In the simplest case, Alice signs a mutually-agreed on message with every private-key for every address. (Note the message must be generated carefully such that neither side can 100% control its contents or predict the outcome. Otherwise Alice can reuse ancient signatures from the past as current proof, or Bob can use the opportunity to sign a valid bitcoin transactions that takes away the funds.) It also means Alice has to also disclose the constituent public-keys that make up each address. Recall that the Bitcoin address is constructed as a one-way hash of keys or complex scripts containing keys; without knowledge of that original construction, Bob can not confirm the mapping between public-keys and bitcoin addresses associated with his funds.
One advantage of this approach is that the proof takes place entirely between Alice and Bob; there is no publicly visible trace on the blockchain, no transaction fees or other overhead that would limit how frequently it can be performed.
Cryptographic techniques exist for further refining the idea. For example, it can be made more efficient by using a single signature to prove possession of multiple ECDSA keys at once. This is done by synthesizing a single public-key as the linear combination of multiple keys— although such protocols are not compatible with commonly available cryptographic hardware. Or going in the direction of increased deniability, Alice can use interactive zero-knowledge proofs instead of a signature to prove that she has control of specific keys, without giving Bob any record that he could use to convince someone else that Alice controls those keys.
Scaling this out to multiple customers creates additional pitfalls. For example, if Alice has the same arrangement with both Bob and Carol for custodying funds, there is a new way to cheat the proof. A single address can be used to convince both Bob and Carol that their money is still under the control of the custodian, even though the funds are being double-counted towards both customers. (Especially when using approach #2 above, which creates no visible traces on the blockchain. Using #1 would alert another customer that an address allegedly reserved for their exclusive use is appearing in transactions they did not authorize.) A simple solution here is for Bob and Carol to require that their dedicated addresses always start out with zero balance and only count funds they themselves deposit to that address as part of their balance. In other words, Alice is not allowed to shuffle funds by herself and declare a pre-loaded address as reserved for Bob.
If the scenario described above could be scaled indefinitely from Bob & Carol to encompass thousands of customer, the proof of funds protocol could likewise be scaled linearly without issues. The challenge is that not all cryptocurrency storage scenarios can leverage unique addresses. This will be the subject of the next post.