QuadrigaCX and the case for regulation

[Full disclosure: this blogger was formerly CSO for a regulated cryptocurrency exchange. All opinions expressed are personal.]

After QuadrigaCX

Two lines of argument predictably follow in the aftermath of any cryptocurrency business failure. First is second-guessing by pundits about their favored silver-bullet technology that could have saved the failed venture— if only they implemented multisig/hardware wallets/Lightning or reformatted all webpages to Comic Sans, this unfortunate situation would not have occurred. Second involves increased calls for regulating cryptocurrency. The aftermath of Canadian exchange QuadrigaCX is following that script so far. Quadriga has entered into bankruptcy protection, with $190M USD in customer assets allegedly stuck in their cold wallet, because the only person with access to that system has unexpectedly passed away. 

Before taking up the question of what type of regulation would have helped, there is a more fundamental question about objectives. What outcomes are we trying to achieve with regulatory oversight? Or stated in the negative, what are we trying to avoid? There are at least three compelling lines of argument in favor of regulating some— not necessarily all— institutions handling digital assets:

1. Consumer protection: Simply put, customers do not want to lose money to security breaches or fraud occurring at cryptocurrency businesses they depend on
2. Stemming negative externalities: Cryptocurrency businesses must not create new avenues for criminal activity such as money laundering while the rest of the financial industry is working to eliminate the same activity in other contexts
3. Market integrity: Pricing of digital assets must reflect their fair value assigned by the market as closely as possible, not artificially manipulated by participants with privileged access.

I. Consumer protection

This one is a no-brainer: when people entrust their money to a custodian, they expect to be able to get those funds back. Quadriga debacle represents only one possible story arc culminating in grief for customers. If their court filings are taken at face value, this incident stemmed from an “honest mistake:” the company lacked redundancy around mission-critical operations, relying entirely on exactly one person to fulfill an essential role. To put it more bluntly, it was incompetence. But that is not the only way to lose customer money. Far more common and better publicized in the cryptocurrency world have been losses due to security breaches, where systems holding digital assets were breached by outside actors and funds taken by force. Meanwhile initial coin offerings (ICOs) have been notorious for dishonest behavior by insiders, culminating in so-called exit scams where ICO organizers abscond with the funds raised, without delivering on the project.

There is no bright line between these categories. If a wallet provider is “0wned” because they failed to implement basic security standards, is that routine incompetence or does it rise to the level of gross negligence? In any case, such distinctions do not matter from a consumer perspective. Customer Bob will not feel any better about losing his savings after learning that a sophisticated a North Korean group was behind the theft. (Not entirely hypothetical, since state-sponsored North Korean attackers have been targeting bitcoin businesses, particularly in South Korea. Nor is it surprising that a rogue country would embrace bitcoin to subvert embargoes when it is cut off from the global financial system, in the same way that criminals & dark-markets embraced bitcoin as early adopters.)

That said we need to spell out he limits of what counts as “unreasonable loss.” All investing comes with risk. Notwithstanding the the tulip-bubble perception created by remarkable run-up in prices in 2017, there is no law of nature that bitcoin prices can only increase. As painful a lesson it may have been for investors who jumped on the HODL bandwagon at the wrong time, it is possible to lose money by investing in cryptocurrencies. For the most part, that type of loss can not be pinned on the cryptocurrency brokerage where the buying/selling occurred. Individual agency for investment decisions is a core assumption of free markets. But even then, there are edge-cases. Suppose an exchange decides to list an obscure altcoin whose value later drops to zero because miners abandon it. Does the exchange share in the responsibility for losses? Even if the exchange did not make patently false representations— “buy this asset, it is the next bitcoin”— customers could argue that supporting trading in that asset constitutes an implicit endorsement. For the purposes of this blog post, we will punt these questions to courts for resolution and only focus on losses due to systemic failures in security and reliability.

II. Negative externalities

A very different line of argument in favor of regulatory intervention involves society’s interest in limiting negative externalities. That interest is compelling because the market participants are not directly harmed and may not have any incentive otherwise to correct this behavior. Consider a cryptocurrency exchange favored by criminals to launder profits from illegal activity— BTCe would have been a good example until its 2017 seizure. Arguably others customers of the exchange were not affected adversely from this behavior, at least not in their role as customers per se. After all, criminals in a hurry are not price sensitive: they could be willing to dump their bitcoin at much lower prices or pay a premium to buy bitcoin at higher price than comparable venues where they would not be welcome. That means in a sense everyone involved in that particular trade is better-off: the crooks are happy because they exchanged their ill-gotten gains into a more usable currency, customers who happened to be counter-parties on the other side of that trade are happy because they got a great deal on their bitcoin and the exchange is happy because they collected commissions on the trade.

Society overall however, is not better off. Easy avenues for converting criminal proceeds into usable cash helps incentivize further criminal activity. Economic activity that looks like a win-win for everyone within the confines of a single cryptocurrency exchange can be harmful in the bigger picture when negative externalities are taken into account. To libertarian sensibilities this may represent an overreach by the state to intervene in free-market transactions between fully informed participants: the criminal trying to dump bitcoin and some willing buyer interested in acquiring those assets. But pragmatically speaking, there is significant precedent for regulating financial services based on this premise and the argument that cryptocurrency is somehow exempt from similar considerations does not pass a sanity check.

