Qntra and others have been detailing potential ulterior motives for the push for an XT hard fork. Populist support for "Bitcoin"XT tends to ignore code that has not been well publicized or that they find inconvenient to acknowledge. The code in question relates to the deanonymization of XT nodes running on Tor and the blacklisting of Tor exit addresses. This is achieved through an IP address blacklist of nodes which "misbehave" and checked daily against a list of nodes maintained by Mike Hearn which the XT client dutifully fetches.

The code presented below was pushed by Hearn for merging into Bitcoin "Core" and created a large controversy in the discussion attached to the pull request on Github. Wladimir J. van der Laan commented on the request:

@mikehearn A while ago you said you wanted me to behave more like a dictator. I still refuse to do this with regard to the consensus rules, but I'm fine with doing it for technical changes.

So: I reject anti-Tor blacklist in Bitcoin-Core.

Go ahead and merge this into your own fork, but the discussion here is done. Every pull you touch turns into a cesspool, a big controversy that detracts from getting day-to-day work done. You are behaving in a way that is toxic to this project. Instead of considered step-by-step development and reasoned discussion, like all other people here, you throw something over the wall and start a forceful argument on how you're right and every alternative suggestion is a mistake that will lead to doom and gloom. This is draining our energy. Stop it.

The first part of the code defines IP groups, which correlates a connected node to a specific IP address:

// Copyright (c) 2009-2015 The Bitcoin Core developers
// Distributed under the MIT software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.

#ifndef BITCOIN_CIPGROUPS_H
#define BITCOIN_CIPGROUPS_H

#include "netbase.h"

class CScheduler;

// A group of logically related IP addresses. Useful for banning or deprioritising
// sources of abusive traffic/DoS attacks.
struct CIPGroupData {
    std::string name;
    // A priority score indicates how important this group of IP addresses is to this node.
    // Importance determines which group wins when the node is out of resources. Any IP
    // that is not in a group gets a default priority of zero. Therefore, groups with a priority
    // of less than zero will be ignored or disconnected in order to make room for ungrouped
    // IPs, and groups with a higher priority will be serviced before ungrouped IPs.
    int priority;

    CIPGroupData() : priority(0) {}
};

struct CIPGroup {
    CIPGroupData header;
    std::vector subnets;
};

// Returns NULL if the IP does not belong to any group.
CIPGroupData FindGroupForIP(CNetAddr ip);

void InitIPGroups(CScheduler *scheduler);

#endif //BITCOIN_CIPGROUPS_H

This second piece of code uses these data structures in a nefarious way:

bool disconnected = false;
 {
     LOCK(cs_vNodes);
     BOOST_FOREACH(CNode *n, vNodes)
     {
         int nodePriority = n->ipgroup.priority;
         if (nodePriority < ipgroup.priority) { LogPrintf("Connection slots exhausted, evicting peer %d with priority %d (group %s) to free up resourcesn", n->id, nodePriority, n->ipgroup.name == "" ? string("default") : n->ipgroup.name);
             n->fDisconnect = true;
             disconnected = true;
             // Leave shouldConnect = true to allow this socket through.
             break;
         }
     }
 }

 if (!disconnected) {
     CloseSocket(hSocket);
     LogPrintf("Connection slots exhausted, refusing inbound connection from %sn", addr.ToString());
     shouldConnect = false;
 }
}
else if (CNode::IsBanned(addr) && !whitelisted)
{
 LogPrintf("connection from %s dropped (banned)n", addr.ToString());
 CloseSocket(hSocket);
 shouldConnect = false;
}

if (shouldConnect)
{
 CNode* pnode = new CNode(hSocket, addr, "", true);
 pnode->AddRef();
 pnode->fWhitelisted = whitelisted;

 {
     LOCK(cs_vNodes);
     vNodes.push_back(pnode);
 }
}

This code prioritizes the IP addresses of nodes known to behave correctly according to Mike Hearn, and drops deprioritized nodes when the machine runs out of resources. This could eventually lead XT nodes to only connect to "white-listed" peers, essentially forcing users to use specific access points to relay transactions to the network. In fact XT contains a Python script which generates a C struct of deprioritized IP's specifically mapped from TOR exits. As of the publication of shitco.in's article the XT project has a list of over 1000 IP's which have been added to this blacklist.

One can easily see how this mechanism could serve a regime in regulating the use of Bitcoin at the protocol level, a step beyond even what Coinbase has done. An XT node operator is able to add any IP to the blacklist but what is more concerning is that the default behavior of an XT node downloads a dynamic list upon start up:

The code has both a static list and a list that's downloaded when the node starts.

This list "that's downloaded when the node starts" could be served by any number of malicious actors attempting to isolate or force individuals off the network under the guise of DDOS protection. Hearn states this downloaded list is only a list of known Tor exits as these according to him commit Denial of Service attacks upon the network. A predominantly XT network that is under heavy load would essentially prevent anyone from using Bitcoin with Tor.

Given Hearn's bizarre approach in trying to be a part of Bitcoin, it isn't too far fetched that his definition of "Denial of Service" is actually a framework to be used by a government to exert control over the Bitcoin network. However running XT and Hearn's patches is a choice, though some voices on social media appear all too happy to choose this reality for themselves. Though Hearn claims to have good intentions, his true loyalties and thinly disguised malfeasance are apparent even under the most superficial examination.