To be sure, Blockstreamers only now are coming to realize that an increase of the effective block size limit to 4 MB will have the unexpected and unwelcome consequence of increasing the effective block size limit to 4 MB.
Jesus christ at least get your FUD right.
Fully validating nodes will effectively be moved to 4MB max... something you guys have been fighting and #rekking for many months now. The irony of your gracefully fluid position is lost on most observers, but not all.
So Luke has already proposed to keep the 1 MB limit for the total block size, including the segregated part.
Provide quotes or GTFO.
[]luke-jrLuke Dashjr - Bitcoin Expert 6 points 2 hours ago
Hmm, problem here is that CPU usage is not the primary bottleneck for block sizes: bandwidth is. And unfortunately, SW doesn't help in the bandwidth area at all. So while I do think we should take this opportunity to get the block size changes softforked in instead of hardforked (buying us a bit more time before a hardfork is required?), it does still need to be gradual and not just 4x at once.
My suggestion is to go based on either BIP 103 or John Sacco's double-the-limit-every-subsidy-halving idea.
Admittedly, he didn't literally say keep 1MB effective max, but if you get 4x from SegWit, you would actually have to soft fork lower on the max block size to keep luke happy. At least that's my reading.
But they should not worry, since the space savings will only occur if the clients start issuing transactions in the new SW format. Which will not happen right away, if SW is deployed by soft fork. And even after the clients have upgraded, the use of SW will be optional. Will there be incentives for the clients to use it?
No, regular transactions get a 75% bump in space.
Could you explain the math behind the 75% "bump" you state here?