Operational Redlist Mechanism

[synctext]

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.

[maaku]

I'm afraid you missed the window for this PR by 2 months and 24 days.

[gmaxwell]

While this is advertised (e.g. https://bitcointalk.org/index.php?topic=665191.0) as a decentralized redlist proposal what is actually does is quite different— it polls a hard coded URL and blocks whatever it returns, an overtly centralized mechanism.

Even the few fringe people with a poor understanding of the important of fungibility as a social fiction (— which is all it is even for classic forms of fiat currency) to enable money like goods to be useful would not find a mechanism with some unspecific central control desirable; and there is no existence proof for a globally accepted authority for the censorship of monetary transactions anywhere now or in history.

Back to the effects on the network— and ignoring the moral and economic implications this functionality, the mechanism presented here guarantees no consistency between participants. It doesn't even make an effort to achieve consistency beyond hoping all users use the same central authority at the same time and that authority gives an identical list to every user. Because node running this code will attempt to reorganize the chain (at least for a depth of 2) based on inconsistent information even transactions unrelated to the blacklist may be reversed and replaced with competing spends. This reduction in convergence reliability will cause innocent unrelated third parties to be robbed. While this kind of block discouragement has been proposed previously and could be an effective tool for certain network upgrade situations, the lack of any method to ensure that the enforcing side would be consistent would be very bad for convergence.

Most importantly, I am relatively confident that practically no one would run code containing this software. Obviously you are free to go run it yourself or encourage other people to do so (though, for my own part I would strenuously encourage them not to), but including it in this repository would accomplish nothing of value except cause users to obtain their Bitcoin software from another source. (But it is nice to see proposals come with source!)

Cheers.

[mikehearn]

Incidentally, I coined the term "redlist" exactly so we could talk about a very different system than this. It's quite annoying to see you take that term and use it to mean blacklisting, did the term blacklist not appeal or something? Please don't mis-appropriate terminology like that in future, these discussions are complex enough without people deliberately muddying the waters by redefining terms on the fly.