mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

Lots of great points about hard and soft forks, and I fully agree that once the blockchain is fully established, forced hard forks are both a technical and moral hazard. So let's keep the 2 years limit, leaving us 4 hard forks to face our growing pains (and iron out soft forks on our chain, that has relatively little variable data).

Sorry Casey (and Coindesk [1]) but human-friendly date/times are too much of a pain (timezones and daylight savings anyone?), especially when we have one of the most solid distributed timestamping mechanisms available: a blockchain. Basing it on block heights is much simpler, robust and less subject to interpretation.

I do agree with the necessity of a node implementation available early enough, especially as time goes. Early on, it may be difficult to do 3 months but as time passes it should get more and more predictable. So I propose to strive for 1, 2, 3 and 4 months in advance respectively.

- Igno

[1] https://www.coindesk.com/solstice-approaching-mimblewimble-blockchain-considers-hard-fork-schedule/

> -------- Original Message --------
> Subject: Re: [Mimblewimble] Scheduled hard forks
> Local Time: October 5, 2017 4:06 PM
> UTC Time: October 5, 2017 4:06 PM
> From: percytheprefect@xxxxxxxxxxxxxx
> To: Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>
> mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>
>
>>Finally, there's rarely a need to hardfork. Softforks alleviate most of the above concerns (except needing a very long lead time and extensive review) and with a bit of foresight can be done just as cleanly as hardforks. For example see my "future peg support" proposal from some months back.
>
> Expanding on this, I believe we can learn a lot from other blockchains in terms of consensus design. It seems if we have a flexible serialization system for transactions we can later soft fork in changes that need to be made to the system.
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
>> -------- Original Message --------
>> Subject: Re: [Mimblewimble] Scheduled hard forks
>> Local Time: October 5, 2017 9:57 AM
>> UTC Time: October 5, 2017 2:57 PM
>> From: apoelstra@xxxxxxxxxxxxxx
>> To: Andrew Bellenie <andybellenie@xxxxxxxxx>
>> mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>
>>
>> Hardforks limit the growth of the system to people who are willing to do
>> regular mandatory updates of all of their supporting software to handle
>> changes that they may not care in the least about. It creates a centralization
>> pressure because it will be cheaper for many businesses to outsource
>> validation to companies who specialize in it (who will then be de facto
>> rulesetters for the system).
>>
>> It will also increase the maintenance cost for software that uses the system
>> (and the cleanly separated commitment structure + cryptographic properties
>> of every object in the blockchain mean that I expect people to be doing
>> interesting and unexpected things with it that the standard grin node software
>> will not support) and discourage creating it in the first place, if the rules
>> are not set in stone.
>>
>> As the community grows things will tend to ossify and changes will be harder
>> to get consensus for and to deploy updated software for.
>>
>> And this is even for somewhat boring things like changing the difficulty
>> adjustment. If we were to introduce huge new pieces of crypto the way that
>> Monero does this problems would be an even more serious concern.
>>
>> Monero is designed to be a bleeding-edge somewhat-experimental cryptocurrency
>> for people who are willing to try new things to explore the privacy tech
>> landscape. That necessarily restricts their community to people who are
>> comfortable with this level of risk (and requirement to pay attention), and
>> they have had some near-misses with broken crypto that I think would"ve been
>> avoided if they were more conservative. To contrast MW is a much simpler
>> design; there are basically two rules (the UTXOset must add up and every key
>> needs to sign itself) and the rest is standard chain-of-blocks kinda stuff.
>> It doesn"t seem like a natural base for consensus-critical radicalism.
>>
>> Finally, there"s rarely a need to hardfork. Softforks alleviate most of the
>> above concerns (except needing a very long lead time and extensive review)
>> and with a bit of foresight can be done just as cleanly as hardforks. For
>> example see my "future peg support" proposal from some months back.
>>
>> None of these points are very important in the early days of the system
>> before it"s been battle-tested or widely used, and when everybody involved
>> is paying close attention to it (and minimizing their exposure to their
>> problems). But I like the idea of being clear upfront that the "early days"
>> won"t last forever.
>>
>> Andrew
>>
>> On Tue, Oct 03, 2017 at 11:01:10PM +0100, Andrew Bellenie wrote:
>>> I agree, except I don"t see a reason to limit it to the first 2 years. Six
>>> monthly upgrades seem to be well accepted by the Monero community. I"d
>>> leave the option open, besides, it could always be removed or adjusted in
>>> one of the upgrades (e.g. move to annual, then bi-annual, or stop
>>> altogether).
>>>
>>> I like the solstice idea too for entirely non-technical reasons.
>>>
>>> On 3 October 2017 at 21:29, Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>
>>> wrote:
>>>
>>> > Hi all,
>>> >
>>> > As we"re preparing both a fully new blockchain format and implementation
>>> > we, developers, are bound to make mistakes. Some of them will be trivial to
>>> > correct, and some of them will not, requiring changes in consensus
>>> > parameters. We will also want to "clean up" some technical debt that can
>>> > accumulate in younger implementations. So I think it"s fair to ask for some
>>> > leeway to hard fork when required, at least at the beginning.
>>> >
>>> > To make that process easier and more predictable, I would like to include
>>> > scheduled hard forks with the following limitations:
>>> >
>>> > - Only 2 scheduled hard forks per year.
>>> > - Only for the first 2 years.
>>> >
>>> > The mechanism would be a mandated block version increase every 6 months,
>>> > limited to 4 increases.
>>> >
>>> > Thoughts?
>>> >
>>> > - Igno
>>> >
>>> > P.S. Thanks to yeastplume for suggesting we establish a pre-defined
>>> > schedule.
>>> >
>>> > --
>>> > Mailing list: https://launchpad.net/~mimblewimble
>>> > Post to : mimblewimble@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~mimblewimble
>>> > More help : https://help.launchpad.net/ListHelp
>>> >
>>> >
>>
>>> --
>>> Mailing list: https://launchpad.net/~mimblewimble
>>> Post to : mimblewimble@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~mimblewimble
>>> More help : https://help.launchpad.net/ListHelp
>>
>> --
>> Andrew Poelstra
>> Mathematics Department, Blockstream
>> Email: apoelstra at wpsoftware.net
>> Web: https://www.wpsoftware.net/andrew
>>
>> "A goose alone, I suppose, can know the loneliness of geese
>> who can never find their peace,
>> whether north or south or west or east"
>> --Joanna Newsom
>>
>> --
>> Mailing list: https://launchpad.net/~mimblewimble
>> Post to : mimblewimble@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~mimblewimble
>> More help : https://help.launchpad.net/ListHelp