[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