Bitcoin Cash: Why It's Forking the Blockchain and What That Means

And for someone that cannot afford a 100$ drive every 5 years, toss the old blocks after saving a checkpoint and just keep the last X months plus UTXOs?

How does this improve with offchain transactions? What's the point of validating the blockchain if it's no longer a peer to peer network? That can't be any better than validating from checkpoints.

> I understand the reason for a larger block - it seems like it's pure profit for the miners

Bigger blocks = more supply. Wouldn't the cost go down?

Not that it will do them a lot of good, what matters most is what the exchanges and other important economic entities handling bitcoins consider "the real bitcoin", having a majority of nodes won't do much.

There's simply not enough incentives for Bitcoin users to spawn a node so most people prefer to use a light wallet.

Furthermore ~400GB per year is not particularly insane, you can get a 6TB drive for less than $200 and that'll be enough to store more than 15 years worth of blockchain.

As for bandwidth it amounts to less than 14kB/s on average.

>there could be millions per second if micropayments do take off, and that will most likely happen via the channels as described in the lightning docs

Maybe, but I'm a bit surprised that so many people believe that LN will be successful when we have so little data on how it'll actually work. But I'm going to repeat myself, I already explained my concerns here: https://news.ycombinator.com/item?id=14759965 (with some insightful replies).

In particular I can't really imagine how LN could reach a Visa-level number of transactions without having a few mega "nexus nodes" concentrating most of the open LN channels. That would give those nodes some power as they could decide who they pair with (which channels they open) which would be a big blow to the decentralized nature of Bitcoin.

The idea that every bitcoin user would each end up having a handful of channels open and we'd keep routing around the graph (with all the balancing issues it involves) to pay everything seems rather optimistic and aligns poorly with real-world incentives.

It should mean lower transaction fees for users, but more transactions are possible so the miners make it up on volume. Win-win.

> I am fairly convinced at this point that off-chain transactions as described in the lightning docs [1] is the future. The block chain cannot possibly support all the transactions, there could be millions per second if micropayments do take off, and that will most likely happen via the channels as described in the lightning docs.

If you trust your counterparty you wouldn't be using bitcoin in the first place. SegWit/lightning seems to undermine most of the point of bitcoin; certainly moving to transactions happening off-chain would be a radical change and it's not clear it would preserve bitcoin's positives (e.g. decentralization). Whereas increasing the block size is a simple, well-understood change.

Isn't this inevitable? Once demand of anything increases beyond a certain threshold, individuals can no longer supply enough of that thing to satisfy that demand, because they are overwhelmed by the costs of logistics, storage, maintenance and so on.

In the case of bitcoin, I imagine that soon you'll need to have dedicated machines for this task. Not a lot of people can afford to have one - or several, for redundancy - machines to do it.

Hence, the "power" - like in anything else - is in the hands of those that are willing to make a significant investment to keep things running. The payoff for them is that they can profit from providing this service. If I understand correctly, this comes in the form of transaction fees.

Or did you think that bitcoin could rise to the level of, say, Visa or Paypal on the backs of volunteers? Bitcoin isn't even "mainstream" yet, and the network is already buckling.

I think this outcome was more than predictable.

No. You provide no stats, no costs, to justify why 8MB is prohibitive while 1MB is fine. In reality 8MB blocks remain easily affordable. The limit where it starts being quite costly for an individual to run a full node is around 100MB:

https://news.ycombinator.com/item?id=14825934

And by the time we get to 100MB, computing, networking, storage technology will have improved and let us go even further.

[1] https://bitinfocharts.com/comparison/bitcoin-size.html

Let's talk about the realities of Lightning for a minute. Lightning is an interesting technology solution to scaling transactions and settling on the blockchain. But realize that there are significant drawbacks.

In order to spend anything on the lightning network, you need to have funds locked in a channel with a hub. And you can only spend the maximum that is in your hub. Likewise, you can only receive up to the maximum that the hub has put in the channel. In other words, your net credit or debit balance can't exceed the maximum put in by the other side.

There are some significant user experience drawbacks to this approach. I want to send someone $100, but I only have $50 in my channel. So now I need send $50 more of bitcoin and wait 20 minutes for confirmations. Then I can send the $100. It is even worse if I want to receive $100. Now the hub (bank?) has to approve my request to "receive" $100 because it costs them fees and capital to fund the channel. Make no mistake, the hubs will pass these fees on to you, the consumer.

Suddenly this starts to look a little more like Paypal then we want. Granted it is a better version of Paypal - there can be multiple, interoperable hubs - but with small blocks, funding transactions will not be cheap.

In a small block world, Lightning network fees will likely be more than you think. It could easily cost $10 worth of bitcoin for both sides to fund a $1000 channel. Why would I want to tie up $1000 to use this. I'd rather just pay the 3% to send via Paypal.

As space in blocks becomes crowded we should expect transaction fees to grow, and indeed they have: https://bitinfocharts.com/comparison/bitcoin-transactionfees...

If space in blocks is abundant then transaction fees should settle at the approximate per byte cost to the miner of the additional transaction.

I would expect smaller block sizes to be more profitable for miners, all else being equal (e.g. ignoring that high transaction costs make BTC less valuable).

2) 8TB drive is $175 on Amazon. That alone can hold ~1 thousand days of full blocks. That's almost 3 years worth of blocks. By then the HDD prices will likely be even lower.

3) If some regular user will want to mess with the whole blockchain (which is such a strange argument, most don't care for it), downloading 8TB of data takes less than 18 hours on a gigabit connection. It will take years to get to 8TB.

4) There's no real objection to SegWit, as long as it comes with the large blocks. But consider what happened with Segwit2X - as soon as Segwit support solidified, a talk of ditching the 2MB extension started, a classic bait and switch. It's all over /r/bitcoin.

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

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.

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.

