mimblewimble team mailing list archive

[percytheprefect <percytheprefect@xxxxxxxxxxxxxx>]

>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