With the block size debate raging for weeks now, bitcoin has proven (again) that it is has grown up and is now subject to the unfortunate realities of the world, and politics. While we have been following the debate closely, we felt that it was not worthy of reporting on because of the childish behavior, remarks and slander which are completely unproductive when you are trying (as a community) to build the next global financial system. The sock puppets, censorship and social engineering fuckery have gotten way out of hand, and the community is starting to stray from the cohesion which it has maintained for so many years. While we don’t expect this to be the end of bitcoin, by any means, it it isn’t going anywhere fast until the current issues are sorted out and consensus on the block size is reached.

It is clear that there are certain agendas at play, and our goal is to help readers see through the bull shit to gain a clearer picture of what is actually going on. As we have stated multiple times, we are bitcoin believers, and our goal is to educate the community. The traditional bitcoin news sources are highly censored, controlled opposition or worse, and we strive to provide an oasis away from that garbage, for the intellectually inclined.

Our belief has long been that bitcoin’s only potential Achilles Heel (but not fatal flaw) lies with the politics of the developers. While it is an open source project, and anyone can view or modify the code, the developers are the “controllers” of bitcoin in a sense, and therefore are often viewed similar to political figures. Just like the conversations you unfortunately have to hear when walking down the street about Hillary or Jeb, Reddit is littered with posts of love, hate, passion and disdain for all of the core devs. It’s literally a minefield on some days (well, until censorship). In the “real world”, it has been shown time and time again that by influencing those in control, certain agendas can be carried out, often with little or no push back. Fortunately for bitcoin though, the open source nature of the project allows anyone with a computer and internet to audit the code. In the end, the “controllers” are only perceived to be in control, while the actual control lies with each and every one of us, the community.

A series of abnormal events have occurred in the last few months, which we will lay out below. While it may be clear to some what is going on, most of the community is still in the dark (as usual, what else is new).

1) The regulatory landscape surrounding bitcoin has been changing dramatically. The NY BitLicense has been implemented, many companies and exchanges are refusing to comply, and we can expect more regulation to be introduced in other parts of the globe sometime soon. Anyone reading this blog has read everything associated with these events, so we don’t feel the need the outline them further here.

As we know, bitcoin itself can not be regulated (unless it is hard coded, more on this below), so these current regulations are a patchwork of misdirected attempts to apply traditional regulatory logic to a vastly contrasting system. The at the “core” of the issue, is the bitcoin core itself, and the fact that without actually modifying this code, it is impossible to regulate bitcoin in any effective fashion.

2) The stress test in early July was a blatant attempt to draw the communities attention to the ongoing block size drama. After a series of less stressful stress tests, someone with a very thorough understanding of the bitcoin protocol performed a tx spam attack which slowed transaction time for many considerably.

More in:

Bitcoin Magazine

and some excellent coverage on Medium

The common thread that seemed to tie all media coverage together, especially “mainstream”, was that something needed to be done with the block size. Reddit was ablaze with people saying dumb shit (and some insightful things), and, as usual, no one saw through the fact that this all was just a big game of social manipulation. Sucks, huh?

3) Coinwallet.eu entered the scene a few months back, and immediately questions began to surface. Their about us page is shady, at best, and the business address which they list (78 York Street, London), is a virtual office. Reddit posts outlining this can be found here and here, with more details. Supposedly, their phone number doesn’t even work, their executives are all anonymous and it doesn’t seem as if they have are any satisfied customers (or customers at all).

After the first stress test, Coinwallet claimed responsibility, and more information became available. Finance Magnates does a great job covering that here. They also bring the anonymous aspect of the company to light for those who don’t compulsively check Reddit:

Others pointed to the fact that Coinwallet.EU, previously unheard of in the industry, is using the test to make its name known. Skeptics alleged that the company seems to have come into existence solely to conduct the test. Its website lists no physical address, and does not disclose the identities of its principals.

