Can you edit a blockchain without breaking the chain?

Suppose a shared ledger accidentally includes a confidential document. Everyone agrees it should not be there. Someone appends a correction asking readers to disregard it.

The correction does not remove the document. New participants still receive it when they download the history. Existing participants still carry it as part of the accepted record.

That is an uncomfortable consequence of a property blockchains are often designed to provide: once a record becomes part of the agreed history, changing it should be difficult.

In work with Giuseppe Ateniese, Daniele Venturi, and Ewerton Andrade, I explored a different design choice. Could a blockchain permit explicitly authorized changes to old content while preserving the cryptographic links connecting its blocks? Our paper, Redactable Blockchain — or — Rewriting History in Bitcoin and Friends, first appeared as a preprint in 2016 and was published at IEEE EuroS&P 2017.

The answer depends on separating two questions: how an edit can preserve the chain, and who should be allowed to make that edit.

Why changing an old block causes trouble

A blockchain links blocks through cryptographic hashes. A later block contains a reference derived from the previous block. If the earlier content changes, its hash normally changes too, and the later reference no longer matches.

Updating that reference changes the later block, which affects the block after it. In a proof-of-work chain, reconstructing a valid replacement history also involves the work associated with those altered blocks. A seemingly local correction can therefore become a problem for everything that follows it.

Adding a new record is often the right application-level answer. A reversal can record that a payment was cancelled, for example, while preserving the evidence of what happened. But an appended correction and removal of old bytes serve different purposes. The former does not achieve the latter.

The paper’s construction asks whether an authorized editor can change a block’s content while preserving the value used to link to it. That is the role of a chameleon hash. Sections 3.1–3.3

A hash with a controlled way to find collisions

An ordinary collision-resistant hash should make it infeasible to find two different inputs with the same output. A chameleon hash has a public hashing key and a secret trapdoor. Without the trapdoor, finding collisions should remain hard. With it, an editor can efficiently arrange a collision for a chosen replacement message.

For a public-coin chameleon hash, the idea can be written schematically as:

CH(m, r) = CH(m′, r′)

Here, m is the original content and r its randomness; m′ and r′ are their replacements. The public hashing key is omitted from this notation. Anyone can check the equality. Producing the new randomness for a chosen replacement is the operation that requires the trapdoor.

In the blockchain construction, the chameleon hash covers the content that may need to change. Its output feeds the hash used for the block’s proof of work and the next block’s reference. Preserve the chameleon-hash output and keep the proof-of-work nonce fixed, and that outer hash stays the same as well.

The authorized edit changes the content and its associated checking information. It does not force every later block to acquire a new reference or a new proof of work. The construction retains an ordinary hash in the outer layer; it does not give editors a way to find arbitrary collisions in SHA-256. Section 3.3

Before-and-after diagram of a redactable blockchain. Blocks A, B and C are connected by backward hash references. An authorized trapdoor operation replaces B’s content and randomness while preserving its hash identifier, so C’s reference and the surrounding blocks remain unchanged. Previously saved copies are not erased. — An authorized editor changes the middle block’s content and randomness while preserving the link value. In the construction, an unchanged chameleon-hash output and nonce also preserve the outer proof-of-work hash.

View the full-size illustration.

An edit must not give everyone the editing key

There is a trap here. Some chameleon-hash constructions expose their trapdoor when someone sees a collision. That can be acceptable in applications where collisions remain private. It is a serious problem for a publicly edited ledger.

A participant might retain the original block and then receive its replacement. It now has two different messages and their checking information under the same hash value. If that pair reveals the trapdoor, one authorized edit would give observers the power to make further edits themselves.

The required property is therefore stronger than ordinary collision resistance. Seeing authorized collisions must not enable an observer to generate unauthorized ones. The paper formalizes this as enhanced collision resistance, addressing the key-exposure problem. Section 4.1

One contribution is a generic transformation using encryption and a suitable non-interactive zero-knowledge argument. Instead of exposing the underlying hashing randomness directly, the transformed hash publishes an encryption of it and a proof that the encrypted value is consistent with the message and hash. Verification remains public while the randomness itself is hidden. An authorized editor can recover it and generate the replacement checking information.

