Hacker News Reader

Everything you said is correct AFAIK.

> 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"

> 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.

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.

I'd like to comment about something I realized when reading your post. About the difference between the Bitcoin development/community and the Ethereum one. If you want to completely oversimplify it, the Bitcoin community appears to be full of fear, anger, attacks and competition among themselves. While Ethereum seems to be compromise, inclusion, discussion, working towards a greater goal. You see a change proposed, and one developer comments that they think it's a bad idea for certain reasons. Then after a month of discussion he will come back and say that, yeah, I was wrong, it's actually a good idea.

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.

Exactly. To make an analogy, consider what would happen if the president/congress appointed an incompetent fool as the chair of the Federal Reserve. The whole world would lose confidence in the dollar, and another currency would take over.

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...

[1] https://news.ycombinator.com/item?id=14833567

I rarely comment on Bitcoin these days, although I do still read things about it from time to time. I realise we're mostly in agreement, but on the technical arguments I'd like to briefly defend myself here - the arguments I made were not misleading or dishonest in any way. It's rather the post you link to which is.

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.

Thanks! I will certainly re-read it.

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.

There's also no shortage of the Ethereum community patting themselves on the back too. The Ethereum community isn't toxic because it hasn't encountered serious questions about the future of the protocol yet and the price is constantly going up (in the medium/long term).

I'd say the Dao hack and fork was a very serious question, getting right down to the entire point of a blockchain itself, immutable or not. And the fact they are now able to work side by side (eth/etc) on some code issues is a very good indication on how the dev community there works differently.

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.

Right. I've been describing it like this: That Bitcoin doesn't have a Good King anymore (Satoshi). Ethereum has Vitalik, and Linux has Linus. Projects with a Good King typically defer tough decisions to the king, and the project is (usually) overall better off for it. But with Satoshi gone, everyone has their own ideas about what's "best" for Bitcoin, and there is no unifying force. Ethereum development is sane because Vitalik is heavily involved in it. I believe that is why Ethereum will succeed over Bitcoin in the long run.

All good kings eventually die. So projects without a good king are more future proof if they survive because they have already priced that reality in. The other projects could very well collapse once their good king dies.

Perhaps. But which project is more likely to survive into the future: Bitcoin, or Ethereum? I think having a good king steers a project well enough to future-proof it in most cases, if for no other reason than that it's engineered better along the way.

> 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 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.

>It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue?

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.

Increasing the block size is a fundamental change requiring a hard fork and a chain split. It is not possible to continue on the same chain with a 2mb block. However, they could continue on the same chain with segwit which gives the rough equivalent of a 1.7mb block. Unfortunately, that wasn't enough for the other side (+lots of other reasons, valid or not, I couldn't say).

Don't be fooled into thinking a soft-fork is the "same chain". It simply tricks nodes that don't know about SegWit into validating transactions that they don't really know how to validate.

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.

Let's see if I understood this correctly: once the network splits into BTC (with SegWit) and BCC (without SegWit), if someone spends an old BTC coin (where old = from before the split) using SegWit, anyone can "steal" that same coin on the BCC "mirror universe"? Sounds worse than merely replaying a transaction from one chain into the other. That's so going to be a mess.

Correct, though this isn't really anything special about SegWit. If BCC had forked right before Bitcoin added P2SH for example, the same would have resulted from P2SH transactions.

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.

Not quite, it needs 51% of hashing power in order to be safely backwards compatible with non-upgraded nodes, however it's always safe with upgraded nodes. That's the reason BIP9 has a 95% activation threshold.

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.

> 51% of hashing power in order to be safely backwards compatible with non-upgraded nodes, however it's always safe with upgraded nodes

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.

The argument is that higher cost of node operation is actually what kills the "peer to peer aspect." Trustless second layer networks such as Lightning use "third parties" to route money across the network, but never in a trusted/custodial fashion.

The lightning network works just fine as a daily transaction layer. Increasing the block size would never work as a large scale transaction system because the block size would have to grow to 100s of GB a day to reflect even a small percentage of total transactions. It's a short term hack that creates problems down the road.