Comment by Taek | Hacker News Reader

Comment by Taek | Hacker News Reader

Parent Full thread

The people responsible for writing 90%+ of the code changes to Bitcoin since 2013 are all heavily in favor of SegWit, and heavily against Bitcoin Cash and also against SegWit2x. These guys are the researchers and engineers with the deepest understanding of decentralization, game theory, and adversarial blockchain design.

The most politically active exchanges, miners, and payment processors are all in favor of SegWit2x, and against the bitcoin-core developers. These are the people who are most familiar with business, who are closest to the userbase, and have to deal with the practical problems associated with running Bitcoin businesses in ways that the core developers do not. At the same time, they often miss significant security and stability risks in the changes that they propose.

A small faction of highly passionate users with relatively deep pockets and effective social media skills favor Bitcoin Cash. This group passionately distrusts the bitcoin-core developers, has a strange vendetta with the EFF-commended company Blockstream, and is the source of a large number of conspiracy theories. This is the same group that passionately backed the failed Bitcoin-XT project, the failed Bitcoin-Classic project, and the failed Bitcoin-Unlimited project. Their following I think was largest during the Bitcoin-Classic days, but at this point I think they've disenfranchised a lot of their early community members with their stubborn anti-bitcoin-core rhetoric.

What does the difference between SegWit and SegWit2x amount to? Is it just the difference in block size limit? As I understand, they’re practically in agreement on the limit, but not exactly, thus risking a fork because of a relatively tiny discrepancy.

SegWit2x contains a hardfork that brings the block size limit to 2mb. The primary point of contention with SegWit2x is the fact that it introduces a hardfork, something that most developers very strongly oppose.

A secondary concern is scalability - SegWit already increases the burden for full nodes in terms of bandwidth and storage by doubling the practical capacity of the blockchain, and quadrupling the max size if miners are being abusive. SegWit2x quadruples the practical capacity of the network, which quadruples the burden of running a full node. And attackers now have 8x the wiggle room for attacks. I don't want to dive deep into the details, but there are a lot of reasons to be concerned about this.

1. Why do most of the developers strongly oppose a hardfork? Isn't that primarily an economic issue (i.e., is it good for the price/ecosystem for there to be warring factions), or is there some technical concern I'm missing?

2. You seem to be well-informed and (which can be rare in this space) cool-headed. Any recommendations for the best readings/websites/forums/users to follow, with a high signal-to-noise ratio?

Thanks.

There are two very good reasons to oppose a hardfork, and then a bunch more besides. I think that I would say the best reason to oppose a hardfork is to protect yourself against political manipulation. The whole point of Bitcoin is that it's money that nobody controls. Hardforks introduce decision points that people can have control over, and they can use political leverage to get things out of the hardfork that you may not like. Especially if the ecosystem becomes accustomed to hardforks, it gets a lot easier to introduce changes which are supported by popular opinion. As we know from Trump, popular opinion is not always what you want to be directing your future.

There's also a fantastic non-political reason, which is compatibility. As we know from IE6, Windows XP, outdated versions of Flash, IPv4, and lots of other things in software history, industry wide upgrades take a loooong time. When you hardfork Bitcoin, you are introducing a change that is only successful if 100% of people upgrade. That's a really high bar. If someone or some company does not realize that there's been a hardfork, they are sitting on an old, vulnerable chain and don't realize it. Everyone who doesn't upgrade is vulnerable to accepting payments that they think are worth 1 btc, when they are actually worth 1 btc-old, and btc-old may have a dollar value that's only a few percent of the btc price.

When you hardfork, you force everyone in the ecosystem to upgrade. This causes a lot of friction, breaks compatibility with existing software, and really reduces the value of your ecosystem substantially because you lose a lot of legacy code and hardware and systems that may no longer be compatible with the post-hardfork chain.

As for recommendations, honestly there's not much I can do to help. All the major places that I know of have been overrun by people who think they know a lot more than they actually know. There's also a lot of brigading in general, though I think the fundamental problem right now is an ecosystem-wide Dunning-Kruger effect, and I think it'll blow over once the ICO mania matures more.

If you really want some good stuff, look for anything posted to a mailing list or to IRC by Greg Maxwell. While his reddit comments are often petty, he's probably the most intelligent person in blockchain today. Take everything he says with a grain of salt, but even if you don't like him you will learn a LOT by reading everything he's posted over the past 2-5 years. Other names worth following (not a complete list, sorry to anyone I miss) would be Pieter Wuille, Peter Todd, Luke Dashjr, Eric Lombroso.

>These guys are the researchers and engineers with the deepest understanding of decentralization, game theory, and adversarial blockchain design.

These guys don't have the deepest understanding of any of those things. The minutia of the protocol, and the source code that implements it, is extremely important, but knowledge of it does not impart one with any insights into game theory, the political implications of different decentralisation tradeoffs, and adversarial blockchain design as it pertains to political/economic attacks.

I beg to differ. These guys have spent the whole of their professional careers discussing various tradeoffs, attacks, and sources of attack surface as related to decentralized blockchains.

I guess a statement like yours and a counter like mine is difficult to back up with evidence, but if you look for some of the technical debates realted to SegWit, Bitcoin Unlimited, Bitcoin Classic, Emergent Consensus, etc, it's pretty obvious that the bitcoin core developers are well ahead of their opponents even in the realms of economics and politics.

Bitcoin has a lot of defenses to manipulative politics in place already, including the fact that it's intentionally very difficult to hardfork the newtork, and including the fact that releases follow a fixed schedule (which makes it much harder to shoehorn in features).

The characterization that the core devleopers focus primarily on code and traditional software engineering falls far short of the reality.

The amount of time they've spent discussing and analyzing these things has nothing to do with their contribution to the source code. There are plenty of people who have spent thousands of hours discussing the various trade offs, attacks and sources of attack surface and have not contributed to the Bitcoin Core client github repository.

>The characterization that the core devleopers focus primarily on code and traditional software engineering falls far short of the reality.

That wasn't my characterisation. I disputed your characterization of the Core contributors being the most knowledgeable on these game theory aspects of security based on their contribution to the source code.

Reply on news.ycombinator.com