Comment by Bae8anoh | Hacker News Reader

Comment by Bae8anoh | Hacker News Reader

Parent Full thread

Read up on the history of Mike Hearn, he has wanted to fork Bitcoin into his own governance for years, this is just an excuse.

In 2011 he was proposing to Satoshi that he should take over the project[0], in 2013 he was trying to pitch the concept that development was stagnant and that a fork was needing to fix it[1][2], and now in 2015 it's again come about that he has found an excuse to attempt it (this time with some mild enthusiasm from part of the community). In the past Mike Hearn has pitched censorship features in Tor[3], attempting to subvert the inclusion of privacy fixes in Tor[4], proposed "redlists" of supposedly undesirable transactions in Bitcoin[5]. The current branch of Bitcoin XT already includes an alarmingly ill advised hardcoded blacklist of supposedly Tor exit nodes which are de-prioritized[6].

The measure of "consensus" has already slipped down to 75% when it become clear that 95% of the hashrate was never going to happen. The solution from Mike Hearn is that if miners don't want to get to 75%, he will simply hardcode his own centralized markers into Bitcoin wallets[7] to make sure it happens regardless. This is unbelievably toxic stuff, and spells certain death of Bitcoin if it goes ahead.

[0]: http://pastebin.com/raw.php?i=3kt5Reeh

[1]: https://www.reddit.com/r/Bitcoin/comments/29qafs/circle_ceo_...

[2]: http://www.coindesk.com/bitcoin-core-development-falling-beh...

[3]: https://lists.torproject.org/pipermail/tor-dev/2014-July/007...

[4]: https://lists.torproject.org/pipermail/tor-dev/2014-July/007...

[5]: https://bitcoinfoundation.org/forum/index.php?/topic/505-coi...

[6]: https://github.com/bitcoinxt/bitcoinxt/blob/73c9efe74c5cc8fa...

[7]: http://sourceforge.net/p/bitcoin/mailman/message/34162353/

I was ready to be persuaded by your first statement: "In 2011 he was proposing to Satoshi that he should take over the project[0]", but then I actually clicked through the link you provided and, while expecting some shocking revelation, I instead found what seems to be a solitary email sent to the ether so to speak and a very reasonable email too at that.

This "attack" on someone who worked for google as a network engineer, who has contributed to bitcoin for years, who has given us SPV wallets and a million other things, in this forum out of all places, sounds desperate.

Welcome to a Bitcoin discussion.

Anyone can "fork" bitcoin.. No one will accept their fork, but they can go right on and do it. This is my first hearing of Mike Hearn, but I don't understand your attacks on him. For one, I'd be ok with Tor traffic being de-prioritized in an attack since that is commonly where an attack is coming from anyway. The centralized list is concerning, but de-prioritization rarely matters anyway (ie, outside of when the network is attacked) All of his other proposals are just that, proposals and "lets talk about this and the problem". I hate to think if I proposed/discussed a bad solution to a problem and suddenly I'm part of some conspiracy theory.

> For one, I'd be ok with Tor traffic being de-prioritized in an attack since that is commonly where an attack is coming from anyway.

