“Redactable Blockchains” are not Blockchains!

Calling out misinterpretations and misuse of Blockchain technology.

Upon reading the Abstract of “Redactable Blockchain, or Rewriting History in Bitcoin and Friends” created by Giuseppe Ateniese (USA), Bernardo Magri (Italy), Daniele Venturi (Italy) and Ewerton Andrade (Brazil) I grew insensed as it contradicted the intrisic nature of the Blockchain concept seemingly in efforts to make it palatable for consumption by corporations under the guise of removing dark or contested content.

Below are my responses to statements and claims in the whitepaper:

“As we argue, there are several reasons to prefer an editable blockchain, spanning from the necessity to remove improper content and the possibility to support applications requiring re-writable storage, to “the right to be forgotten”.”

What is “improper content”? Who is deeming this content “improper”? The trusted, permissioned owner of the private blockchain or source of content? As we read further we find a potential for a “Central Auditor”.

“Whether the blockchain is used to store data or code (smart contracts), there must be a way to redact its content in specific and exceptional circumstances.”

This is essentially adding a trust entity into a decentralized blockchain!

But records should be expunged in case they contain errors or sensitive information, or when it is required by law. Even encryption may not help as keys are notoriously difficult to manage and are often leaked.

Append, do not expunge. People make errors. Erroneous people make erroneous smart contracts which in turn make erroneous transactions which are reflective of the erroneous people who created them. Append!

Redactions can be made only by authorized entities and under specific constraints; moreover redactions are publicly auditable by existing miners, since they must approve the new blockchain and have access to its old copies.

And there we have it, “authorized entities” that under “certain circumstances” can redact/ edit the blockchain.

by redaction we mean one of the following actions (and any combination of those): re-writing one or more blocks, compressing any 2 number of blocks into a smaller number of blocks, and inserting one or more blocks.

Compressing blocks (coalescing blocks) that represent the same transaction? Is that redaction? I assume no since the original transaction was never edited and therefore would remain immutable. I would expect redaction would be editing transactions that exist versus appending.

The solution per the whitepaper is essentially to add a backdoor key to each link of the hash chain therefore making it possible to find collisions and thus replace the content of any block in the chain. Really? The team references this as a "trapdoor" but I regard it as a "backdoor" key.

Proposing to affect the immutability of the blockchain may seem an ill-conceived concept given the importance of the append-only nature of the blockchain. However, hard forks exist that can be used to undo recent transactions.

Very ill-conceived and kow tows to the major corporations who want to utilize Blockchain while maintaining trust and ownership such as in their existing centralized model.

As Peter B Nichols puts it,

The pragmatists believe peer-to-peer trust is possible. Idealists clutch onto the world unchanged, controlled by a self-selected minority.

Now to the my question, who can make these redactions? The whitepaper advises:

Who can make redactions? We show how to make redactions given the knowledge of a secret key. This key could be in the hands of miners, *a centralized auditor*, or shares of the key could be distributed among several authorities. The actual way the trapdoor key is managed depends upon the requirements of specific applications; while we provide some examples (see Section 3.5), we stress that those are just a few possibilities out of many.

Its the “Central Auditor” that raises both eyebrows for me. It is understood this can be defined and agreed in consensus by the blockchain but is this truly decentralized in this scenario? What if the Central Auditor is compromised? In this scenario, a 51% attack is not needed assuming there is one Central Auditor who can be coerced or compromised.

Trusted authorities could be individuals, such as judges or arbitra- tors, or/and organizations, such as the International Monetary Fund (IMF), the World Trade Organization (WTO), Electronic Frontier Foundation (EFF), INTERPOL, etc.

Respectfully, I would not regard these as “trusted organizations”. These organizations can be influenced and auditors of blockchains can be coerced into redacting blocks without justification or consensus.

The whitepaper continues to walkthrough the mathematical model behind utilizing chameleon hash functions etc. to facilitate a “trapdoor”. Furthermore there is a case made for “shrinking” the chain by essentially removing entire blocks from the chain due to disk space and computational limitations. The latter become less and less of an issue in this day in age. I can see a merkle tree where possible legacy nodes are compressed/archived but never redacting, removing or editing blocks.

In conclusion, I contend that whitepapers such as this are insightful however contradict the original intent of blockchain technology. Furthermore, I expect a permissioned blockchain with clearly defined consensus and valid smart contracts can address the majority of the problem cases mentioned. Is it perfect, definitely not however the goal is to vastly reduce not eliminate errors.

It is essential the Blockchain community review, debate and share commentary on such white papers/research endeavors.

As my regional focus is Brazil, I expect strong Blockchain use cases in the area of supply chain, dispersion of public funds, campaign financing, land ownership and general agriculture, tracking and recording of Indigenous people (nativos brasileiros) amongst many others. A model such as the one proposed in this whitepaper literally provides a backdoor thus rendering both the Blockchain and it's benefactors vulnerable.

Thanks for reading and comments are welcome (in English and Portuguese).

Brian McCurtis