4) The introduction of Bitcoin XT has introduced about as much volatility into the community as the price has recently experienced. One of the most hotly debated aspects surrounding XT though (until now), has not been the software itself, but the blatant censorship and social engineering/manipulation which has occurred in every corner of the community. This clearly concentrated effort has just pissed off most people, but if you have a half a brain, you would think more into the situation. Why might this be going on? Why is there this HUGE push by some to stop XT in it’s tracks, while others are so eagerly pushing it along? What could each of their agenda’s be? What else could be at stake? Like everything else in the world, is this huge debate just cover for a much larger issue?

Before the spam attacks, the block size issue was raised by Gavin as being “urgent”. Until then, it was known to the community that modifications would needed in the future, but there was no sudden sense of urgency.

Is it a coincidence that the first Coinwallet.eu attack began shortly after Gavin started pushing the block size debate? Seems a little too well timed for us to think so. To be clear, we are NOT implying that Gavin has anything to do with the stress test. There are many other players to consider though.

5) The next spam attack by Coinwallet.eu, which is now being pushed by the msm. Some quotes from that article:

UK-based mining service CoinWallet is gearing up to conduct a stress test of the Bitcoin network in early September, which it said will likely render most standard wallet software “worthless” and create “nearly a 30-day backlog”.

A CoinWallet representative told IBTimes in an email exchange: “I don’t have a set date, but it will be early September. I’m too busy this month to fully devote a large amount of time to executing the ‘test’.

…

“As part of this test, I will be reconsolidating more than 150 Bitcoin that currently sits in these wallets.”

CoinWallet conducted a transaction to demonstrate what this will look like.

“As you can see from the transaction, there are 20 tiny inputs, with half going to miner fees, and half going to one of my CoinWallet addresses. This transaction is approximately 3kb, or 1/323rd of a block. In other words, for every ~323 of these I send, I fill up a block.

…

“These 20 servers push approximately 1 transaction per second. The plan is to fill them up to 50-100 Bitcoin in total. In theory, if all things go as planned, we will create a nearly 30-day backlog.”

…

“Of course, this won’t cripple Bitcoin entirely. Those who are smart enough to increase their fees will still manage to push transactions through. However, it will make it prohibitively expensive, and will likely render most standard wallet software, ranging from Multibit, to Mycellium, Blockchain.info and others completely worthless.

…

A debate has been raging for months over whether or not to increase the maximum size of a transaction block of data beyond 1 megabyte.

Bitcoin core developers Gavin Andresen and Mike Hearn are spearheading the drive to increase the block size, and have developed Bitcoin XT client to allow miners to opt out of the current 1MB limit. The majority of miners must adopt the protocol upgrade or else no change will come into effect.

“The fact that the XT fork hasn’t occurred yet is ridiculous,” CoinWallet said.

So “a Coinwallet representative”, but throughout the entire article he is quoted as referring to themself as “I”. Sounds like a one man show to us. The “representative” is very careful to outline the fact that their “test” attack will render most wallet software useless. Fear mongering, anyone? Their plan is to create a 30 day backlog in transactions, which they believe will shift perception towards the need for larger blocks, now. The end quote is just the icing on the cake, and clears up any conspiracy theories that community members may have had about Coinwallet’s intentions. They are pushing for an XT update, and flexing their digital biceps in order to push their agenda. How much more fucking political can you get with this? The kicker, they plan to start this “test” attack in early September, so like in a week and a half.

So, why does this all matter?

It appeared as if Gavin and Mike were doing the right thing by pressing forward with a solution when no one else would. They put a solution out there, and gave the community the right to decide how to move forward. Until a consensus is reached, the network will not be an XT alt, and we are safe. But piecing all of this together, there seems to be some sense of urgency to force users to switch to XT. Anyone who regularly sends coin, knows that the network works as promised at all times other than when these malicious events are taking place. Since the last stress test ended, the mempool has been pretty much empty, with the exception of what looked like a pre-test to this upcoming attack about a week ago. If there wasn’t going to be another stress test attack, people wouldn’t have any problem completing their transactions until bitcoin organically grew, and the user base started consistently filling 1mb blocks. The point being, other than this Coinwallet.eu FUD and their stress tests, there is no need for larger blocks right now, and there is no reason for anyone to rush and update to XT. So what is the ulterior motive?

