In the second and final part of this blog we will examine the perils of relying on trust in a trustless world and explore the challenges around governance and in not using a tiered transaction approach. Read Part 1 of the blog here.

 LESSON 4: BE CAREFUL OF RELYING ON TRUST IN THE TRUSTLESS WORLD.

Bitcoin’s intrinsic design equips individuals for value exchange without the need for trust. However, there’re certain practical difficulties involved and a number of applications and organisations are working towards mitigating these. For example, a Bitcoin ‘wallet’ guarantees that payment can be created, thus enabling transactions in a traditional way but using a non-traditional currency. However, in almost all circumstances this would require an individual to deposit some or all of their Bitcoin in the custody of the service provider, so that they are equipped to verify transactions more quickly.

To do this, the service provider uses applications and processes away from Bitcoin, perhaps even relying on a traditional payments infrastructure or relational databases. The upshot? At best these suppliers become a single point of failure and a huge honeypot for criminals to target. At worst they can become corrupt and inefficient.

So, what happens if such an organisation is hacked or becomes inefficient? Regrettably this has happened numerous times. The most recent notable case is Bitfinex, an exchange platform where cryptocurrencies can be exchanged to USD. In this case attackers managed to make off with 120,000 BTC valued at $71 million dollars. On August 2, 2016 Bitfinex suspended trading on the platform in reaction to the attack, later deciding to socialise its losses across all of the BTC holders on the exchange, with each user losing around 36% of their balance[1]. Ouch!

The conclusion that financial services can draw from this example is the importance of controlling single points of failure. A more contextually relevant example of this would be the use of Oracles, essentially trusted off-chain information/data sources. Whilst Oracles can be used in a variety of different scenarios, they need to be managed carefully, particularly when their input generates automated outputs. A specific example that illustrates this point is the Trade Finance utopian use case. In this scenario there is often an Oracle listed off-chain that simply feeds in the delivery status of goods arriving at Port X. If an attacker were able to compromise Port X’s system, perhaps with bespoke ransomware, they could withhold or wrongly express delivery statuses, affecting linked payments When designing a solution, it is clear that these kinds of points-of-failure should be identified and carefully managed.

 LESSON 5: GOVERNANCE MUST BE IN PLACE TO ALLOW THE SYSTEM TO EVOLVE.

To deploy any form of blockchain with multiple participants there needs to be a detailed agreement on how the system operates – a challenge in itself. Further, once a large network of users is found and the system is up and running, what happens if there is a need or desire to change the underlying protocol?

An example of this can be found in the ongoing debate about increasing the Bitcoin Blocksize and generally speeding up confirmation, two popular issues amongst the Bitcoin community. This discussion has led to the formation of the two very different schools of thought: Bitcoin Core and Bitcoin Classic. Both are concerned about how Bitcoin can be scaled whilst avoiding decentralisation. Core and Classic have very conflicting views on how this can best be achieved. Both views have a strong following, but ultimately if either of the proposals goes forward it will require the support of a strong majority of the network.

In these conditions, decision-makers are naturally driven by their own self-interest. And while it’s likely that the long-term health of the network benefits everyone, it still doesn’t necessarily align with the priorities of the aforementioned decision makers. This leads to options being selected which may not be in the network’s best interest, perhaps The DAO (the Ethereum based Digital Autonomous Organisation)[2]represents the best example of this. Further, this kind of adoption can also be very slow and inflexible in the face of change.

So who would run our blockchain powered utopia for financial services? One of the more feasible options is that an organisation similar to SWIFT would be formed (newly or by existing players transforming) and funded by the global financial services sector to govern various financial blockchains for the good of all participants. Or perhaps a private organisation that sells services on a consortium model, but with a clearly defined ambit, similar to CSD services currently provided.

What is clear is that within a blockchain system, a robust form of governance will need to be designed into any use case to ensure that when the system needs to adapt or evolve, it can do so without any obstacles or political disputes to hinder it. The wheels are in motion to address these challenges, but there is still a long way to go.

LESSON 6: TRANSACTIONS SHOULD BE TREATED DIFFERENTLY DEPENDING ON RISK AND NEED.

All Bitcoin transactions are treated the same regardless of their value. This is at odds with the constructs of most processes, where their security and level of processing required depends on the nature of the task. For example, in the UK there are three tiers of security-clearance levels. These range from a basic ID confirmation/criminal record check to secure checks and examinations around motives and being blackmail-resistant. Similarly, banks would not normally ask for any proof of source of funds when accepting small deposits, but would be required to do so with large or uncharacteristic deposit amounts.

The Bitcoin Lightning Network is a proposed decentralised system for instant, high-volume micropayments that, allegedly, could exist without the risk of delegating custody of funds to trusted third parties. In theory the Lightning Network could power instant transactions after being set up by moving Bitcoin into the secure smart contract to perform transactions, referred to as a channel. To start using the Lightning Network it is proposed that a user starts by sending money to it from the Bitcoin blockchain in the traditional way, thus requiring proof-of-work and the normal confirmation processes that go along with it. The user then can transact at high speed on the Lightning Network with their balance being maintained solely on the Lightning Network. However, once an individual is finished, they then move their money off of the Lightning Network back to the Bitcoin blockchain, again using a standard transaction. This transaction broadcasts the netted amount of Bitcoin (thus not recording each minor transaction on the Lightning Network), thus saving significant effort and producing a service of instant payments. This is perhaps being ideal for numerous low value straightforward exchanges, leaving the Bitcoin blockchain for more complex arrangements. This proposition, in its most optimistic form, represents a good balance of functionality, immutability and security, but there are many details still to be determined.

Whilst the proposition of the Lightning Network is still largely untested, it does present an interesting reminder, namely that it is perhaps undesirable to treat all transactions, regardless of risk and value, the same way. This should definitely be borne in mind when applying blockchain technology to a complex use case.

CONCLUSION

Bitcoin is and will continue to be an ongoing project of interest. Future entrants exploring blockchain technology should take note of the lessons described, but ensure that they do not fixate on the technology and techniques derived from cryptocurrency as a panacea that can solve all of the challenges facing financial institutions today.

REFERENCES:

[1]http://www.reuters.com/article/us-bitfinex-hacked-hongkong-idUSKCN10I06H

[2] http://www.coindesk.com/ethereum-executes-blockchain-hard-fork-return-dao-investor-funds/