Operational Redlist Mechanism

Please do not merge yet!

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.