[topmonk]

I can give you one implementation off the top of my head. You could, in the blockchain, elect some editors that could remove things, but the effect would be subject to a time delay, such as a month for example. So things removed would still be on the blockchain but would be marked with some sort of quarantine bit that is set later in the chain.

When it comes time to remove the offending data, the software that verifies the blockchain would accept in lieu of the actual data, a set of signatures of the elected editors. All nodes would replace the block with banned data with the replaced one.

It really isn't that hard.

[dsr_]

For that month, nobody outside of Saudi Arabia and Somalia could accept updates to the blockchain, because it has child pornography on it.

I suppose limiting blockchain updates to one month intervals could help solve the energy problem...

[topmonk]

Jesus Christ, I'm not the poster child for this, ok? Just because you can find something you think is a problem with an implementation I came up with on the fly, doesn't mean the whole concept is bad.

Fine, make it instant. People can compare the old data with the new, and notice, and vote out an editor who is abusing their power.

[zbentley]

The whole concept is bad, because the goals are paradoxical and mutually exclusive. Providing a way to instantaneously edit past transactions in a blockchain with the proper credentials sacrifices the only useful property that distinguishes blockchains from traditional databases (decentralized verification of/consensus about state).

The concept is bad because you don't want that property; you want a mutable data store with privileged and unprivileged access.

[topmonk]

> Providing a way to instantaneously edit past transactions in a blockchain with the proper credentials sacrifices the only useful property that distinguishes blockchains from traditional databases (decentralized verification of/consensus about state).

There are different categories of data. Data which refers to the the chain itself must be immutable, I agree. But data that represents the content of articles posted there does not.

> The concept is bad because you don't want that property; you want a mutable data store with privileged and unprivileged access.

You do want that property for some categories of data. You don't want unaccountability in who can update articles and what changes they can make, but you do want the articles to be changeable.

What this provides is to prevent an organization from being corruptable. A government or powerful corporate entity could pressure wikipedia into changing an article to suit their purposes, and wikipedia could stone wall and refuse to comment on any changes they made for that purpose.

If it was on a blockchain, and an editor was pressured into making such a change, the community would be able to directly vote that editor out and get the original content restored.

[root_axis]

If the content isn't on the chain itself then the entire exercise is pointless since the content is the thing that people care about (whether they want the content to stay or go)

[topmonk]

When did I say it isn't? The idea is that some blocks can be accepted in lieu of the original if signed by certain entities that have been voted in by the community. In this way you can change previous blocks in the chain.