Martijn Meijering [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-17 📝 Original message:Appealing moderator's ...
📅 Original date posted:2015-12-17
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/633b9c14/attachment-0001.html>;
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/633b9c14/attachment-0001.html>;