Avoiding Bitfinex scenarios with Voting Pools

Avoiding Bitfinex scenarios with Voting Pools

Attacks Bitcoin Bitfinex hack Ripple theft Voting Pools

This week, a high-profile Bitcoin theft took place at the Bitfinex exchange. The attacker reportedly stole 119'756BTC, worth about 70.5M USD. Those funds were held at a 2-out-of-3 multisignature wallet - one key was held at Bitfinex's server, another was kept by BitGo, and a third was a backup key held offline by Bitfinex. From what the reports say, the hacker was able to get their hands on the first key, as well as the API credentials required to authorise BitGo to process the withdrawal. With no additional safeguards, they were able to drain the hot wallet and land themselves around the number 2 spot of the biggest Bitcoin theft to date, after MtGox.

The scenario is still unfolding, so there are a lot of theories still floating around as to why the situation was allowed to take place. Some have speculated Bitfinex was forced to keep all of their coins in a hot wallet due to CFTC's ruling (as Bitfinex was not a registered futures trading platform), although it seems that the change was made before the ruling. Bitfinex also unveiled a plan for a "bail in", wherein everyone's assets would be devalued by about 36% so the exchange could continue operating.

Since Bitcoin's past seems to be littered with theft, I would like to have a look at one possible solution to minimise such high-profile hacks:

Voting Pools

Voting Pools is an idea proposed by Open Transactions, a Crypto 2.0 platform focused on notaries issuing IOU tokens and other financial instruments. The main issue such systems have to cope with is securing the cryptos, currencies and commodities underlying the assets circulating on the platform - an USD IOU is only useful if you can redeem it for real USD at the end of the day.

