Bitcoin Is Having a Civil War as It Enters a Critical Month

Bitcoin as a high throughput transaction network for buying things like coffee is not a good goal. It should be for much larger transactions, but optimized for decentralization and sound money.

Derivative blockchains can be spun off of Bitcoin, and settled periodically to the "reference" blockchain, which is Bitcoin, through lightning networks or other off chain developments (perhaps some sort of forked derivative pegged chains).

Bitcoin only has value as either a distributed non-centrally controlled international settlement network for countries and large banks [0], and/or as a digital Gold.

Optimizing this value out of bitcoin to achieve transaction throughput destroys the necessity of Bitcoin for existing.

Bitcoin proper should remain resistant to change, distributed, unable to be coopted or controlled by a few organizations, and above all, to have the properties of sound money (so resistant to changes to expand the money supply). If it doesn't have these qualities, it has no reason to be valuable. It cannot be all things to all people, but it can to "one" thing very well.

[0] https://thesaifhouse.wordpress.com/2017/05/19/economics-of-b...

I think the size of the node is a consideration, but not a huge one -- before we started butting up against the limit, blocks were naturally much smaller than the 1MB limit -- the fear of spam and dust transactions never materialized, so there's no reason to expect that the economics are fundamentally different now.

The biggest con by far is the hard-forking nature of the change. Changing the limit means that clients will have to accept blocks that they currently don't accept. This applies to core, of course, but also to the innumerable other implementations of the bitcoin protocol. Don't make the mistake of thinking that core is the only player here -- a hard fork is trouble for everyone, miners included, and has a substantial risk of causing two viable chains to appear, which is much more of a disaster for Bitcoin (because of how long it takes to adjust difficulty) than it was for Ethereum. With sufficient consensus, this becomes less of a problem for the same reason -- the defunct 5% chain (with 95% consensus) will take 280 days to converge on a new difficulty, during which time that network will be extremely congested. But if miners are misconfigured, etc., even if there is consensus there may be an unintentional hard fork.

The second biggest problem is the rise in the risk of orphaned blocks. This, I think, is probably what holds most miners back -- the longer it takes to transmit and verify a block, the greater the chance of a block being orphaned is. Orphans hurt the security of the network by making it so that a smaller fraction of the net hashing power is actually being applied to the problem of securing the network. As much as people complain that the proof-of-work is "wasteful" in the ecological sense, wasting even that wasted work would make nobody happy.

Segwit, on the other side of the debate, has the attachment to off-chain scaling, but also offers a solution to transaction malleability, which is a huge problem for bitcoin businesses as it can be difficult to tell whether a transaction ever made it to the network, much less rely on features like child-pays-for-parent. Since the current version of segwit is a soft fork, it should, in theory, work with existing non-core clients, and the Litecoin adoption should give us some information on how that works in practice, but Litecoin doesn't have nearly the adoption that Bitcoin does, so it's hard to generalize.

I'm curious if you have some sources on this -- most of the anti-big-block claims that I have seen tend to settle on the hard fork being problematic, which is a very legitimate criticism (thought I need to dig up citations to play by my own rules here). There's also a significant group (I think unaffiliated with Core) that worries about the increase in orphanage that big blocks can lead to.

You're correct. However, I'm fairly sure OP was talking about Segwit (with 2x).

If most users/exchanges/services don't get on board by the time the scheduled segwit2x hardfork happens, then those blocks would be considered invalid.