Proposals from the core development team have widespread support from businesses and exchanges [1].

Saying it's bitcoin core versus the world is a tad bit hyperbolic.

[1] https://en.bitcoin.it/wiki/Segwit_support

However, I think it's incorrect to say most developers disagree with increasing the block size or a hard fork. Segwit increases the block size, as do hard forks proposed by some Bitcoin Core developers like Spoonnet [1]. There is just a general dislike towards the existing technical proposals.

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...

This topic seems technical but at it's core it is about self interest, fear and money.

That's quite telling, isn't it? There's this huge debate, but his argument is that it's obvious?

From a 'tradition' or 'legacy' standpoint, the blocksize limit was never meant to be a persistent thing. It was not present in the whitepaper or the initial implementations, and when Satoshi added it, it was explicitly stated that the limit should be raised as needed and as computer hardware and network capacity increased. When Satoshi left, the project was handed to Gavin, who has gone to great lengths to support blocksize increase. Similarly, other early developers like Jeff Garzik and Mike Hearn strongly support on-chain scaling. I think it is quite fair to say that the original intention for the limit was simply an anti-spam measure, and was not intended to limit network usage, for whatever that's worth.

Larger blocks require more cost to run a node. It costs more network capacity, more storage, more time to spin up a node, etc. The argument is that these costs will decrease node count to a dangerous degree. More network use could, however, create incentive for more people to run nodes. Clearly there's a trade-off between extremes, so a careful consideration must be made about where the best trade-off occurs.

Larger blocks are a liability to miners as they increase the chance of orphaned blocks. This has two primary effects: it places a natural limit to the block size miners are willing to mine, and it creates incentives for miners to have excellent network access to the rest of the network. This later issue can mean mining centralization. This is one of the core arguments against increasing block size, but it's a very complicated issue. One of the primary confounders is ASIC development, which means rapid capital turnover and short investment timelines for mining. As ASIC development reaches state-of-the-art node sizes, and also as the Bitcoin price stabilizes, mining investment looks very different. This is very difficult to predict.

Small blocks greatly limit what Bitcoin can do. It places a hard cap on transaction throughput. The formation of a transaction fee market greatly discourages small transactions, making Bitcoin inaccessible to a wide range of people. It makes any address with Bitcoin less than the txn fee effectively unspendable. In the extreme, it limits Bitcoin to the role of digital gold, a speculation vehicle with little use as a medium of transaction.

There are two big open questions:

* Will larger blocks lead to dangerous centralization?

* Will 2nd layer solutions provide effective scaling solutions?

In the end, all of this deals with trade-offs, but worse, trade-offs with difficult-to-quantify risks at either extreme. I simply would not trust anyone that is dogmatic about their favored approach.

My personal view is that the conservative approach with least risk is to permit moderate blocksize increases while 2nd layer solutions are being developed, and to continue the debate as the network develops. This is, in effect, exactly what the '2X' compromise does.

Exactly what power is that? The power to collect smaller mining fees?

Honest question - what's the status of Lightning? Core promotes it as the solution to scaling and it's essentially a page on github. Litecoin already has Segwit and no one is using Lightning. Am I missing something here?

What they're trying to say is they'll support multiple implementations of the software on the same network (unlike Bitcoin ABC, which is a fork of the software and a fork of the network).

But Bitcoin already supports that too. There is bitcoin core, bitcoin knots, bitcoinj, btc1, bitcore all running on the same network.

I don't think it happened on any meaningful chain. It could be donetechnically through a proof-of-burn on the giving chain, and the corresponding minting on the receiving chain.

Something loosely comparable would be conversion from a token to another within the same blockchain, and this must have happened quite a few times on Ethereum; but that's within a single blockchain, so arguably doesn't count.

However when you see how difficult it is, in terms of governance, to address such an obvious issue as Bitcoin's tiny throughput, I can't imagine two distinct chains agree, in a timely fashion, both on the principle of a merge, and on the way to execute it. Maybe on-chain governance, as proposed by Tezos, will fix this problematic indecisiveness on blockchain evolutions, we'll see.

Also, altcoins present a real competitive risk; failure to maintain an advantage over them will see network value approach zero.

If you think that the price will first crash and then bounce, you might want to sell your stash and then buy it back at a lower price. To keep the price up it wouldn't be enough to have many who wait and see; you also need lots of buyers for all the BCC that will be sold by those who have BTC and will want to get something out of their BCC as soon as possible.

If you care about one token over the other, the best thing to do is let the dust settle, then sell all of your non-preferred token for the preferred token. Financially, this should not set you back even if you prefer the minority token - you just end up with a bunch of them, and the total value of your wallet is still about the same.

Bitcoin isn't worth $2500 per Bitcoin by magic. It's worth that because of supply and demand.

The only change might be that some of the demand shifts to BitcoinCash instead of Bitcoin, meaning the price of both will be lower than the price of Bitcoin now, but they'll likely add up to about the same amount.

I'm hoping it decreases the overall level of conflict, as both groups will be able to get what they want here.

Here's what they say: https://support.coinbase.com/customer/portal/articles/284421...

Notably:

> Coinbase will not support the new blockchain or its associated coin.

Now would be a good time to get your BTC out of Bitstamp, to ensure you get access to your BCC coins when the fork takes place.

Who would want tx malleability?

But don't trust any third party with your coins, especially Coinbase which isn't sharing the private keys with you.