The hardcoded list of "bad" peers is effectively worthless (it's already hopelessly out of date), and the additional service which downloads a new blacklist from a centralized website is completely insane. The reality of the situation is that if anybody with criminal intent wants to attack the Bitcoin network you need exactly two IP addresses (one v4, one v6) to completely disable all new incoming connections on all nodes in the network. This patch doesn't change that fact, nor that criminals often have botnets with unlimited access to new IP addresses every second of the day.

It doesn't achieve the stated design goal, and introduces new vulnerabilities which aren't stated in the commit.

> All of his other proposals are just that, proposals and "lets talk about this and the problem". I hate to think if I proposed/discussed a bad solution to a problem and suddenly I'm part of some conspiracy theory.

Bitcoin isn't like any other software on earth, it can't exist in fragmentation or in consensus incompatible forks. Operating on a fork of the software with soft consensus changes or simply operational changes that do not affect consensus are completely fine, that happens today under the assumption that you are somewhat at risk if you run software that is even slightly different to anybody elses. Some nodes in the network for example support different P2P commands, and that's fine because the P2P network is not part of the consensus at all. The linked discussions are mostly harmless, it is extremely positive that all scenarios and eventualities are debated out in the open.

Prompting companies and individuals to attempt a hard fork of the network without consensus is another matter entirely. In the light of that, the previous discussions lose their innocence somewhat.

Oh dear, you have some serious anger issues, don't you?

I have not wanted to fork Bitcoin for years. I still don't - I have many better things to do, like working on Lighthouse or oh .... really anything else. Screwing about with gitian and gcc all day is right at the bottom of my list of "fun things to do on a sunny day".

But the fact that Bitcoin Core was heading for disaster was obvious for a long time now. It has been progressively abandoning things that the user community finds important: SPV wallets, unconfirmed transactions, now even the notion of growing the platform at all have all become "controversial" and therefore untouchable. Anyone who suggests that maybe these things are useful is immediately branded an idiot. Combine with a maintainer who hides any time a decision is needed and you have a recipe for deadlock.

You seem to think I hate Tor. I am actually the maintainer of a full blown Tor implementation (Orchid). I've done a lot of work on integrating it into bitcoinj and I'm basically the only guy who can actually move the needle on Tor/Bitcoin usage, by enabling the use of it by default in consumer wallets that have hundreds of thousands of installs. We're not there yet (it's still too slow) but we're a lot closer than before.

This doesn't change the fact that Tor is heavily abused. It can be useful but it's a frequent source of attacks of all kinds. So finding ways to get the good without the bad involves some tricky coding.

Below, you say "anyone can jam the network with just two IP addresses". Yes, that's unfortunate isn't it. I've been sounding the alarm about Bitcoin Core's poor DoS protection for years. Nobody listened, that's why I have now written a new anti-DoS system that can handle this sort of thing. It starts by clustering and deprioritising Tor because we've seen actual jamming attacks that came through Tor, and because using it is a lot safer and more convenient for an attacker than using your own IP addresses or using a botnet. But it absolutely should be extended to have more advanced heuristics. Instead of whinging that (gasp) loading a file from a web server is "insane", maybe you should be writing code instead.

I'm not angry, I'm saddened that you are going to destroy the only functioning distributed consensus because you can't see that the ecosystem is already bleeding under the weight.

Core has been moving away from failed experiments like unconfirmed transactions. (How that wasn't an obviously flawed idea in the first place is beyond me, but hey, might as well get the data..)

No one in core is saying that growth is a bad thing and must be avoided, the key point that has been repeated is that the approach you and Gavin took with XT was not a good one. It has been poorly thought out from the get go. The initial proposal contended that we had to go to 20MB or we were doomed, remember that?

Bitcoin needs a steady hand at the wheel. Wladimir and co are putting out a solid amount of code with remarkably little disruption.

Your statement re: orchid is a little misleading. You might be a maintainer, but https://github.com/subgraph/Orchid/commits/develop shows that your contributions are minor. https://github.com/subgraph/Orchid/graphs/contributors

Why do you continue to cause this degree of public spectacle and unnecessary drama?

Orchid is developed in the bitcoinj tree these days, not the subgraph repository. Upstream imported changes one time, but I continue to handle it on a day to day basis.

Unconfirmed transactions are not at all a failure. The data is in - usage of them has been increasing over time, not decreasing. When someone attacked shapeshift.io (an exchange that uses them!) and double spent, their response was "We get significant value from fast payments, we can easily patch the exploit they used, and we're going to continue with our current path".

The initial proposal was not "20mb or we're doomed". It was "we need more space or we're doomed, 20mb seems to work OK based on <reasons>". But lowering it to make the Chinese pools happy is not a problem, as it's an upper limit.

I'm afraid the drama has all been created by others. The limit was always meant to be removed, remember? We're not the ones suddenly trying to change the plan.

And Mike's a nice guy whose done a lot for bitcoin adoption. He's also passionate and persuasive.

Not all his ideas are good, but he's earned the right to be listened to in the bitcoin space.

Reply on news.ycombinator.com