That construction has its own assumptions and proof requirements. It is also distinct from the efficient public-coin construction used elsewhere in the paper for the distributed protocols and prototype. The paper provides both the stronger general construction and concrete ways to explore the blockchain integration. Sections 3.4 and 4.3

Who holds the power to edit?

Knowing how to preserve a link does not decide who may change the record behind it.

In the simplest setting, one designated authority holds the trapdoor. That authority can generate the collisions needed for redaction, and the system needs rules for authenticating its changes and adopting the updated chain.

The paper also describes a distributed setting. A designated group holds shares of the trapdoor and uses secure multiparty computation to produce a redaction. The aim is to obtain the replacement checking information without handing the full editing key to an individual participant. The security guarantees depend on the chosen sharing and computation protocols, including their assumptions about how many participants may be dishonest. Sections 3.3–3.4

This arrangement gives a consortium a way to distribute authority. It does not make authority disappear. The group still needs a membership policy, a decision process, and a response to compromised or unavailable key shares.

The distinction becomes especially important in an open network. The paper discusses distributing the key among network participants or a selected subset, while acknowledging the performance difficulties of a large group. Choosing that group and maintaining it over time are deployment questions. A shared trapdoor is not, by itself, a complete governance system. Section 3.5

For a deployment, the editing policy must also say which transformations preserve the application’s meaning. Maintaining hash links does not establish that an arbitrary rewritten payment history is economically consistent or that every transaction dependency remains valid. The cryptographic mechanism is one part of the system’s acceptance rules.

What can an observer learn about the edit?

There are two different observers to consider.

An existing participant may have the old block and receive the proposed replacement. It can compare the versions and take part in whatever approval or auditing process the system specifies.

A newcomer may see only the redacted chain. The paper’s history-independent design aims to prevent that current representation from revealing the previous content. It therefore does not automatically provide a permanent, self-contained record of every edit to every future reader. Section 1.2

These are different requirements. A system that wants an enduring indication that a redaction occurred must design for it. The paper discusses a later permissioned prototype with an immutable indication of alteration; that additional behavior should not be confused with the guarantees of the basic history-independent construction. Section 1.4

There is a more fundamental limit too. Redacting the agreed ledger cannot erase copies that someone already saved. A participant could archive the original chain or copy the document elsewhere. The mechanism lets cooperating participants change the maintained record; it cannot make every observer forget the past. The paper explicitly acknowledges this distinction. Section 1.3

What the Bitcoin prototype demonstrated

The paper includes a proof-of-concept implementation built on Bitcoin Core 0.12. It changes block hashing and extends the header to carry the chameleon hash’s randomness. It implements block redaction and removal in a centralized setting, with one special node holding the trapdoor. Section 5.2

Those details matter when reading the performance results. The experiments ran on a private regression-test network. They measured in-memory operations, excluded disk access, and removed the proof-of-work cost from the block-creation comparison. In that setting, the paper reports a small, nearly constant additional cost for creating blocks. Section 5.3

This demonstrates feasibility for the tested operations. It does not measure the full cost of distributing edits across a production network, running a maliciously secure multiparty redaction protocol, or administering the editing authority.

It also does not show that an ordinary Bitcoin node would accept the modified chain. The prototype uses a different block structure and hashing rule. The paper describes an initialization procedure for migrating an existing chain. Adopting the scheme requires an explicit protocol change, rather than a secret key that somehow edits the existing Bitcoin ledger. Section 5.2

The guarantee has changed

The appeal of an immutable ledger is that an administrator cannot quietly rewrite yesterday’s record using an ordinary database command. Introducing a redaction trapdoor deliberately changes that guarantee.

The resulting promise is conditional: parties without the required authority should remain unable to rewrite the chain, while authorized participants can perform the changes the system permits. Whether that is desirable depends on the application and its trust model.

For me, the useful question raised by this work is how precisely we can state those boundaries. Which content can change? Who can approve it? What evidence survives? What happens if the editing authority is compromised?

Chameleon hashes give a technical answer to preserving the chain through an edit. A useful deployment must give equally explicit answers about the people and procedures controlling that capability.

No results found