Quote from: becoin on May 22, 2017, 01:21:50 PM

Quote from: CoinCube on May 22, 2017, 01:04:16 PM

Quote from: Meuh6879 on May 22, 2017, 12:10:44 PM

Quote from: Asrael999 on May 22, 2017, 08:24:11 AM

So is it an attempt to stop the User activated fork getting traction ?

yes, because the period from august 2017 to november 2017 is the enforced period for Segwit ... not the LOCK period.
https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

so Segwit2Mb is a trap.
they want introduce the 2Mb before SegWit LOCK.

So the folks who want 2Mb don't trust the SegWit people not to break away after SegWit is locked and block a later block size increase?

Sounds understandable given the emotionalism on this issue. It would be very disruptive to activate SegWit and then deactivate it before LOCK. Seems unlikely the miners would do this. It seems far more likely that the SegWit folks would increase their opposition to a block size increase to 2 Mb once they already have what they want.

I am not understanding why this is not a reasonable roadmap forward.

Any block size increase is not a reasonable roadmap forward. It solves nothing! It just postpones the inevitable next block size increase - 4mb, 8mb, 16mb... until full centralization. Big blocktards will accept anything just to follow this roadmap.

This solution is basically just trying to retaliate against UASF by pushing through something suspicious much earlier, but a block size increase with SegWit is not necessarily a bad way forward.

Since Bitcoin started in 2009, the amount of storage which people typically have has much more than doubled. Now it's fairly normal to have 2 terabyte hard drives like one of my computers does, while in 2009 it was very new for that to be conventional.

It's OK for the block size to rise if the average amount of capacity people's computers have raises faster than the size of the blockchain. What's important is that the block size is not flexible and it can't just rise often like it could if BU went through.