ok to draw this together
It seems
[1] a 2MB block
No.
[2] quadratic solution of some type and :: [segwit and flex trans seem to have some options]
Yes.
[3] maybe compression :: [segwit and flex trans seem to have some options]
No, Segwit does not change space efficiency, and flextrans is not even a serious proposal
may be a dialogue that most parties could agree on::
Could this form a backbone to the discussion going forward?
Stripping away the emotive which may be justified but deleterious, reaching a compromise and consensus, where cooler heads prevail.
The miners, the devs, the userbase, exchanges, etc, all these parties can show now if you wish the way forward/
Sure there will be testing and things at the margins that due to unseen issues or tech requirements need to fall one way or the other.
Can we have this accord?
No.
You're not listening, and you're mis-representing the case for improving space usage (which is the only form of scaling possible) so badly, that it's not easy to take your assessment seriously as a compromise proposal. You're also advocating a 2MB base blocksize hardfork, it's been rejected twice already (XT & Classic), and would involve an 8MB total blocksize when one factors in the corresponding witness blocksize. No.
Remember:
Segwit is already a significant compromise between big blocks and 1MB forever. I'm somewhere in between big blocks and perma-1MB, and I am willing to accept Segwit, despite it's 4MB total blocksize being a concern to me.
What's happened is that the big blocks proponents just will not accept the 4MB Segwit blocksize increase, and keep pushing and pushing and pushing for as big a blocksize as they can, and never compromise anywhere (and also never hardfork the blockchain as they have constantly threatened for 2+ years). Your "compromise" just falls into the same category of rhetoric, and it's unpalatable for well grounded and argued technical reasons.
Firstly I genuinely appreciate the time you took for your input.
I am unaligned excepting as to detrimental stagnation (if this exists). I am doing this as an exercise in the search of truth.
I perhaps should not have said segwit or flextrans, so I withdraw them.
Lets take them out of the argument as they are clearly anchored to a lot of baggage.
I should say or rather recast as this a code solution that is acceptable to most parties,
Part of this seems to be to show on major part of the argument we are willing to look as an implement
[1] blocksize change,
[2] quadratic solutions, and compression of data if this can be achieved.
[3] +/- compression [if it make it easier to agree throw it out]
The 2MB is to say we are willing to the concerned party we as community are prepared to increase the block size and sets the precedent for the future, its just shifts to a matter of degree, in the circumstances and cost of the tech of the day and the risks of over centralization, that is what I was trying to get across.