As it turns out, some conspiracy theorists believe bitcoin has been hijacked. They feel as if a player has identified and attempted to exploit the one weakness which might actually harm the honey badger. Crashing price? No. Hackings, Goxxings, Ponzis and scams? No. Hijacking the code itself, creating FUD/a media shit storm surrounding the issue and then “creating a 30 day backlog of transactions” because the “fact that the XT fork hasn’t occurred yet is ridiculous”,  sounds like some Stuxnet style shit to us. An urgent (and artificial) timeline is being pushed on the community, to update their software in a rush, to a package which has much controversy surrounding it.

But has the code itself been hijacked? Is this just a conspiracy theory, or conspiracy fact.

In this linuxfoundation e-mail from yesterday, it is noted:

Bitcoin XT contains an unmentioned addition which periodically downloads
lists of Tor IP addresses for blacklisting, this has considerable privacy
implications for hapless users which are being prompted to use the
software. The feature is not clearly described, is enabled by default,
and has a switch name which intentionally downplays what it is doing
(disableipprio). Furthermore these claimed anti-DoS measures are
trivially bypassed and so offer absolutely no protection whatsoever.

Connections are made over clearnet even when using a proxy or
onlynet=tor, which leaks connections on the P2P network with the real
location of the node. Knowledge of this traffic along with uptime metrics
from bitnodes.io can allow observers to easily correlate the location and
identity of persons running Bitcoin nodes. Denial of service can also be
used to crash and force a restart of an interesting node, which will
cause them to make a new request to the blacklist endpoint via the
clearnet on relaunch at the same time their P2P connections are made
through a proxy. Requests to the blacklisting URL also use a custom
Bitcoin XT user agent which makes users distinct from other internet
traffic if you have access to the endpoints logs.

There is a great bitcointalk thread about the issue, which highlights the topic.

Some quotes from that thread:

Mike Hearn says it’s to ban people who use DoS attacks from the network, but obviously it can be used to blacklist anyone.

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23

I’m combing through the code and it’s not looking good.

Basically they will disconnect you if your address has ‘low priority’, which might hurt new addresses. If you have a negative priority score that means you’re an attacker according to them, and you are disconnected.

Also mapping the tor network, lots of code aside from this to break through the anonymity of TOR.

These changes are massive and BitcoinXT has not mentioned them at all, clearly the block size debate is a distraction.
We should start referring to XT as ‘PanoptiCoin.‘

This is disgusting, pages of code for the blacklist.

They’ve been mapping tor for months to get ready for this…. over 1000 IPs listed

 

And some of the more colorful posts from that thread:

There are also some arguments against the supposed findings, we outline the most important and conclusive later in this article.

So after all of that conjecture and possible FUD, let’s break down the situation into it’s simplest form:

1) Gavin initiates and pushes urgency of block size issue

2) Regulations are put into place (BitLicense)

3) First spam attack takes place

4) Much community discussion takes place regarding block size

5) Larger spam attack takes place, Coinwallet.eu takes responsibility

6) Bitcoin XT is pushed out by developers and released in a hurry

7) The MSM pushes the XT/block size issue, after mostly negatively portraying bitoin in the past (but blockchain positively)

8) Coinwallet.eu threatens another spam attack, which will back up the network for 30 days. They also support and promote upgrading to XT immediately opently.

8) Questions arise about the purpose of some of the code in XT, or how it can be modified in the future for other/nefarious purposes. Is this an attempt to “regulate” the bitcoin core?

In all fairness to Mike and Gavin, we have to present the most compelling piece of evidence for their inclusion of the new features into the XT code.

Check out this link for the full thread.

The most important response from Mike:

