8 ms·
I think you understate the cons of the on-chain solutions. This said as a big-blocker myself. I think the size of the node is a consideration, but not a huge
by andrewla 9y ago
I think you understate the cons of the on-chain solutions. This said as a big-blocker myself.
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.