Quote from: BitUsher on February 19, 2016, 12:48:07 AM

It is surprisingly small ... He elaborates the number of lines of changes in the original XT proposal exceed Segwit changes .
This is a fair comparison because most of the XT supporters are now classic supporters insinuating that Segwit is a massive change when they were will to accept (in some regards- loc) a larger change before.

Quote from: adamstgBit on February 19, 2016, 12:28:25 AM

he says that its safer to do segwit then change the MAXBLOCKSIZE define

trud manure, every word, trud manure

In many ways(not all) segwit is indeed safer than simply increasing maxBlockSize. It doesn't involve a contentious hardfork(99% of people support segwit in itself ) , it allows for signature pruning which reduces costs on the network = safer , Fixes most Malleability issues= safer, creates a Linear scaling of sighash operations = safer, allows for safer deployment of softforks in future, Reduces UTXO growth , ect....

This is the changeset for SegWit:

https://github.com/bitcoin/bitcoin/pull/7404

I seriously encourage anyone to have a little browse after being told this is the safer, simpler option.

A form of segwit could/would have tangible benefits, but it's being sold in an underhanded way. As a carrot when the network needs more capacity... and in current form, is designed in a way that applies economic favoritism at the protocol level with fee discounts.

If a small increase of maxblocksize was implemented first as a HF, or if they were hardforked together, nearly all of my concerns would be assuaged. I would still argue against favoritism in the fee economics... but I would instantly become much more agreeable generally. As long as a HF is slated way off into 2017... if at all (Gregory's current roadmap), I will remain distrustful of Core's leadership and their conflicted interest in forcing the settlement layer architecture.

If things have changed and a hard date for a hard fork is promised in 2016... our disagreement is much closer to resolution.