This patch fixes the issue. It adds code that only runs when the node is full. As nodes are not supposed to get full unless there’s an attack, this code should ideally not run, or hardly ever run. If a node reaches its -maxconnections limit instead of rejecting all new connections, it calculates a priority score for each connection and if there are any lower than the new inbound connection, that lower scoring peer is disconnected to make room. And it adds a starting rule that gives Tor connections a lower score than clearnet connections. Hopefully there will be many other heuristics added over time.

The result is:   if and only if your node has run out of resources, and it has connections via Tor, then it will kick out the Tor connections one at a time to make room for non-Tor users.

This reflects the reality that Tor is much more attractive to attackers than real users:  nobody is going to DoS bitcoin from their home internet connection but people use Bitcoin from such connections all the time.

…

My patch is a tiny first step towards fixing a long standing problem with the design of Bitcoin’s DoS protection system:  it works by attempting to ban IPs that engage in “misbehaviour”. This has two problems:

1. It’s possible to DoS a node without triggering the misbehaviour rules
2. It assumes 1 IP = 1 person

The latter assumption isn’t valid for lots of users, like users on mobile phones, at hotels, at conferences, at some universities ……. and users behind Tor!

One of the misleading things I’ve seen a Blockstream employee say is that the Tor prioritisation patch “risks network partition”, which is a fancy way of saying users behind Tor might get disconnected entirely from the main network.

I have a problem with this argument for a couple of reasons.

The first is that anyone can already trigger such a partition. All you have to do is connect to each Bitcoin node from every Tor exit, and then “misbehave”. The exit will then get banned for 24 hours. New connections are then no longer possible. Existing nodes will keep their connections intact, but eventually people will have to restart their nodes, and then they’ll end up banned too. This results in a kind of slow motion network partition. The best fix for this is to replace the notion of banning IPs with something else …. like a more advanced form of priority.

The second is that it suggests Bitcoin should just not care about the attack I outlined above. The guy who has been saying this also believes that non-Bitcoin-Core P2P wallets are a bad idea, which is consistent with Blockstream’s vision of Bitcoin as a kind of clearing network between quasi-institutional entities. So, no surprise that he doesn’t care about attacks that affect mobile P2P users.

However, the Bitcoin XT project does care about them.

The third reason is that to force Tor users to be disconnected and make a partition unique to this patch, you would have to flood the network from non-Tor IPs. As you are probably breaking the law by doing that, you need to find some other shield. The framework is general so if someone does this via some other proxy network, we can give those networks even lower priority than Tor. Problem fixed.

Then you’d have to use botnets and the like, but I know from my time fighting hackers at Google that this is much harder to pull off than using something like Tor. Attacks getting harder, riskier and more expensive? That’s progress.

The new framework is very basic. There are many other heuristics we can add to make it work better, and eventually remove the Tor specific logic entirely.

One idea is to raise the priority of nodes that are doing useful stuff, like relaying us data.

Another idea is to extend the P2P protocol so clients that don’t have long lived connections and can’t provide services to the network (i.e. phones) can gain priority by proving they own bitcoins. It makes sense that a user who has 500 BTC in a 12 month old saving wallet should take priority (if need be) over a user who has no bitcoins at all.

Another quick heuristic is to do dialback on connect. One issue with connection prioritisation is that we have to decide fairly quickly and with low resources whether to service a new connection or not. A quick check if the connecting IP is accepting port 8333 would identify not only Tor but all proxy and botnet services    (running custom software on botnets is much harder/riskier than using their predefined services). Of course it’d also identify mobile/NATd users. So we’d want to combine it with the new protocol above and get wallets to implement it first.

Obviously, in a mostly anonymous system like Bitcoin, any heuristic can be gamed by an attacker who is willing to spend enough resources to simulate real users. All we can do is raise the costs.

So with those ideas combined we’d have a pretty nice general framework that doesn’t need any hints about specific IP ranges anymore. But it’d take a lot more work.