> If all users start using segwit addresses and segwit transactions SegWit blocks can vary from 1MB in non-ideal conditions to near 4MB in ideal conditions. 2

> If all users start using segwit addresses and segwit transactions SegWit blocks can vary from 1MB in non-ideal conditions to near 4MB in ideal conditions. 2MB is just the average. You're right, yes, ideally we'd want everyone using SegWit transactions. But we don't need all users to start using them to start seeing congestion relief. I would expect 90% of transactions are generated by 10% of Bitcoin's users. Maybe even more skewed than that. (That 10% is likely businesses, power users, etc). Getting those 10% to switch to SegWit transactions will be relatively easy; they'll feel the value of reduced fees more readily. It's likely Bitcoin Core would start using SegWit addresses by default some time after SegWit is activated. Since the majority of users use Bitcoin Core, the shift wouldn't take too long. > hardfork would solve that issue immediately - no need to upgrade wallets, no need to figure out how do segwit-inside-P2SH addresses work (they are different from normal addresses!). Hardfork _does_ require upgrading wallets. In fact, it requires upgrading _all_ wallets. Anyone who hasn't upgraded cannot participate in Bitcoin any longer if a hardfork is used. Contrast that with SegWit. SegWit doesn't require that everyone upgrade. And yet everyone will benefit from the increased block capacity, even those not using SegWit addresses, because the fees overall will go down. > Again nobody knows. Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. The plan was for SegWit to activate, providing a more immediate ~2MB increase in block size, and then mid-term we'd see things like the lightning network come online and provide further relief. Long term developers would continue improving network efficiency which means the existing blocks can carry more transactions, and also eventually a hardfork to add some mechanism for increasing blocksize (that doesn't require further hardforks). > Well, that's a matter of "policy" I didn't mean that SegWit transactions were inherently cheaper in terms of fees. Sure, fees are always policy. But, AFAIK, SegWit transactions are actually cheaper in terms of network load. The discount on SegWit transactions is not just to expand the blocksize; they're also discounted because they put less strain on the network compared to old-style transactions. EDIT: And to be clear, the SegWit discount we're talking about is a discount on the weight of a SegWit transaction's size in calculating the total blocksize. AFAIK, there is no fee discount on SegWit transactions; they pay the same per byte fee. SegWit2X has no way to remove that discount without changing consensus rules. So that specifically is not a matter of policy; it's matter of consensus. It would thus required another hardfork to change those rules.