Chained wallet. Conception of blockchain, finance security and protection

I had been thinking about writing a post on Blockchain when I happened across the Washington Post’s In/Out List for 2017, and that sealed the deal:

Out:  Not being able to explain Bitcoin.

In:     Not being able to explain Blockchain.

So, feeling up to the challenge, here goes.

Blockchain is really just a distributed, shared database technology. Its use demands that multiple, untrusted entities (such as different companies in a supply chain) write transactions to multiple, duplicate copies of the database that propagate through peer-to-peer protocols.  Each node (or copy) of the database verifies the transaction independently by requiring the transaction to be confirmed in a blockchain.  The blockchain is chronological, and the database can only be changed when there is consensus among the participants.  Most important for the discussion here, however, is that the transactions and the distributed database are claimed to be immutable and permanent.  And that’s a real problem for information governance.

Permanence is a problem

Leaving aside the obvious inability to delete obsolete information in support of good information governance and stewardship, consider what happens when an error is made in posting a transaction, or if sensitive information (such as PII, PHI, or PCI) is entered—an often-proposed use case. By its very design, a fundamental tenet of blockchain is its immutability.  Therefore, any reverse engineering to allow authorized change or deletion creates a hole in the logic that weakens the fabric of the technology—like the ultimate back door that can destroy the security of any software code.

Similarly, the “right to be forgotten,” and various state and federal privacy statutes suggest that immutability is not workable when sensitive or protected information is involved. Further, since all participants in the blockchain see all the transactions, confidentiality is compromised, potentially opening the blockchain to doxing.  Ironically, it was doxing that apparently uncovered the identity of Bitcoin’s founder, also the father of blockchain.

A tear in the fabric?

Just about a year ago, a “smart contracts” blockchain was hacked, and approximately $50 million of member contributions were stolen. The twist is that by “tweaking” the blockchain, the hack could be neutralized and the money restored.  What to do?  Ultimately, a controversial “hard fork” was created in the blockchain to restore the members’ money.  So the door is open for compromise.

Not foolproof

Not only have we seen that a blockchain can be vulnerable to hacking, the Bitcoin blockchain protocol has been used to store more than Bitcoin transactions. Messages, prayers, software code, images, and Wikileaks files have been embedded into the Bitcoin blockchain.  From a pure security standpoint, then, what’s to prevent a copy of a blockchain from harboring malware and ultimately infecting its peers?

At a more abstract level, if blockchain is intended for inherently non-trusted parties, how can you trust the inputs from any one party? For example, if in a supply chain blockchain a party enters into the shared database that they used x, y, and z ingredients, but they in fact used a, b, and c, how can the veracity of the entry be determined?

Think before you act

Blockchain has been promoted as the shiny new tool to increase transparency and fight counterfeiting. Financial transactions, DHS/Customs, supply chain, healthcare, smart contracts, property records, and escrow are all proposed use cases.  But even the purveyor of a blockchain platform cautions not to just “go do something blockchainy.”  In their words, you would “be insane” to use a blockchain when a relational database will suffice.

Do you really need to help create multiple, uncontrolled, immutable replicas of data? To needlessly suck up computational power (electricity) to verify and confirm transactions across duplicate copies when a simple database would suffice?  Shiny object syndrome exists in many endeavors, but perhaps most visibly when it comes to our relationship with technology.  We must be careful promoting technology we don’t fully understand, and consider the ramifications of its use, particularly when it adds to the complexity and energy use of our systems.