III. Market integrity

If price discovery is the central function of an exchange, it is important for those price signals to represent true supply and demand. There are many ways the signal can get out of sync from underlying market conditions. For example, in the early days when Chinese exchanges dominated bitcoin trading— before the government got wise to use of cryptocurrency for evading capital controls— there were frequent allegations that self-reported volume on those exchanges was inaccurate. While the subsequent crackdown by PRBC put a damper on volume, even as late as 2018 observers continued to find compelling evidence that leading exchanges were continuing to misrepresent trade volume.

Even in the absence of complicity by exchange operators, financial markets are subject to manipulation attempts by unscrupulous participants. Deliberately employed strategies such as wash-trading and order-spoofing can distort the price signal that emerges. That distorted view poses a challenge both to participants and third-parties. On the one hand, other customers trading on the same venue are getting a bad deal: they could end up paying too much for their cryptocurrency due to artificially induced scarcity or receive less than fair-market value when selling because of inflated supply. On the other hand, when market data is used for pricing other assets—such as derivatives in the underlying asset or shares in a cryptocurrency fund— the noise added to the signal can have far reaching consequences, affecting people who had no relationship with the exchange where the manipulation occurs.

One of the more interesting cases of alleged market manipulation in bitcoin involves neither exchanges or customers. By some accounts, the stablecoin Tether had an outsized influence on price movements for much of 2017 and 2018. Some cryptocurrency businesses can not handle fiat money—their lack of compliance programs have turned these entities into pariahs of the financial system, with no correspondent bank willing to take their business. This is where Tether comes in. A digital asset designed to have one-to-one relationship to US dollar, tether exists on a blockchains and freely moved around, bypassing traditional channels such as wire transfer. Customers who could not directly deposit US dollars into their Bitfinex account could instead purchase tethers in equivalent amount, move those tethers over and place order on the BTC/USDT order book. In isolation the use of tether is not evidence of attempt to fabricate market demand— although it is arguably a lifeline for exchanges with weak/nonexistent compliance programs, since they are precisely the companies who can not establish banking relationship required to receive fiat currency. But suppose tethers could be printed out of thin air, without receiving the requisite US dollars to back the digital assets? Then Tether (the issuing company) could fabricate “demand” for bitcoin since individuals buying bitcoin with tethers (the currency) are effectively working with free money.  The ballooning amount of tethers in circulation, combined with the opacity of the issuing company— Bloomberg referred to it as the $814 Million Mystery— and lack of independent audits have fueled speculation about whether it is operating a fractional reserve.  At least one research paper found that most of the meteoric rise in bitcoin prices could be attributed to tether issuance. That is an outsized amount of influence for a single company: by issuing less than three billion dollars worth of a digital asset— whether or not those were backed by USD deposits as promised— Tether helped propel bitcoin to a peak market capitalization over 100 times that amount. While the Tether story is not over and the presumption of innocence applies, it underlines another argument for regulation: left unchecked, rogue actors can have outsized influence in distorting the operation of digital currency markets.

CP

 

Proof of funds for cryptocurrency custody: getting by with limited trust (part VI)

