> It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue?
Yes, and it seems also out of spite. They could have increased to 2MB in order to avoid the horrible congestion on the network for a couple years. Once that was in place, they could have continued the SegWit work.
In fact, originally, everyone was in support of SegWit. Even the big-blocks camp (we can see that from the New York Agreement, where virtually the whole industry supported both big-blocks and SegWit). The only reason so many like Bitcoin Cash are against it today is because the debate has become emotionally-charged and us-versus-them. SegWit is an all-around good idea.
But the Core developers held out from a blocksize increase because, once they had declared that going from 1MB -> 2MB would be the end of the world, the network would become "centralized", etc, they didn't want to walk it back and simply compromise.
IMO, this is the main reason the ecosystem is migrating to Ethereum. It's not because of the Turing-complete scripting that is possible on Ehtereum, it's because development has been a lot more sane.
Despite the problems they've had (e.g. the DAO), the Ethereum ecosystem is more diverse and professional. They rationally discuss problems and make tradeoffs. They encourage alternate implementations, whereas the Core folks have engaged in baseless fear tactics to ensure theirs is the only implementation on the network[0] (and not talking about protocol changes--simply alternate implementations of the same protocols and consensus rules).
I think unless these leadership problems are addressed somehow, Bitcoin is going to fade into obscurity as others, like Ethereum, lead the way.
[0] https://web.archive.org/web/20160316061949/https://blog.conf...
---
EDIT: Corrected "Bitcoin ABC" to "Bitcoin Cash"
The recent multi-sig wallet hack was due to some bad refactoring by one of the developers on the Parity node/wallet team. Gavin Wood wrote a post about it, and instead of blaming his employee, he blamed himself, that he didn't put enough security into the Solidity language itself. And then he proposed some changes to make it safer.
There definitely was some ugliness with the ETH/ETC fork and controversies, but now we have pull requests from ETC developers that help improve ETH.
There seems to be a lot less ego in the Ethereum developer community. The fighting inside the Bitcoin community leads to attacking other communities too. Whenever there is a setback or hack or just the Ether price drops a bit, the threads are full of Bitcoiners coming in to laugh, attack, 'concern troll'. But you rarely see the reverse. Usually the attacks on Bitcoin come from the people who think all cryptocurrencies are a scam, they target everyone equally. Of course there are exceptions, there are amazing people in Bitcoin and horrible people in Ethereum. I'm just making a broad generalization on the feeling someone gets when reading and talking in their communities.
It's no wonder that Ethereum has the largest developer interest, it's just a really nice place to work.
This is why I agree with Mike Hearn that the "Bitcoin experiment has failed"[0]. In fact it already did so in late 2015.
He makes technical arguments there which you could debate (some of his technical arguments have been shown to be misleading[1]).
But I think where he hits the nail on the head is that Bitcoin is now simply a circus. Unless the community can be united again, it won't last.
The Reddit censorship, DoS attacks, "scaling" conferences where solutions are not allowed to be proposed. It's childish, and almost shocking that people have stood behind their ridiculous behavior for so long, when they are on the verge of changing the world economy.
[0] https://blog.plan99.net/the-resolution-of-the-bitcoin-experi...
No particularly special Bitcoin knowledge is required to figure out why, just careful study of that post with a critical and analytical mind (and not the mind of a "fan"). I wasted far too much of my life dealing with people Peter Todd had deliberately confused back in those years - it's a Sisyphean task that simply never ends if you let it - so I don't wish to write out a long rebuttal now, especially as I don't know you. But see if you can figure it out. Like I said, you don't need me to explain if you study things carefully.
As I said to Peter Todd in that thread, I'm a neutral observer and a fan of both of yours. Having been a programmer for over a decade, it's a shame that even someone like me can get so lost in the rhetoric of this debate.
Thanks for all your blog posts, I point people to them all the time. My greatest wish (something I tried to communicate to Peter Todd) is that Core would write some thoughtful, clear, well-argued posts like yours.
But I suppose it doesn't matter, because as we both agree, the experiment has already failed.
During that crisis it got quite ugly though. Maybe it could be argued Bitcoin is going through a much larger, multi-year ugly period, and that things will settle down and cooperation will happen in another couple years. But many of the people claiming leadership and some of the core developers are outright toxic, and that 'trickles down' into the community.
This statement demonstrates a very shallow understanding of the blocksize debate. There are a large number of reasons to object to any hardfork (causes instability and chaos, breaks compatibility, is a point of control for the people dictating the hardfork, is potentially opposed by many users, no easy way to measure support), and even more reasons to oppose a block size increase hardfork (doubling the blocksize worsens bottlenecks that are already significant, buys only a few months of time, is not a repeatable strategy to achieve real scalability, and the fight seems much more about control and pride than the actual block size - otherwise segwit would have been adopted immediately).
As bitter as the fighting has been, the opposition to a block size increase hard fork stands on very solid ground.
This is dramatically misconstruing the legitimate points made by the anti-big-blockers. The simplest fix would be to say "Others _are content with Bitcoin becoming a settlement layer_".
Making changes is always dangerous given the fact that Bitcoin is fundamentally a consensus-driven protocol. So far, none of the block size proposals has managed to garner a significant consensus. Here I mean "consensus" in a general version of Satoshi's "one CPU one vote" consensus; that's the only consensus here that is resistant to Sibyl attacks.
In addition there's the argument that increasing the block sizes necessarily entails increasing the orphaned block rate, which decreases network security. This happens because the larger the blocks are, the longer it takes for the network to recognize a legitimate block, and thus begin mining on top of it -- any mining that takes place after a block is found is wasted power and does not contribute to network security.
There's also the notion of long-time viability of the decreasing block reward without developing and addressing the problems on forming a fee market to ensure that miner compensation is commensurate with their costs so that subverting the network will always be dramatically more expensive than helping the network.
Finally there's the argument that block size increases make it more expensive to run full nodes by increasing space requirements.
These are real concerns, not just some notion of "increasing blocksize can't solve all problems why even start".
It happens that I disagree with this view; the first argument (forks are tricky) is, in my mind, the only valid one, and if Bitcoin Core threw their efforts behind finding a good, non-gameable, non-spammable block increase implementation, then we could get consensus.
Segwit, which activates on Bitcoin soon, already increases the the block size to ~2MB. Because Bitcoin Cash doesn't implement Segwit, increasing to merely the same size as Bitcoin wouldn't have been compelling.
It's possible for a non-SegWit miner to accidentally mine an invalid block after the soft-fork. Here is how.
The "backwards-compatibility" of SegWit comes from the fact that it looks like an anyone-can-spend transaction. Meaning, on the old blockchain, those coins would be up for grabs.
Nodes that support SegWit know that it is not really an anyone-can-spend transaction, because they have extra data not included in the blockchain.
But a node that doesn't upgrade doesn't know about this. So here's what could happen:
1) Bob sends sends a SegWit transaction to Alice
2) The non-SegWit node sees it as an anyone-can-spend transaction where Bob is basically giving up his coins
3) Eve wants to mess with the non-SegWit node, so she sends it a (valid!) transaction which spends Bob's coins and sends them to Eve
4) The non-SegWit miner mines a block with that transaction, and the block is consequently rejected by the SegWit nodes
So SegWit needs 51% of hashing power in order to work, just like a hard fork. Without it, they wouldn't be able to reject the block with Eve's transaction, which would've been valid on the old blockchain.
The only difference is that the above edge-case exists for a soft fork, whereas for a hard fork, non-upgraded nodes would simply be split into a smaller network instead of being tricked.
Note this is by far not the first soft fork Bitcoin has done. P2SH, CSV, and CLTV for example were also soft forked in. The original design even included 10 blank opcodes designed for soft forking in features.
Yes, what I was pointing out is that in a soft-fork there is a risk of an eventual re-org, whereas in a hard-fork there is not. It's a minor risk, but it exists.
I also believe that any non-SegWit miners will be pushed out of the network using the mechanism I described. It would be pretty easy to trick them into mining invalid blocks.
Actually, since BCC is a hardfork, they can make the Bitcoin Cash spending rules whatever they want. They could have made SegWit transactions totally unspendable if they wanted. They could have made all Bitcoin Cash corresponding to the Bitcoins sent to Blockstream spendable by anyone, etc.
Others want Bitcoin to become a settlement layer, and certain backers have said that $1000 tx fees would be great, since that means BTC won as a settlement layer. This kills the peer to peer aspect though, and end users would rely on offchain third parties to actually get transactions done. This group has fought to keep small blocks, despite recent congestion and increasing fees. The argument is that increasing blocksize can't solve all problems so why even start, and that increasing it even a bit would somehow prevent regular people from validating the chain.
Complicating matters a bit is that some miners have an optimised way of mining, exploiting Bitcoin block header layout to get an optimisation during hash calculations (AsicBoost). This is a 20% advantage but also encourages mining occasional empty blocks. AsicBoost is incompatible with many suggestions of changing the Bitcoin protocol, giving economic incentives to object to such things. This muddies the water.
On the other side, companies have invested a lot into becoming clearinghouses (Coinbase) or inventing ways to do offchain tx (Blockstream) casting doubt on their intentions of killing P2P and making BTC just for settlements.
It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue?