Appealing moderator's decision. If my post was off-topic, then so is the whole thread. As for content-heavy, I made a very specific compromise proposal that I'd like to bring to the developers attention. If this isn't the place to do that, then I don't know what is, but I'd be happy to repost to a different forum if you can suggest one that is more appropriate.

===


It looks as if there has been movement on both sides of this debate and the outlines of a potential medium term truce are starting to appear. Given the enormous amount of unrest this whole debate has caused I think it would be highly desirable if both sides could reach an honourable compromise that's ready to be deployed next year.

I'd like to make a compromise proposal, made up of of uncontroversial elements of other proposals.

It is intended to achieve the following goals:

- Discourage a potentially disastrous contentious hard fork and consequently only activate with overwhelming community support.
- Provide immediate relief on both fees and growth potential once activated.
- Provide immediate reassurance that there won't be radical growth for a number of years without another hard fork.
- Lock in a temporary modest growth path that goes meaningfully beyond BIP 102 so we have at least a few years worth of certainty for those who want growth.
- Be no more than a kick-the-can-down-the-road solution and do not rule anything in or out after an interim period of a number of years.
- One-off activation vote to avoid uncertainty hanging over the market indefinitely.
- Be as simple as possible to allow for the earliest possible deployment.
- Be as uncontroversial as possible to allow for the earliest possible deployment.
- Do not grow much beyond 2M for at least a year because of concerns expressed by miners at Scaling Bitcoin.
- Involve both a hard fork and a soft fork.
- Have continuous, gradual growth instead of big step functions.

It's essentially a combination of a variant of 2-4-8 (necessarily a hard fork) and a soft fork version of Segregated Witness. The advantage of the 2-4-8 hard fork is that it is very simple and can be coded and merged very quickly, probably in January. The SW soft fork on the other hand can probably be activated sooner. Iherefore I'd like to see the hard fork coded, merged and deployed first, then the soft fork merged and deployed and then the hard fork activated provided it passes its vote. In this way SW would be sandwiched between the deployment of an as yet inactive 2-4-8 and its activation.

It does not preclude further hard forks at any time, either before or after the proposed compromise hard fork, although it is specifically intended to discourage *contentious* hard forks. Non-contentious hard forks that become possible in the light of experience gained are only to be welcomed of course.

The details are as follows:

Hard fork with gradual growth:
- +20kb each difficulty adjustment up to 8M.
- Possibly a one-off jump to 2MB, but probably not given that SW will likely be activated first.
- 95% activation threshold hard-coded to a period of 1000 blocks before a one-off, fixed block ("election day").
- One month grace period, with a flag date at a fixed block height ("inauguration day") that will enable the growth mechanism supposing the threshold was met by election day.
- Pull request ready somewhere in January.
- Merged in Q1.
- Release around May.
- Election day January 1st 2017.
- Inauguration day February 1st 2017.

Soft fork Segregated Witness:
- Deployed as already suggested by the developers, but modified to be aware of the upcoming hard fork.
- Limited to 1MB for the witness section for the first two years after deployment to take miner concerns into account and allow time for research into give weak blocks and IBLT research
- Witness section size set to 1x or 2x the size of the main section of the block after two years.