Inaccurate Design

Bitcoin and Blockchains in FS - The Challenges

Thursday, 3 March 2016

As I noted in my previous post, the Bitcoin and Blockchain technology are the next big thing in the finance industry. However, given that Bitcoin was specifically developed to overcome the need to even use financial institutions, there are a number of design decisions and quirks of the technology that could make it’s use dubious - at best, ‘not the right technology’, and at worst the completely wrong technology!

I highly recommend reading the previous post for a quick primer on how the blockchain works if you aren’t already familiar with it. The rest of this post are my views on the problems with the current implementations of the blockchain/Bitcoin in FIs.

51% Attack

If the core strength of a blockchain is that it allows network participation by multiple actors (in the case of Bitcoin, ‘multiple actors’ is ‘millions of actors’) who are relied upon to keep each other honest, then the greatest weakness of is if the actors all act in concert to deceive. This is known as a 51% attack - where a majority of the mining power is controlled by a single person or organisation.

In theory, because each block (link in the chain) takes input from the previous one, it’s impossible to change an old block - it would break the chain. A healthy blockchain network will always work on the longest chain available. You can break the chain and change on old transaction (say, to change a payment amount), but you can’t recalculate every link from that point until the present (and grow the chain) faster than the rest of the network can continue growing the original chain. Your chain will never become longer than the original chain, and your attack will fail.

If you have over 51% of the mining power in the network, you can build a new chain faster than the rest of the network, and eventually your modified chain will overtake the original in length, and the network will ‘flip over’ to your modified chain. This means that as an FI, you need to have actors external to your organisation mining on your chain, otherwise you may as well use a centralised ledger. The question for FIs is, how do you incentivize enough people to participate in your blockchain that this attack becomes infeasible? By incentivizing them!

Network Participation

In the Bitcoin network, people are rewarded for calculating the next block in the chain with ‘fees’ attached to each transaction. If your blockchain isn’t related to a digital currency or transaction, how do you reward people for participating? This can have a non-technical solution - you can have some sort of ‘off-chain’ reward (eg. pay fiat currency), but it means there’s still an entity that end up with control of the blockchain, which is the situation we’re trying to avoid!

Single Entity Control

If you have a single FI (or even group of FIs, or a regulator) in control of the blockchain, you’ve defeated the biggest benefit of the blockchain. This entity (or group of entities) will control the blockchain. If you trust a single entity to control the chain, there are easier ways to have a ‘transparent ledger’ - just publish a list of all the transactions to the network, and allow the controlling entity to sort out any disputes.

Transaction limits

There’s a reason this is at the bottom - it shouldn’t be an issue. As long as you plan ahead when setting up your blockchain, you can avoid this one.

The reason for this issue is simple enough. We mentioned above that when a network participant ‘mines’ a block they 1. Take the output of the previous block 2. Bundle it up with any new transactions 3. Calculate the answer to a mathematical equation 4. Publish it to the network, where other participants can verify the answer is correct and commit it to the chain.

The creation of the bundle of transactions is limited to a total size - currently 1MB in Bitcoin. This limits the number of transactions that can be committed to the chain in any block (estimated to be about 4000 per block at the moment). Each block takes about 10 minutes to calculate (by design), limiting the overall number of transactions per second to about 6.6. For comparison, VISA can currently peak at 47,000 transactions per second.

This is a technical problem with a technical solution, but demonstrates the other side of the coin (pun not intended) with the decentralisation of a currency or ledger - that there’s no single entity to help resolve issues. There’s currently massive debate in the Bitcoin community about increasing the size limit of a block from 1MB to something bigger - like 8MB or 25MB. This will allow more transactions to be processed at once. There any good argument there are pros and cons and trade-offs to be made, but you still need a consensus before you can go ahead.


This is pretty much where my thinking is up to at the moment. Long post. I actually just saw a post on Hacker News about Juno which, from reading the intro paragraph on the page, seems like something I need to read into - it specifically notes other ways of completing the proof of work rather than mining for consensus! Stay tuned.