I'm not sure why SegWit is put forward as a "scaling solution". It does make some room by moving signature data out of the main block, which may allow 2.5x as many transactions - but thats a one time improvement, afaict.<p>The real problem is simply that the blocksize is way too small. At peak daily loads we are trying to put 20MB of transactions into a single 1MB block. Of course the unprocessed transactions pool up in the 'mempool' waiting for the next block, and are eventually cleared later in the day in off-peak times.<p>The reason they don't just pool up indefinitely, and crash the server, is due to economics - people pay higher transaction fees to get their important transactions into the next block. Miners earn part of their income from those fees, so they put the best paying transactions into the block first.<p>Most people who might like to use Bitcoin to pay for actual things, will balk at paying 3$ to send 500$, which means less people use the system, or they only use it for important big trades - thus, an equilibrium is set up where transaction volume is kept low.<p>Keep in mind bitcoin blocks occur on average every 10 minutes. A global rate of 3 trans/sec is clearly not a large number for a system used by millions, all across the globe.<p>Litecoin has the same architecture, but doesn't have this bottleneck problem - they have 3/4 the blocksize, process 4x as frequently and handle less that 1/10th the volume of transactions. So there is no mempool, fees are low etc.<p>The max blocksize is set to 1MB in code [ think #define or static const ], so increasing it means releasing new software - old versions will not be able to process large blocks, so this means a "hard fork".<p>I would argue that a blocksize increase is urgently needed and justifies a prudent hardfork - because it is currently preventing Bitcoin from growing. Not only do we need a 2MB block yesterday [ some say 8MB ], but we need a clear block size upgrade schedule for the next few years so Bitcoin can handle steady growth, without the need for many future hardforks.<p>Blocksize increase over the next few years could yield a 20x to 200x increase in throughput using the current architecture ... this releases the stranglehold on transaction flow and user growth, and buys time to build out all the other nice new technologies that can augment, or scale beyond, the linear architecture of the blockchain.<p>This issue has been delayed and debated for 2.5 years, so now it really is urgent and people on both sides are pretty angry. Sadly, its metastasized into an ugly political civil war .. but I think at heart it is a fairly normal engineering issue that could have been resolved routinely. Maybe having a ton of cash riding on your code makes easy choices hard.