The immutability problem
This is the third in a series introducing blockchain technology. It considers the problem of ‘immutability’.
One of the claims frequently made for a public blockchain is that it is “immutable”, that is, once blocks are accepted the blockchain may not be altered. It becomes a permanent record of all transactions that can never be changed. This view is so entrenched that it seems to appear in almost every popular article about blockchains. For an extended discussion of its falsity, see (Greenspan 2017). If this sounds too good to be true, it is for the usual reasons.
Of course, the claim of immutability is false for the bitcoin blockchain since it is subject to the 51% attack by any party or consortium who can amass sufficient computing power. Enthusiasts see this as impossible or so unlikely that it may be ignored.1
How much would it cost to gain control of bitcoin? Bitcoin currently rewards the successful miner with 12.5 bitcoins, each worth about US$7500.2 A new block is added on average every 10 minutes, or 144 blocks per day, 52,560 blocks per year.
Simple arithmetic shows that current returns to miners are on the order of US$5bn a year.3 Mining machinery does not have a long life, so it is reasonable to assume that the total value of effective mining machinery is not much larger than a year’s return. In other words, investing some US$5bn in modern mining machinery would set up a system with approximately 50% of the bitcoin system.
While this seems like a large investment, it is not a huge amount for a medium-sized government wishing to control or to destroy bitcoin. Bitcoin enthusiasts tend to ridicule such a scenario, but bitcoin has already been exposed to 51% attacks through mining pools. In 2014, the mining pool GHash.io gained more than 50% of bitcoins hashrate. After discussion, the pool agreed to limit its computing power to less than 50%: see Farivar (2014). The bitcoin community apparently trusted this promise. Majority attacks may also be funded through cpu rentals: see Hertig (2018b), Hertig (2018a) and Bonneau (n.d.).
In addition, most estimates of Bitcoin mining power put about 50% of it within China. However, in April 2019 the National Development and Reform Commission listed bitcoin mining as a wasteful industry: See (Goh and John 2019) and (Barber 2019). It is not yet clear how this might impact on Chinese bitcoin mining. A US$5bn expenditure by China would not be an impossible sum if the Chinese Government decides that it is to their advantage to destroy bitcoin.
These figures are, of course, very rough estimates, but they show that breaking bitcoin is possible. Bitcoin is very secure, but it is not bulletproof, something that has been known since its inception.
The more interesting question will be discussed below: should it be immutable?
Private blockchains are also sometimes claimed to be immutable, but this is clearly false. A private blockchain must have trusted parties, and these trusted parties may agree at any time to change the rules or ‘rewind’ the blockchain.
By a ‘rewind’ is meant starting at the block where the alteration is to be made, then rebuilding the chain block by block. All that is necessary is for all the validators to agree that a certain block should be changed, then sign the new block. Of course, the nature of the blockchain means that all subsequent blocks must also be changed.
The ‘mutability’ of private blockchains has led some enthusiasts to declare that private blockchains do not deserve the name, that they are not really blockchains at all. While not wishing to enter into that rather pointless debate, it should be noted that alteration of a blockchain by this ‘rewind’ method is time-consuming and expensive. If frequent corrections to the database is contemplated, it may be worth asking if a normal relational database might be more suited to the project.
In any case, the desirability or otherwise of immutability must be considered at the time of blockchain design.
More importantly, for commercial purposes we must ask if ‘immutability’ is really a desirable property of the blockchain. Errors in recording transactions are not unknown in commercial applications, and it is not always sufficient to enter a counter-transaction to reverse the earlier one.
As an example, consider a database that records credit defaults. An entry that erroneously notes that John Doe has defaulted on a one million dollar debt is not corrected by later recording that John has an exemplary credit record. What is required is that the earlier erroneous record be expunged.
Corporate databases, including private blockchains, will often be subject to privacy legislation which requires information to be expunged under certain circumstances. The EU ‘Right to be forgotten’ privacy laws are an extreme example of this, giving individuals the right to require records to be corrected or even erased in certain circumstances.
Blockchains may also be infected with malware, as INTERPOL reported in 2015.4 The ‘ZombieCoin’ protocol even claims to be able to leverage the existing bitcoin network to introduce botnet command and control mechanisms.5 Most companies would want their blockchains cleansed of such offensive, and often illegal, material.
Transaction corrections may be desirable even in the bitcoin blockchain. Links to child pornography and other improper content have somehow found their way into the bitcoin blockchain. There is also material that infringes intellectual property rights.6 These ‘infections’ may make the import of the bitcoin blockchain illegal in some jurisdictions.
In short, most commercial applications will consider immutability to be a ‘bug’, not a ‘feature’.
There is an obvious exception to this: a corporation or other entity may wish to maintain “immutable” archive records to be used as evidence in later disputes. It is possible that a blockchain could be used for this purpose, but it would be rather pointless. There are well tested “Write Once Read Many” (WORM) storage mechanisms that have been designed specifically for the archive data problem.7
Any blockchain may be altered by a ‘rewind’ operation. In a public blockchain such as bitcoin, that would require the approval of a majority the ‘miners’, a situation almost impossible to imagine. The ‘rewind’ would entail changing a block, then rebuilding the chain from the altered block, a frightenly expensive operation in any bitcoin style blockchain.
Rewinding a private blockchain is more feasible, but even after the agreement of all relevant parties is obtained, ‘rewinding’ involves a complete rebuild of the chain, an expensive and time-consuming operation at best.
A recently proposed solution is the ‘chameleon hash function’ (CHF). A CHF behaves just like an ordinary hash function, but there is a ‘back door’ which is operated by a digital key.
The holder of the key may activate the back door, remove or alter a transaction from a block, then rehash the block so that the altered block has the same hash as before.8 To avoid clandestine alterations, there is a ‘scar’ left in the altered block, a clear indication that a transaction has been removed. Except for the single ‘scar’, the blockchain remains unchanged, its immutability unaltered.9
The CHF solution to altering a blockchain is cheap, and it works for any blockchain.10 By now, the reader is asking the obviously question: who holds the back door key? The key holder has tremendous power and must be trusted by all users of the chain, a situation which is an anathema to most blockchain enthusiasts.
The difficulty is eased somewhat by a remarkable bit of cryptography: the key may be ‘split’ among several entities. The ‘back door’ is not opened until each of the partial key holders has contributed the parts held. Partial key holders may not necessarily know each other, they need not collaborate or communicate, and the ‘partial signing’ gives no information about the other holders or about the nature of the complete key.11
In a private blockchain, the back door key would be shared among one or more of the trusted ‘validators’. There would be an agreed set of rules about when a transaction should be altered or expunged and, when satisfied that the conditions had been met, each would contribute the partial signature to make the alteration. When the complete signature has been formed, the alteration would be made, the altered block ‘scarred’ to note the alteration and the block rehashed to yield the original hash value.
The CHF solution thus solves the commercial and the legal problems of altering a blockchain. However, the solution requires trusted entities, one of the requirements that blockchains were designed to avoid.
Any entity contemplating the use of a blockchain database should ask if the blockchain really is the proper solution. The essential feature of the public blockchain is that there is no trusted entity.
If the design of a contemplated blockchain solution requires a trusted entity, as is the case with private blockchains, then it is worth comparing the blockchain solution to that of a cheaper conventional database.
The factors that must be considered when making such a comparison are the subject of the next note in this series.