The way Voting Pools help secure users' funds is through shared responsibility from competing actors. Multiple exchanges of similar size would group together in a pool and secure one another's funds through multisig and a legal agreement to share responsibility in an event of a loss (be it from theft or one of the exchanges trying to run off with everyone's money). The multisig would be distributed in such a way that any one actor would not be able to control even their own money, and the system being robust enough to handle a loss of some keys (2-of-3, 3-of-5, 4-of-5, etc.).

This setup would make sure that a critical failure of one actor would not compromise the system. Even if one of the exchanges would burn down, get hacked, or the owner would decide to run away with all of the private keys, they couldn't do anything. The other exchanges would take over the responsibility and secure all of the funds to be able to pay all of the failed exchange's customers without suffering a loss of their own funds.

More importantly, however, this solution also forces every participating company to not only police themselves and ensure they have the most adequate security practices in place, but also to look at one another. When your own money is on the line, you will make sure everyone is keeping up with the rest of the pack in terms of keeping the money safe. Since the exchanges would still be competing with one another, they would have every incentive to expose other actors in the voting pool that are compromising the security.

Beyond that the full implementation of Voting Pools also necessitate that the exchanges would open up their transaction logs to one another to make sure everyone knows how much every customer is owed in case of a database wipe or the exchange vanishing from the face of the earth. This is pretty much automatic when it comes to gateways on a public ledger like Ripple or some shared permissioned blockchain, and it shouldn't be too hard to accomplish if an exchange already creates a strict and timely Proof of Solvency. That being said, it is pretty much unheard of for a normal Bitcoin exchange to do that currently, which might make it more problematic.

Having access to a full, real-time set of transaction logs the participants in a voting pool have everything they need to not only be able to settle with every customer in case the exchange goes under, but they can also police the exchange in real-time and raise flags in case of discrepancy. If exchange's liabilities exceed their assets, all withdrawals can be automatically haled until the matter is resolved. Large withdrawals, sudden market crashes and balance changes could similarly raise a lot of flags (to avoid another MtGox scenario, wherein a hacker crashed the market to be able to bypass the $1000/day withdraw limit).

Conclusions

All in all, voting pools would force a strong degree of transparency on every actor and couple that with multiple security teams making sure the system is secured against a growing number of hacks. While the participating exchanges would sacrifice their business data secrecy to their direct competitors, security through obscurity is never a good approach.

Sample bankchain feature set

Sample bankchain feature set

Bankchains Banks BitShares Blockchain Crypto 2.0 Liquid Permissioned Blockchain Ripple Sidechains smart contracts Smart Oracles Voting Pools

In the recent months, many banks and other financial institutions started looking into the blockchain technology as a potential improvement on their current architecture. Below is a sample feature set of the cryptocurrency technologies that can be used to reimplement and possibly improve upon the banking system as it is today.

Transactions

In all cryptocurrency systems, transactions are the most basic building block of the value transfer network. They have a few important features, including:

• Atomic nature - a transaction can either succeed fully, or fail completely. There is no middle-ground that wasn’t specified beforehand (for example, Ripple’s partial payment flag). It is even possible to have complex transactions that hop across multiple currencies that are still atomic. 
• Self-contained - a transaction in most cases provides all the information that is needed to verify whether it is valid or not. It specifies exactly which money it is spending, quite often how much money is left, as well as contains a digital signature authorizing the move of funds. 
• Undisputable ordering - once transactions are included in a block, their ordering is undisputable. This allows everyone to be able to verify exactly what state the system was before and after the transaction was applied. There is no data discrepancy between the participating institutions as to what happened without the need to resort to a centralized authority. 
• Cryptographic authorization - in the crypto world, there is never a doubt whether someone is authorized to spend the money. Either they own the private keys and can authorize the payments, or they don’t. Moreover, each signature is only valid for a given transaction, so a few authorization problems are mitigated (replay attack, man-in-the-middle, etc.). 
• Easy multi-party escrow - also known as multisig. This allows money to be held by multiple parties in such a way so as to only be spendable when a minimum threshold of parties agrees to spend them. 

Currencies

In the cryptocurrency space, there are essentially three types of currencies.

The most prevalent is a native crypto currency or a digital token. Those are currencies issued by decentralized autonomous organizations, either in the form of complete crypto-networks (like Bitcoin, Litecoin, etc.), or autonomous smart contracts. Those tokens are usually perfectly, mathematically scarce, have a predictable minting schedule and a clear set of rules on how to transact in them. However, due to their decentralized nature, they don’t represent real-world assets very well.

The second kind are derivative currencies (such as BitUSD), which are still created and maintained in a decentralized fashion (without a central or collective counterparty), but through known financial contracts (futures, contracts for difference) can track the value of real-world assets and currencies. Their counterparty risk takes the form of the financial derivative market.

The third kind are IOUs, digital currencies issued by centralized or collective parties usually backed by real-world assets and currencies (such as SnapSwap.USD, BitStamp.BTC, etc). While they are subject to counterparty risk, they have an advantage over the derivative currencies by most often being easily redeemable in kind from the issuer.

Different cryptographic systems have different requirements when it comes to those currencies. A decentralized network will have to have at least the native digital token to avoid spam attacks at the very least. Having that currency, they can also incorporate the remaining two as needed (see BitShares and Ripple for an example). Permissioned blockchains don’t need a native digital token, as the network participants are known entities and can be made liable in case they intentionally disrupt the network. As such, it makes a lot more sense for those networks to mainly feature digital IOUs.

IOU issuers

IOUs in a cryptocurrency network can be a powerful tool. They are useful for not only tracking the value of real-world assets, but also for tracking the trust associated with the currency issuer. If 1 USD from Bank A trades for 1.02 USD from Bank B, we can infer that A is more trusted than B.

When talking about IOUs, there are generally two models that can arise in a system - a web-of-trust or a gateway model (with the real-world examples usually being a mix of the two). In the first model all parties trust one or more parties in the web and money flow is rippling through the system between parties (this is a basis for old version of Ripple). In the gateway model, we have a few central authorities everyone relies on to securely issue and redeem the IOUs everyone else uses (this is a basis for the new version of Ripple). The latter approach might be more useful when there are different classes of peers on the network (governments vs big banks vs small banks vs credit unions, etc.), but the former is useful compliment for smaller-value settlement between the same classes of peers.

IOUs inherently track debt between parties (if you have 1USD IOU from me, it means I owe you 1 USD). In systems like Ripple it is also paired with another variable - trust. Trust limits the amount of IOUs / debt one is willing to take from another individual. This can be especially useful if say, two banks established a mutual trust between one another to simplify payments or reduce their costs. They might agree for example to extend $1M line of credit between one another and use that channel for settlement for any payments made between their accounts. If the credit limit is ever reached, they can still settle with potentially more expensive IOUs from a gateway (say, a government), or settle the debt in some other way and resume operating with the cheaper IOUs.

Decentralized exchange

Having a number of currencies issued on a decentralized network opens up a lot of possibilities. Most useful one perhaps being a decentralized exchange allowing trading between any currency pair. With an open market accessible to all peers, one could expect to drive the spread for performing FX trades to spot, even for small value transactions. Having that, one could expect to start seeing the Singularity of Money going into effect, where the currency you own would not matter as much as the value of that currency. Multi-currency hops would allow one to route money through the most efficient market in the web of value allowing for easy bootstrapping of new remittance platforms and applications.

KYC

An important aspect to consider while designing a crypto network is how it can comply with KYC regulations. While decentralized networks such as Bitcoin are focused on fostering strong pseudonimity, permissioned blockchain users in most cases would be interested in dealing only with known parties. This can be achieved by either having all entities in the system known and explicitly recognized, or having a more open system but with each peer being responsible for doing their own KYC.

The first is a model that seems the most popular with private permissioned blockchains such as MultiChain, where the creators of the system explicitly have to grant read and write permissions to every network participant (thus giving them an opportunity and potentially a responsibility to perform the KYC on everyone).

The latter model is more popular on public blockchains that allow permissioned access, such as Ripple. There, every gateway can explicitly either blacklist addresses to prevent them from using the IOUs they created, or create a whitelist of only the addresses that can send and receive the IOUs.

Block encapsulation

One of the more important differences between a database-based approach and a blockchain-based approach for processing transaction is the idea of encapsulating transactions in blocks. A blockchain, whether it is permissioned or public, has a few key advantages:

• Order of transactions is strict - there is no doubt which transaction is to be applied first and at what time. This addresses the problem of race conditions and can be used to address the problem of frontrunning in a system without a central authority. 
• History is immutable - since all blocks in a blockchain refer to a previous block’s hash, it is impossible to alter any record of what blocks and transactions took place in the past without rewriting it entirely. Paired with real-time anchoring of block hashes into a public immutable ledger such as Bitcoin ensures that any block forks would be evident and would have to be accounted for. 
• Provable auditability - knowing only the latest block hash (which is a small digest in comparison to the actual size of the blockchain), one can not only audit the entire history of the blockchain, but the auditee can probably for the first time in history provide a positive proof that they disclosed all the data for the audit. Any records that are missing or have been altered will come up in a proper audit. 
• Everyone can be sure they have all the data - if one is at the blockchain head, they know they have or can fetch all historical data. There is no doubt whether some chunk of data is missing or not. 

That being said, blockchains are not a silver bullet. They come with their own weaknesses:

• Blocks are slower than individual transactions - while a transaction can be committed to a database within a few read/write cycles, a block takes awhile to be created and propagated. The fastest blockchains out there achieve about a block per 1-5 seconds. While each block can contain many transactions to possibly reach the required throughput, those transactions can only come in discrete quantas, not a constant stream (as they say, “Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.”). 
• Performance-wise, a blockchain will probably have a higher transaction overhead than an optimized database. There are a few possible reasons for this - the fact that in the end transactions from a block will have to be committed to a database anyway, the overhead of synchronizing the network and resolving forks, or the relative age of Bitcoin technology (7 years) vs say, SQL (about 40 years). 
• Currently, there are many blockchain-based cryptocurrency solutions out there, but there are also cryptocurrency networks out there that don’t rely on blockchains, such as Open Transactions. The latter relies on having a few notaries verifying transactions in real time and providing cryptographic receipts for those transactions. It is an interesting approach that allows anyone to prove their balance by merely presenting the last receipt without having to hold onto any prior history.

Tiered blockchains and bandwidth reduction

As it became evident in the Bitcoin world, blockchains can become vulnerable with increased network activity. As such, a modern blockchain solution for high-transaction-volume environment should be prepared to address the bandwidth issue before it might become a problem.

There are a few possible approaches one can take - settle transactions off-blockchain (like the Lightning Network), create a separate permissioned blockchain (like Liquid), or create sidechains (like Credits or what Blocksteam initially wanted to create). Out of those three, sidechains appear to be the more ideal solution - allowing one to move value on and off the main blockchain, transact on that blockchain with the transactions being cryptographically linkable to the main chain (through anchors), and not rely on more centralized third parties.

As such, it might be feasible to construct a tiered blockchain that would be able to offload a good amount of transaction volume off the main chain while still allowing settlement between tiers. At the top of the chain we would perhaps have a public blockchain where the highest-tier peers would issue their IOUs - governments, biggest banks, etc. Below that, we would have sidechains maintained by various banks and other financial institutions. This would allow them to perform more internal transaction without cluttering up the main chain. If needed, more sub-sidechains could also be introduced to further increase transaction throughput. One could also perform sidechain-to-sidechain transactions through a dedicated protocol (such as what Interledger is proposing).

It would be useful for the top of the chain to be a public blockchain as it would allow more institutions and possibly even governments to join and integrate directly with it.

Sample network graph of a tiered blockchain:

Proof of Solvency

One very interesting concept that emerged from the Bitcoin world is so called “proof of solvency”. It allows institutions such as exchanges or gateways create a positive proof that they own a certain amount of currency and that their liabilities are no greater than their currency reserves. Depending on the system in question, the proofs can be either be complete (proving beyond a shadow of a doubt both the assets and the liabilities) or disprovable (one can present undeniable evidence that the institution is lying).

The first scenario is mainly applicable for completely open ledgers - in most cases, only cryptocurrencies and Crypto 2.0s. For example, BTC2Ripple can prove both that they own a certain amount of bitcoins AND the level of their outstanding liabilities on the Ripple network. Since both networks are open, the transaction can be verified to be true or false at any given time.

The second scenario applies whenever we’re dealing with either closed networks, or networks that don’t provide cryptographically signed proofs. This includes exchange’s private databases and bank statements (barring something like TLSNotary). In this case, we either have to rely on some signed documents or PDFs supplied by the banks about the account balances, or generate a merkle tree of all account balances on an exchange. An exchange cannot prove that the information is complete, but anyone can prove the data is invalid if they find their account balance either omitted or altered.

As such, Proof of Solvency can be an important tool for financial audits, allowing them to be performed at any time without disrupting the normal business operations. Some institutions might even opt for continuous proof - updating the required information in real time to bolster confidence in their business.

Proof of Solvency might be fairly straightforward in the above proposed tiered blockchain. Any balance in a sidechain should equal to the amount of assets held at the higher-level chain. The top-level chain would have clear balances of who has how many assets and liabilities.

Voting Pools and auditing competitors

Voting Pools are an interesting idea for keeping everyone honest. In this approach, we have multiple parties vouching for one another’s solvability and being liable for bailouts in case one of the parties goes under. For example, we could have multiple exchanges forming a voting pool and keeping their bitcoins in multisig addresses such that even if one of them turned rogue, they couldn’t defraud their customers nor turn insolvent. This is made possible with continuous proof of solvency, as explained above.

Voting Pools could also be useful for having multiple institutions creating IOUs backed by all of them. These could include:

• The Euro currency, issued by the joint agreement between multiple EU countries 
• International Special Drawing Rights issued by the International Monetary Fund 
• Fiat IOUs backed by multiple banks 

While Voting Pools are the most efficient in a network based on native cryptocurrencies such as Bitcoin, the concept might also be used in permissioned blockchains.

Smart contracts

The final catch-all solution for everything one couldn’t predict while designing the system. Smart contracts are flexible programs that live on the blockchain and can execute commands based on the state of the network. Coupled with smart oracles, the contracts allow for creation of such projects like a decentralized prediction market.

Conclusions

There are many practical applications of the blockchain technology for banks and other financial institutions. Failing to embrace the new technology might make the old network obsolete. The above are only some of the examples of what can be achieved and it is very likely we will see a lot more innovation in the following years. Even from those building blocks we can construct innovative technologies (such as self-regulating universal basic income).