[continued from part V]

Design sketch

Here is an overview of an approach that combines private proof-of-assets to trusted examiner with crowd-sourced verification of the ledger. The custodian publishes the ledger as a series of entries, one per customer:

<Pseudonym, balance commitment, range proof>

At a high level:

• Pseudonyms are unique customer IDs generated for this proof and never reused in the future.
• Balances are represented as cryptographic commitments, which hide the actual value from public eyes but allow selective disclosure
• Range proofs are non-interactive zero-knowledge proofs  demonstrating that the committed balance lies in a sane interval, such as zero to 21 million bitcoins.

Pseudonyms must be generated deterministically such that the customer can verify it can only be referring to their account. Generating a random value and emailing that to the customer will not work; if Alice and Bob have the same balance, the custodian could fool both into believing a single entry represents their balance. Likewise a pseudonym can not be derived from an opaque internal identifier only meaningful to the custodian, such as internal database IDs assigned to each customer. While database keys must be unique, customers have no visibility into that mapping and can not detect if the custodian is cheating by assigning the same ID to multiple accounts. One option that avoids these pitfalls is to compute this identifier as a cryptographic commitment to the email address. This protects the email address from public visibility while allowing selective disclosure to that customer when desired.

Speaking of commitments, a similar construction is used for representing account balances. Here the ideal commitment scheme allows doing basic arithmetic on committed values. Specifically: given commitments to two unknown numbers, we want to compute a commitment representing their— still unknown—  sum. That would be very handy in an accounting context: given commitments of individual customer balances, the custodian would be able to produce a new commitment and show that it represents the total balance across all customers. (This is similar to the notion of homomorphic encryption. For example the Paillier public-key encryption algorithm allows working with encrypted data. Given Paillier ciphertexts of two unknown numbers, anyone can craft the Paillier encryption of their sum.) Multiple options from the literature fit the bill here, going back at least two decades including Pedersen and Fujisaki-Okamoto commitment schemes.

Avoiding integer overflows, the cryptography edition

There is still a catch: regardless of the commitment scheme chosen, they all operate in modular arithmetic. There is an upper bound to the values that can be represented, even if that limit happens to be a very large number with hundreds of digits. If we try to use the additive property in a situation where the sum exceeds that limit, the result will overflow and return incorrect results— the cryptographic equivalent of an integer overflow vulnerability. These commitments that act like negative numbers. When combined valid commitments of real accounts, they will end up subtracting from the total balances.

Left unchecked, this allows custodians to cheat. It’s no consolation that such numbers will not occur naturally for real account balances: a dishonest prover can fabricate bogus ledger entries with negative balances. Since the full list of customers is not publicly known, no one will notice the spurious accounts. The imaginary customers will not show up to challenge their misrepresented balance. Meanwhile the negative values reduce the total perceived liability of the custodian because they subtract from total balances expected when summing up the commitments.

This is where the last element of the entry comes in. A range proof (such as Boudot’s result from 2000 using FO commitments) demonstrates that the committed value belongs in a sane interval, without revealing anything more about it. Such range proofs are public: it does not require any secret material to verify. Requiring positive balances reduces any incentive for the custodian to invent bogus customers. Doing so can only inflate the liabilities side of the ledger and require more cryptocurrency on assets side to pass the solvency test. Incidentally, there is a low-tech alternative to range proofs by relaxing the privacy constraint: the custodian can open every commitment for the third-party doing the examination. While the examiner still can’t tell if alice@example.com behind the pseudonym is a real customer, they can at least confirm her alleged balance is positive.

Verification

To prove the integrity of the ledger, commitments in each entry are opened privately for the specific customer associated with that entry. This involves making available to that customer all the random values used in the construction of the commitment. That could communicated via email or displayed on a web page after the customer logs into the custodian website. Armed with this information, every customer:

1. Verify their own balance is represented accurately in the ledger.
2. Rest assured that the ledger entry containing their balance is exclusive to their account. It can not be reused for other customers, because the pseudonym is uniquely tied to identity.
3. Confirm that all entries in the ledger represent positive balances. While other customer balances are hidden by commitments, the associated range proofs are publicly verifiable.
4. Calculate a commitment to total balances across the customer base

That last property achieves consensus around a single committed value for liabilities that everyone agrees on— the custodian, all customers and any independent examiner hired by the custodian. Next the custodian verifiably opens that single commitment for the benefit of the examiner, revealing total liabilities. (Alternatively, the custodian can open it publicly if there is no privacy concern about disclosing total assets under management.)

Next the custodian executes the usual proof of assets on blockchain, by demonstrating knowledge of private keys corresponding to claimed blockchain addresses. This demonstration is not public. Only the trusted examiner gets visibility into addresses. This is where trust in the independent examiner enters the picture. The proof is only convincing to the extent that the examiner is honest and competent. Honest, in that they will not make false assertions if the accounting demonstrates a discrepancy. Competent, in that they are familiar with sound methodologies for proving control over keys. (For example, they will insist on influencing challenge messages to be signed, to avoid being fooled by recycled signatures on ancient messages.) Assuming the proof is carried out to the satisfaction of the examiner, they can produce an attestation to the effect that at a specific point in time custodian assets were approximately equal to liabilities implied in the ledger. Crucially the examiner can look beyond numbers alone and assess the design of the cryptocurrency system. Does it have appropriate physical and logical access controls? Is there enough redundancy in backups? Are there key-person risks where only person can execute critical tasks— looking at you QuadrigaCX?

Summary

To recap: liabilities are verified in a distributed, public fashion with every customer able to check their own balance. This requires no external trust assumptions. Assets on the other hand are verified privately by a trusted third-party, who is given full visibility into distribution of those assets on the blockchain. Unlike BIP127 this approach covers both assets and liabilities. It does not require public disclosure of addresses, and by implication, total assets under custody. Also unlike the Coinfloor approach, individual customer balances are not revealed, not even pseudonymously or to an independent examiner. It is not limited to P2PKH addresses; arbitrary spend scripts can be accommodated. Finally it permits going beyond simple control of addresses and demonstrating higher redundancy. For example with M-of-N multisig, instead of proving control over the minimum quorum of M keys, the custodian can be held to a higher standard and required to prove possession of all N. There is still an element of trust involved in the independent examiner, but less trust required in the custodian for performing the proof. Unlike opaque audits where the examiner can not independently verify ledger integrity, publishing the ledger turns every customer into a potential examiner.

It is easy to accommodate additional requirements with changes to the protocol. For example, if we are willing to place additional trust in the independent examiner, they can also be tasked with reviewing bank statements to check presence of fiat assets. They can reviews internal policies and procedures used by the custodian, looking for red-flags such as key person risk that appears to have plagued QuadrigaCX. We can move in the other direction, reducing trust in the examiner while giving up some privacy for the custodian. Suppose we insist that the exchange publicly open the commitment to its total liabilities and publish the proof of control over keys. That would disclose all blockchain addresses used by the custodian but in return take the examiner out of the trust equation for digital assets.

CP