implementation of a redlisting mechanism

[synctext]

We created the first implementation of a fully decentralised redlisting mechanism:
https://github.com/bitcoin/bitcoin/pull/4412

We would love to hear your opinion on this. (We are obviously aware of the design ideas of Mr Hearn)


Full documentation of the redlist mechanism: http://arxiv.org/abs/1406.5440

The implementation 1 is split into several parts:
1) retrieval, updating and building of the redlist in memory
2) checking of new transactions by the miner against the redlist, to prevent them from ending up in a block.
Because the redlist is implemented as a hashset, the amortized runtime for this check is O(1). If it sees a transaction that contains redlisted keys it simply does not process it into a block.
3) checking of new blocks against the redlist and forking the blockchain if necessary to keep the blockchain clean

Switching threshold
This code identifies transactions that are tainted. It also gives up after a given threshold. This architecture maintains the Bitcoin principle that the past cannot be undone. If it will find itself in the situation in which the non-redlisted branch is too far ahead with regard to the current tip (the branch height difference has surpassed the switching threshold). It will have no other choice but to give up its effort to uphold the redlist.

End-to-End System Test
See here for the private, difficulty 1 testnet in a box. https://github.com/DistributedRegulation/testnet
The master branch is meant for bitcoind v0.8.0. Check the tags for other bitcoind versions (You must have bitcoind installed on your system and in the path).
The purpose of our tests is to verify both the correctness of our redlisting mechanism and the branching behaviour of a network populated by both the reference and the redlist version of the Bitcoin client. The test consists of a sequence of 5 steps, each involving the mining of a block containing a single transaction. In this environment, nodes W and R are the only miners, while A and B are simply used as transaction endpoints.

There are many outspoken opponents of redlisting in the Bitcoin community. They present a few important arguments against the introduction of redlisting:
• it introduces a central component, namely the regulatory organ, into the decentralized nature of the Bitcoin system.
• redlisting (or tainting) coins would be subject to abuse.
• tying a public key to an individual is technically impossible, making redlisting tricky.
We recognize all of these problems. However, we are of opinion that none of these arguments are strong enough to reject redlisting as a regulatory measure.

We will not further pursue this matter. We regret not having the time to further make enhancements to this pull request. Please pick this up if you want. The code is yours now and do with it as you please. Delft University of Technology gives the Bitcoin community full usage of this open source contribution. We hope the cryptocurrency dream comes true. -peace j

[GoldenWings91]

Who is the ultimate authority that manages what is redlisted? Since Bitcoin is a consensus network if everyone isn't using the same redlist it will lead to many forks.

[synctext]

Who is the ultimate authority that manages what is redlisted? Since Bitcoin is a consensus network if everyone isn't using the same redlist it will lead to many forks.

That is decided by the majority. Every miner can select what to redlist.
This is thus a very generic mechanism, where countries could issue redlists and miners can opt to follow them (or not).
If there is no consensus the majority simply wins. Forks are short lived, limited by the Switching threshold.
This proposed mechanism is designed to give up if it sees that it is creating a fork after, for instance, 3 rounds.

This has gotten some initial press coverage, with more details:
http://www.wired.co.uk/news/archive/2014-06/25/regulating-bitcoin

[DannyHamilton]

Won't this just force users to start using P2SH instead of addresses?

Then your redlisting process won't have any keys to compare to.

[DeathAndTaxes]

That is decided by the majority. Every miner can select what to redlist.

Well at least it is impotent.  Miners will take financial losses by not building off the longest chain.   So despite the fact that you say every miner can do what they want the reality is it can't work unless a majority (preferably a super majority) of miners break the longest chain rule and build off a minority chain to FORCE the other miners to adopt the redlist by depriving them of revenue.

This proposed mechanism is designed to give up if it sees that it is creating a fork after, for instance, 3 rounds.

When that happens on the miners stupid enough to build off of the minority chain loose.  They lose all their block rewards on the orphaned chain.  Of course you aren't dumb enough to not already know that.  The only way redlisting works is through the threat of violence, aka "under penalty of law".

This has gotten some initial press coverage, with more details:
http://www.wired.co.uk/news/archive/2014-06/25/regulating-bitcoin

Lots of bad ideas do.

[synctext]

Won't this just force users to start using P2SH instead of addresses?

You are very correct; that should be considered future work... For this initial implementation we focused on addresses.

[DannyHamilton]

Won't this just force users to start using P2SH instead of addresses?

You are very correct; that should be considered future work... For this initial implementation we focused on addresses.

Seems like a waste of time and effort.

[cr1776]

...We will not further pursue this matter. ...

That is good news, assuming they mean continuing the redlist.  It seems like a waste of time given the issues with it above.

[gmaxwell]

It's odd that the success rate graphs in the paper do not account for the fact that every non-enforcing miner will automatically keep attempting to restore transactions from blocks that fell out of the chain from their perspective causing the censoring miner to constantly redo his reorg attack until he gives up (or until the next censored transaction shows up). Unless the attacker is also able to author a fraudulent double-spend which conflicts with the censored transaction or has a majority hash-power the censored transaction will eventually make it into the chain, for any/all selection of reorg tolerance the only result is a delay (and massive theft exposure for unrelated transactions during the reorganizations that will constantly happen until the miner turns off the feature or until no more censored transactions are authored).

But it does make some nice examples for the risk created by mining operators (pools, cloud facilities, etc.) with a non-trivial share of the total hashrate, as they would be pretty successful at double spending theft— just not at censorship.

[laurentmt]

This redlisting idea allows funny thought experiments. Let's take this one: buying and selling marijuana is forbidden in many countries and is allowed in a few like the Netherlands. Thus, we could imagine that with a system like this one, a majority of miners in the world could decide to reject all transactions related to marijuana business whatever the country of origin. It implies that miners from foreign countries would start to "punish" dutch citizens for something which is legal in the Netherlands...

Ok. I'm just kidding but I'm sure you get the idea: reducing human laws to a boolean flag in the blockchain (good/bad) sounds like a very narrow vision of justice and regulation.

Anyway, I acknowledge the courage of the team for investigating a controversial subject even if I stay on a different vision: punish guilty people, don't punish the coins.

My 2 satoshis.