[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

Proof of funds for cryptocurrency custody: revisiting trust assumptions (part V)

[continued from part IV]

Trust assumptions revisited

Purely cryptographic approaches to proving solvency are constrained by an ambitious dual mandate: achieve full public verifiability and guarantee full privacy for custodian assets. On the one hand, it aims for creating proofs that any one can verify without relying on the word of third parties. On the other hand, it protects the custodian against unnecessary of disclosure proprietary business information such as blockchain addresses or even total assets under management. The first objective is intrinsically incompatible with accommodating fiat balances, while the latter one may not provide as much value as expected.

First consider the nature of the privacy afforded to the custodian: its collection of assets— and by implication total balance— are hidden inside a larger “cover set” of other blockchain addresses chosen during the construction of the proof. Use of zero-knowledge techniques mean the distinction between real vs cover addresses will not be leaked by the proof. But there is no guarantee that outside observers will not be able to distinguish true addresses from the chaff using other signals. Many companies specialize in blockchain analytics: clustering and labeling addresses associated with specific actors and tracing flow of funds. For example, cold-wallet addresses for many exchanges are already well known. The prover could include some these in their cover set, unaware that the addresses have been deanonymized and associated with another actor. While the inclusion of such an address does not invalidate the proof, it provides no privacy benefit. Anyone looking at the proof can immediately eliminate those addresses as belonging to the custodian, leaving a smaller subset for real assets. That problem only gets worse over time: an address may not have been labeled when it was included in the cover set but future work— and new transactions involving that address— can reveal the identity behind it. The anonymity set contracts over time. In fact if Provisions-style approaches were widely deployed, participants may well undermine each other. When the same address appears in multiple proofs from different custodians, it can belong to at most one. For all others, that address can be ruled out as part of the wallet. Similarly, long-term stable addresses used by a custodian would jump out when comparing proofs over time. The cover set may change but real custodian addresses must appear in the proof as long as they carry non-zero balance.

Giving up on blockchain privacy

Another interesting datapoint is the existence of proposed and implemented proof strategies with complete transparency over blockchain addresses. For example a BIP from Blockstream proposes to use “almost-valid” transactions as proof. The custodian creates a single massive transaction consuming all of their valid unspent outputs and one bogus input. The bogus input serves two purposes. By incorporating some fresh information that can not be predicted in advance, it guarantees recency of the proof— since signatures of all the valid inputs must also reference the bogus input, they could not have been precomputed before that last input was known. Second by virtue of being an invalid input, its presence invalidates the entire transaction, preventing its unauthorized broadcast. (Recall that we want to prove control over funds at rest; we do not want to move them in the process.) As far as disclosure goes, this is radical transparency. Not only are all addresses and by implication total assets under custody revealed, the proof also gives away information about the construction of those addresses, such as the set of public-keys behind a multisig script which may never have appeared on the blockchain before.  On the other hand, the proposal makes no attempt to address the liabilities side of the equation. Knowing a custodian can sign for 1000BTC is not helpful without the additional context of how much it was supposed to have in the first place.

Coinfloor

The exchange Coinfloor uses a more comprehensive approach in its Provable Solvency Reports. They publish a pseudonymized version of the internal ledger, listing balances for every customer. These are not cryptographic commitments; actual amounts appear in cleartext. The only piece of information obscured is the identity of the account, which uses hash of API keys. Coinfloor then executes an actual bitcoin transaction moving the total amount on the blockchain. This approach reveals even more information than the Blockstream version. Individual balances are visible to everyone, not just that specific customer who is the only person in a position to verify if it is represented correctly. Pseudonyms help but can not prevent partial leaks. If the exchange is known to have customers with high balances (for example, hedge funds or accredited investors) their balances may stand out since the distribution is highly skewed. For example in the June 2018 report from Coinfloor, just ten customers account for close to 30% of all bitcoin under custody. Luckily the identifiers change over time by incorporating a timestamp in irreversible manner. Consistent identifiers would have provided even less privacy by allowing investors balances to be tracked over time, allowing others to observe which customers are building up or exiting their bitcoin positions.

Finding a middle ground

Merits of these specific proposals aside, there is a clear disconnect between the privacy and trust assumptions of solvency protocols that are deployed and those appearing in the literature. Relying on an independent third-party seems inescapable for two reasons: dealing with fiat currency balances and looking under the hood at the soundness of the overall storage system. (QuadrigaCX was in control of its keys, until one day when it was not not.) On the other hand, ledger verification is best outsourced to customers. They are both ideally positioned to check if their balance is recorded correctly and motivated to do so when their own funds are at stake. Building on this observation, we can explore other design options: proofs that are partially verifiable while still calling on trusted third-parties for specific tasks.

[continued]

CP

Proof of funds for cryptocurrency custody: public verifiability (part IV)

[continued from part III]

Zero-knowledge proofs

Borrowing on a principle from blockchain ideologues that that trusted intermediaries introduce vulnerabilities, we can instead fallback on a purely cryptographic approach to constructing a proof of solvency. The first attempt at this in the literature dates to a paper from CCS 2015 introducing a scheme called Provisions. The authors independently tackle both sides of the accounting book.

• Liabilities are publicly made available as a set of cryptographic commitments, with one commitment for the each customer balance. Commitments are private in the sense that the number is not publicly visible, but it can be selectively disclosed. Each commitment is opened only for the specific customer, for example by emailing them with the information required to verify the committed value. This part effectively crowd-sources verification, by allowing every customer to confirm that their balance is represented accurately. More importantly, the commitment scheme uses a construction that also allows committing to a total balance which is verifiably equal to the sum of individual commitments. That figure represents the total amount of customer claims to cryptocurrency stored by the customer. While the proof implies a public commitment to the sum, that number is not publicly disclosed. As such the amount of assets under custody can remain confidential as a proprietary business metric.
• Proof of assets is done using zero-knowledge proofs, over a cover set that includes the actual custodian addresses as a proper subset. The main contribution of the paper is a provably secure protocol for doing that demonstration without disclosing specific addresses or for that matter total assets. True custodian addresses are obscured among a larger cover set, which could be all addresses on the blockchain if one wanted maximum privacy. The prover uses zero-knowledge proofs over the entire set to demonstrate that the smaller subset for which she knows the private keys— in other words, custodian keys— collectively have enough bitcoin balance to exceed the liabilities committed to in the first step. Again this proof is made public for anyone interested to verify.

Falling short of the goal

At a high level, this model certainly succeeds in removing trust in a third-party accounting firm, allowing anyone including those who have no business relationship with the custodian to verify its financial health. But looking closer at the paper reveals a number of limitations:

1. Proving that liabilities were represented accurately now depends on the diligence of individual customers. This is really the same problem faced by trusted third-party accountant  in a different disguise: ledger integrity. Only this time there is a fighting chance for discrepancies to be uncovered: each customer can verify if their own balance was represented accurately. So the assurance provided by this “proof” is only as good as customer diligence in validating the ledger. It remains an article of faith that such participation will materialize. (Much like the belief that open source software must be getting more secure over time, because if there were any vulnerabilities someone, somewhere looking at it surely would have said something.) Consider that the level of effort involved is non-trivial and involves running random software to verify the commitment.
2. Limitations in the protocol, most importantly the lack of support for multi-signature addresses. This is a deal-breaker in the current incarnation: if there are few things cryptocurrency community can agree on, one of them is that the additional security and redundancy provided by multisig addresses is crucial for risk management when dealing with large amounts. This limitation affects core functionality, not just privacy. Provisions can not be used if the custodian itself is using multisig addresses, even if every other address in the cover set were P2PKH. (In other words, even if we are willing to give up privacy by exposing P2SH custodian addresses among the P2PKH decoys.)
3. Compatibility with hardware wallets. There is a more subtle implementation problem with incorporating a Provision-type design into an existing cryptocurrency storage system. The zero-knowledge proofs require using private key material in non-standard constructions. By “non-standard” we do not mean that they are dangerous or incorrect, only that these are not garden variety algorithms such as ECDSA signature, ECDH key-exchange or ECIES encryption that are widely supported. This matters because of another tried-and-true risk management strategy: using dedicated cryptographic hardware to store high value keys. Off the shelf hardware such as PCs or phones are not ideal for keeping keys due to their large attack surface. Special purpose devices such as hardware-security modules, smart cards and USB tokens are designed and validated to stringent threat models for the safekeeping of secrets. Their simplicity is an advantage for security becomes a disadvantage when contemplating fancy new protocols: these devices are deliberately not extensible. In other words, they support a fixed array of algorithms such as ECDSA and they can not be easily programmed— short of the manufacturer introducing an update— to perform arbitrary new computations using secret keys.
4. Not applicable to fiat currencies. Bank account balances are not verifiable by cryptographic techniques and will remain that way, short of all financial institutions agreeing on a new standard for digitally signed statements. That is not a problem for custodians only handling cryptocurrency. But in every other situation where fiat currency coexists with digital assets, it means the proof of solvency is incomplete. Recall the original reason why proofs are carried out independently for each asset class: to prevent the custodian from shifting balances around between currencies. Putting on the tinfoil hat, a paranoid customer could argue the custodian completed the solvency proof by temporarily using fiat deposits to purchase cryptocurrency.
   Without independent verification of fiat assets against liabilities, there is no way to disprove that line of conspiratorial thinking. (As an aside: stablecoins at first glance offer a solution. For the purpose of the proof, custodian converts its dollar assets into a stablecoin pegged one-to-one against the US dollar. Since stablecoins are tokens represented on a blockchain, the usual cryptographic proofs could then be carried out over control of private-keys in that setting. But the idea that this switch will dispense with third-party trust is illusory: the integrity of the stablecoin depends on its issuer. Transposing the problem from an old-fashioned attestation about bank statements into stablecoin balances introduces a host of new trust assumptions. Specifically that the issuer is carefully maintaining that 1:1 ratio by only minting new coins in proportion to fiat deposits and will allow timely conversion of the stablecoin back into USD on demand— just ask Tether customers how well that is working out.)

Internal controls vs externally verifiable proofs

As the state of the art advances, new protocols may well overcome some of these limitations. But there are more fundamental problems with a public cryptographic proof: possession of keys alone does not equate to sane procedures and risk management. Recent bankruptcy of the Canadian exchange QuadrigaCX is a great example of this. In court filings, company representatives identifies the root cause of $130M+ USD in customer funds being stuck: Quadriga used a single laptop for cold storage, with the password only known to the company founder who recently passed away. That is a staggering failure of internal controls: failure to identify the founder as key-person risk, failure to identify laptop as single point of failure. (There are many other ways this could have gone sideways, including disk corruption on that device.) But as long as one person at Quadriga had access to that cold wallet, they could have produced Provisions-style proofs and passed the solvency test with flying colors.

That is the intrinsic limitation of externally verifiable cryptographic proofs: they can demonstrate that the custodian controls the necessary secret keys at a point in time, but as the saying goes past performance is no guarantee of future results. By contrast a trusted-third party examination need not be limited to quantifying assets/liabilities. They can look into the actual design of cryptocurrency storage— is it a USB drive under the mat or geographically distributed HSMs? They can review policies & procedures around how funds are moved, interview select employees, ask for evidence showing that written procedures are being followed faithfully in day-to-day operations. None of that can guarantee the custodian will not experience a security breach or commit a serious blunder resulting in lost funds. But knowing an organization has consistently applied sound internal controls is at least as valuable a signal as seeing public proof that all the keys are accessible; unlike a point-in-time demonstration, organizational culture around risk management is indicative of future behavior.

The good news is that these two approaches are not mutually exclusive: we can combine third-party audits with partially-public proofs. The starting point is to revisit some of the privacy assumptions behind Provisions: from the perspective of the custodian, what are the zero-knowledge techniques trying to protect and how realistic is that expectation?

[continued]

CP

Updated 2/17: Additional comment on stablecoins.

Proof of funds for cryptocurrency custody: third-party attestations (part III)

[continued from part II]

Assets and liabilities

Before delving into the options for proving that a cryptocurrency custodian has all customer funds in storage, a few word on what exactly we are trying to demonstrate. As before, there are individual customers who deposited varying amounts of cryptocurrency for safekeeping with the custodian. Those account balances are on the  liabilities side of the accounting books— money owed to customers. They are tracked on an internal, private ledger maintained by the custodian. (For reasons explained earlier, the state of this ledger is not reflected on the public blockchain.) The custodian also controls some blockchain addresses where funds are logically kept; these are the assets. The objective is proving that custodian assets are approximately equal to its liabilities.

The fine print: time, currencies and drift

A few clarifications are in order. First, the comparison is always done at a specific point in time. Customer balances are in a state of constant flux: new deposits arriving, withdrawals leaving the wallet and at least in the case of exchange, trading activity resulting in funds changing hands among customers. To avoid discrepancies caused by such fluctuations, it is important to fix a reference time when answering questions such as “how much bitcoin does customer Alice have?” (This can get tricky for cryptocurrencies due to confirmation times: when the customer can sends bitcoin, there is usually a delay between those funds appearing in the custodian wallet and being credited to the customer. The former happens when the very first block containing that transaction is mined, while the latter may follow a few blocks later to allow for sufficient confirmation.)

Second, the comparison must be done independently for each cryptocurrency. In other words, bitcoin balances are reconciled on their own, independent of ether, litecoin or any other asset the custodian holds for that customer. The alternative is converting everything to notional dollar figure and only comparing totals. While that may appear to provide the same assurance regarding customer funds, it obscures important information. When a customer entrusts the custodian with 1 bitcoin, they expect the custodian to hold exactly 1 bitcoin and not that figure converted to equivalent amount of some other currency. Given the high volatility of cryptocurrencies, businesses engaged in that type of arbitrage activity would be exposed to risk from exchange rates moving in the wrong direction. Performing reconciliation independently for each supported currency demonstrates that no such conversions are taking place behind the scenes or necessary to satisfy customer liabilities.

Finally, why the qualifier “approximately” in the objective statement?  Because there are at least two factors that can cause the numbers to diverge slightly in either direction:

• Handling of fees. When customers withdraw, the custodian creates a transaction that includes not only the specific amount requested by the customer but also a transaction fee paid to miners for maintaining the blockchain. A “round-trip” of 1 bitcoin deposited and later withdrawn will draw on slightly more than 1 bitcoin in assets. (In case that sounds unfair, consider that the customer also had to pony up slightly more than 1 bitcoin on the way in.) Whether the fees are negligible or not in the grand scheme of things depends on several factors including blockchain congestion, transaction patterns and exchange rate. Recall one of the most counter-intuitive aspects of blockchain economics: mining fees are a function of blockchain space consumed by a transaction, not the value transferred. An inefficiently constructed 0.0001BTC transfer can cost more in fees than one sending 1000BTC. Many small withdrawals are worse than one withdrawal for the same total.
  Depending on how the custodian accounts for fees— eating the cost, fully passing it on to the customer or something in between— it can result in a drift between assets and liabilities. In late 2017 when bitcoin fees spiked precipitously, many cryptocurrency businesses responded by adopting a less generous stance towards absorbing fees and cracking down on abusive withdrawal patterns.
• Custodian business model. The way a custodian collects revenue for its services can also result in drift between blockchain assets and liabilities. Consider an exchange that allows trading bitcoin against ethereum. Typically both the buyer and seller are charged a commission as percentage of the value involved in the trade. If Alice sold 1 bitcoin in exchange for 40 ether from Bob, both Alice and Bob pay a commission to the exchange. (Not to be confused with mining fees, which are only relevant for transactions that hit the blockchain.) Which currency those commissions are charged in determines the direction blockchain balances could differ from ledger balances. Here is an over-simplified example: the exchange can treat Alice’s original offer as 0.999 bitcoin, charging her 10 basis points, while crediting Bob 0.998 bitcoin after settlement, charging him the same 10 basis points. As far as the internal ledger is concerned, the original 1BTC owned by Alice became 0.998BTC owned by Bob after the trade executed. Of course 0.002BTC did not vanish into thin air. It is still there on the blockchain— the only ground truth that matters for monetary value— associated with some address controlled by the exchange. But from an accounting perspective, it is no longer on the liabilities side of the ledger. The net effect is blockchain balances will exceed ledger balances over time, with the excess corresponding to revenue earned by the exchange.

I. Trusted third-party attestations

In this model, the custodian hires an independent party trusted by its customer base to perform the comparison of assets/liabilities and provide a written statement of their findings that can be shared with customers. The custodian is responsible for providing all necessary information required by the trusted third-party (TTP for short) to perform the comparison. In particular, they must be given access to:

1. Snapshot of internal ledger at a predetermined point in time
2. List of blockchain addresses used by the custodian at that same instant for each cryptocurrency
3. Proof that those addresses are indeed controlled by the custodian (This proof can take different forms as described earlier.)
4. If the custodian also deals in fiat currencies, access to bank statements or equivalent supporting documentation to verify those balances

If everything checks out, the third-party can provide a written statement to the effect that the custodian has demonstrated control over an amount of cryptocurrency equal to their outstanding liabilities. Everyone with access to that statement is free to form their own opinion regarding the assertions, based on their opinion of the author. Assuming a competent TTP with expertise in traditional accounting and cryptocurrency, this model has the advantage of following standard practices for proving the integrity of financial statements. It is common for management to bring in an impartial third-party to look over the accounting and perform additional due diligence to vet statements made by that management team about the financials of the company. While that third-party is faced with the challenge of carefully scrutinizing company records, for everyone else including customers, the problem is greatly simplified. They need only focus on the final outcome, the report stating whether that independent examination successfully verified statements made by the company.

What could go wrong with this approach in the case of cryptocurrency? There is the obvious element of trust in the entity performing the review. But assuming an honest TTP with stellar reputation, there is a more subtle element of trust in the custodian for correct execution of step #1 above.

The problem is TTP can not verify its version of ledger is identical to what individual customers are seeing. The custodian could tell Alice that her account balance is 10BTC while TTP is given a version of the ledger crediting her with only 9BTC. Short of reaching out to customers and asking what they expect their balance to have been at a particular time, TTP can not ascertain liabilities were captured accurately. Aside from sheer impracticality— have you ever received a call from the auditor of your FDIC-insured bank asking what you think your account balance ought to be?— this would raise serious privacy issues. Keep in mind that balancing the books does not require TTP to learn anything about the identity of individual account holders. Instead of using a real name such as “Alice” or “Acme Trading LLC” the ledger shared with TTP can represent customers with pseudonymous identifiers. (Of course even this leaks some information: for example if it is known that a given hedge-fund or high net-worth individual uses a particular custodian, their total balance may be gleamed from the pseudonymous data as the highest value.) Actually exposing the identity or contact information of customers to TTP is problematic.

Likewise even disclosing total assets under management as part of the attestation would not help reassure customers that their funds are accounted for. This is because only the custodian has a global view of liabilities across all customers. Individual customers only get a “local” picture of their own slice. For example they may receive periodic account statements or have a web page where they can view their balances. But short of collective action involving every single customer, they can not infer the expected total assets under management from their own balance. Consider a simplified scenario where the custodian only has two customers: Alice and Bob. Alice has 10BTC in her account. Suppose an accounting firm vouches for the fact that the custodian successfully demonstrated control of 15BTC on the blockchain. Does Alice get peace of mind? No because she has no idea of Bob’s balance or for that matter the existence of Bob. If Bob holds a balance of 5BTC or less, all is well. But if Bob also had 10BTC on deposit, there is a problem: each customer sees total AUM exceeding their own balance— a necessary but not sufficient condition— while total liabilities exceed total assets.

These limitations inspired a search for alternative models where customers can independently verify that their own funds are properly accounted for. One approach from 2015 using zero-knowledge proofs will be the subject of the next post.

[continued]

CP

QuadrigaCX and Hanlon’s razor for cryptocurrency custodians

Another one bites the dust

Just in time for a series of posts on proof-of-funds for cryptocurrency custodians, news has emerged that the Canadian exchange QuadrigaCX has gone out of business and customers are unable to get their funds on deposit. The plot thickens after Coindesk started investigating and discovered a filing attributing the problems to the passing away of the exchange founder while traveling. According to the affidavit, customer funds were stored on a single laptop—thankfully still in the possession of the Quadriga team— but the password required to access that device and unlock the cryptocurrency storage were only known to the founder.

Suspicious circumstances surround the incident. To pick on three examples:

1. Quadriga previously claimed to use a multi-signature design for cold storage. Instead of using a single cryptographic key, multisig distributes control of funds across N secret keys such that access to any quorum M ≤ N is sufficient to authorize a transaction. As the moniker “multi” implies N is greater than 1, it is difficult to see how the loss of just one laptop alone could result in complete loss of access to funds. (Unless that is all keys were stored on the same device; technically this qualifies as “multisig” in letter but not in spirit. The whole point of multiple keys is risk diversification: force attackers to perform additional work to get more than one key while also building resilience against failure/loss of individual keys. Keeping all keys on the same hardware achieves neither.
2. Even if Quadriga used this degenerate design that achieves “multisig” in name only, the idea of storing over $100M USD on a system accessible to only one person defies the imagination. Well-run companies strive for redundancy in operation, seeking to avoid key-person risks where one person has an outsized level of influence on the success of the enterprise. If employee Bob is the only person in the entire organization who can perform a vital business function, the company is going to have a bad-hair day when Bob goes on vacation, quits to join a competitor, retires— or gets hit by a bus. In fact, that last morbid scenario has inspired the concept of “bus factor” for projects, quantifying the level of dependence on specific individuals with irreplaceable capabilities. Surely Quadriga management would have recognized the massive risk posed by their cold storage having exactly 1 authorized user and no redundancy beyond a single laptop? Putting aside personnel issues, what happens if that laptop experiences a hardware failure? Some commentators have also pointed out that the founder had a chronic medical condition that has also been listed as the cause of death. This is irrelevant: the bus-factor captures chance events not dependent on individual behavior. Careening buses do not discriminate based on prior conditions.
3. Quadriga is also having difficulties accessing its fiat currency accounts, due to ongoing legal disputes. This is completely orthogonal to the problem of accessing cryptocurrency storage: even if the deceased founder had been the only authorized signatory for those accounts, the laws of mathematics do not prevent transferring ownership of funds to the executor. Experiencing problems with both cryptocurrency due to technical reasons at the same time as experiencing problems with fiat due to litigation at the same time is an unlikely coincidence.

The burden of proof

“Never attribute to malice that which can be explained by incompetence”— Hanlon’s razor

Looking past the present uncertainty, we can ask how Quadriga will substantiate its claim that funds have become inaccessible. In other words, what type of evidence is required to prove beyond reasonable doubt that the current dilemma is the result of an honest mistake around key-person risk (in both of senses of “key”) and not outright fraud? There are at least four pieces of evidence required:

• List of wallet addresses. While the cryptographic keys controlling these addresses may be locked away in a laptop with unknown password, the addresses themselves are not secret information. For each cryptocurrency (bitcoin, litecoin, ethereum, …) Quadriga should be able to produce an inventory of all hot & cold addresses currently used to custody customer funds.
• Sufficient funds to account for all customer deposits. While some addresses are no longer under Quadriga control due to inaccessible keys, blockchain balances must show that in principle all depositors could get paid in full if those addresses were accessible.
• An argument for the correctness of the address list. This is the trickiest part, required to compensate for the missing proof that specified addresses are still under Quadriga control. Without that constraint, Quadriga can simply point to a random pile of funds on the blockchain— consider that there exist individual addresses storing more funds than all of Quadriga’s liabilities— and claim those as part of their own wallet. (Given privacy considerations, one can not rely on the legitimate owners to step forward and challenge bogus assertions.) This argument is bound to be imprecise, relying on heuristics and to some extent information volunteered by customers about their own deposits. Hot and cold wallets for a custodian are likely to exhibit high-degree of clustering. Hot wallet addresses send excess funds to cold wallet, and cold addresses replenish hot wallet when liquidity is running low. Starting with a self-identified customer deposit, we can trace funds on the blockchain. For example, suppose a Quadriga customer publicly volunteers the information that they deposited funds from origin address O123. The expected pattern on blockchain would be  O123 → Habc moving funds to hot-wallet, followed by a sweep transaction Habc → Cxyz securing the excess in a cold wallet address and perhaps eventually followed by Cxyz → H456 replenishing a different hot-wallet address when liquidity runs low. Every occurrence of an address in these patterns will lend additional credibility to Quadriga claiming that address as part of its wallet.
• Permanent inactivity. This is a part of the demonstration that remains open-ended. If cryptographic keys controlling addresses are irretrievably lost, the expectation is those addresses never appear as the source for any future transaction on the blockchain. Any movement of money originating out of those supposedly frozen addresses would give the lie to the assertion that corresponding keys are missing. On the one hand, showing that the funds are indeed “stuck” is an easy way to refute the exit scam accusations. It is not exactly a very successful scam if the perpetrator goes out of business without getting to keep any customer funds. On the other hand, it means Quadriga will never have any finality or closure in its defense: years from today, the eventual movement of those funds could reveal that it was an exit scam after all— albeit one orchestrated by extraordinarily patient crooks, waiting years for their payoff.

Can Quadriga build a convincing argument? Time will tell. It is very likely that parts of the raw data will be reconstructed independently by outside individuals, without any participation from the company itself. Not surprisingly, the suspicious circumstances have already inspired armchair forensic accountants to conduct their own blockchain research to locate customer funds. One such examination has tentatively concluded that statements made by Quadriga management are not consistent with blockchain activity, to put it mildly. Time is running out for Quadriga to furnish its own evidence to refute these allegations, as the public narrative is shifting from an astonishment at incompetence to outrage fueled by increasing suspicion of malice.

CP

 

Where are the coins? Proof of funds for cryptocurrency custody (part II)

[continued from part I]

The challenge of commingled funds

Consider an exchange that allows trading bitcoin against another currency such as USD. For efficiency and scaling reasons, these trades will typically take place off-chain, on internal ledgers maintained by the exchange. That is, when Bob buys BTC from Alice in exchange for USD, that trade executes on private systems managed by the exchange, not visible to the outside world. Placing/modifying/cancelling orders does not update any blockchain state, and neither does the successful execution of a trade when bid/ask prices cross. That means when Alice and Bob are informed that their trade has executed successfully, there will not be not be any blockchain transaction taking funds from an address allocated to Alice and moving them to some other address exclusively reserved for Bob.

Why? Because given the capacity of common public blockchains, it would greatly limit trade latency, frequency and volume to require 1:1 correspondence between trading activity and blockchain state,  For example Bitcoin can process on the order of 10 transactions per second, depending on assumptions about segwit adoption. If every trade were reflected on chain, USD/BTC order books for the top five exchanges alone would account for 10% of that throughput. Putting that in perspective, USD/BTC is just one possible order-book involving bitcoin, and a tiny fraction of the overall bitcoin spot-trading volume. (Because unregulated exchanges have difficulty obtaining/keeping banking services required to accept fiat, crypto-to-crypto trading dwarfs comparable crypto-to-fiat activity.)

Deposits, withdrawals and blockchain state

Once trades are not reflected one-to-one on chain, the idea of dedicated addresses also goes out the window. At first this is counter-intuitive because, deposit addresses are typically unique. Every customer is given one or more unique address to use when sending funds to the exchange. This is used to simplify the problem of distinguishing deposits coming from customers. Recall that an exchange monitoring the blockchain only sees a sequence of transactions and must somehow identify those that correspond to an incoming customer deposit. While we can imagine elaborate schemes where customers state their intention ahead of time (“deposit will arrive from this specified address for this specified amount around this block number”) or use the equivalent of a memo-field in bitcoin transactions to indicate the account to credit for incoming funds, there is a much more user-friendly solution: disambiguate by destination address. When Alice wants to deposit funds, she is given a unique address controlled by the custodian. All bitcoin sent to that address is recognized as a deposit from Alice. Similarly when Bob wants to deposit funds, he gets a different unique address and any funds sent there are credited to Bob.

This may create the appearance of unique customer addresses but the model breaks-down immediately once trading and withdrawals enter into the picture. Suppose Alice deposits bitcoin to her unique address and later executes a trade to sell that to Bob. Recall that this trade will not be reflected on the blockchain even after it is executed. Some of the funds sitting on Alice’s deposit address no longer belong to Alice. Meanwhile Bob is the proud owner of some bitcoin, even if all of his deposit addresses have zero balance as far as blockchain state is concerned. Later when Bob wants to withdraw some of his shiny new coins, the transaction could originate from any combination of exchange-controlled addresses that combine for the requested amount. It does not have to be one of Bob’s own deposit addresses. It does not have to be the original address associated with Alice that supplied the bitcoin Bob acquired in the trade. In fact, there is complex optimization problem around spend-candidate management: given a wallet with large number of addresses and multiple unspent transactions for each address, what is the right combination of UTXO for sending N bitcoins?” The optimal answer for that question is very unlikely to coincide with the internal trading history of how the bitcoin changed hands inside the exchange ledger.

Bottom line: for large-scale cryptocurrency custody, customers have no way of confirming their balance from blockchain state alone. Their custodian could assert that they have 2.5 bitcoins on deposit but the customer can not verify this by looking up the balance of some addresses, secure in the knowledge that all funds residing at those addresses are earmarked for that customer.

Tangent: deposits, withdrawals and misattributions

One consequence of the design described above is that third-parties monitoring the blockchain can get confused by observed patterns and misattribute intent.

Suppose a given blockchain address has been associated with malicious activity: for example it is used to collect payouts from a ransomware scheme. Later a transfer is observed from this suspicious address into Alice’s deposit address at some custodian and credited to her account. Does that mean Alice is implicated in the shenanigans? Not necessarily. Once an address appears on the blockchain, anyone is free to send funds there. Recall that Alice does not have to notify the exchange ahead of time about her intention to deposit. Any blockchain transactions observed sending funds to that address are automatically credited to her account— that means transitions initiated by Alice, but also by someone mistyping an address (granted, this is unlikely because addresses have a checksum that reduce the chance of a typo resulting in another valid address) but more importantly, anyone else who wishes to send a “gift” to Alice. This is not at all an uncommon: high-balance addresses in bitcoin often receive spam contributions. That means one must be careful about jumping to conclusions about evidence of relationship between sender/recipient based on a deposit, especially when the amounts are nominal.

Another example of misattribution going in the other direction. Often transactions originating from an address are assumed to speak “authoritatively” for the intentions of that address. During the controversial Ethereum hard-fork, a virtual poll was setup to gauge support for the fork. Users could vote by sending a nominal amount from their address, to different addresses corresponding to “yes” and “no” options. Of course this being cryptocurrency, voting rights were determined by the distinctly antidemocratic metric of money: the higher the ether balance of the address involved, the greater weight assigned to the vote. Given the hot-wallet management strategy for commingled accounts, it is easy to see how this can be gamed. Any customer can ask to withdraw funds from their cryptocurrency custodian and specify their choice of vote as destination.  While the nominal amount of ETH will come out of that particular individuals’ account (no free-riding allowed) the weight of the vote will be completely out of whack with reality. Because the withdrawal is coming from an address controlled by the exchange, it is likely to have a much larger balance that the individual “voting” and those tallying the votes will incorrectly assume this one vote as representing a much larger pool of money.

Proof-of-funds for omnibus wallets

With this background on typical custody designs for cryptocurrency in large scale systems, we can not turn to ways the custodian can convince customers that all of their funds are still in storage. At a high-level there are three options:

1. Bring in a trusted third-party. This borrows on the standard practice of independent audits in finance. The auditor is hired by the custodian and given full access to both its internal ledger of customer balances and blockchain addresses.
2. Use cryptographic protocols to publish public proofs of assets and demonstrate those assets equal or exceed customer balance. There is no trusted third-party required for verifying the assertions, but it requires participation by individual customers to confirm their own balance is represented in the proof.
3. Hybrid designs, combining elements of third-party statements and public proof. Instead of 100% public verifiability, these options allow customers to independently verify some aspects of the solvency criteria while relying on assertions made by independent auditor for others.

[continued]

CP