mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

This has been implemented and here is the code (see valid_header_version):

https://github.com/ignopeverell/grin/blob/9310151680007dd1e637bd3dc085c93f50184eb4/core/src/consensus.rs#L84

- Igno

> -------- Original Message --------
> Subject: Re: [Mimblewimble] Scheduled hard forks
> Local Time: October 6, 2017 10:12 AM
> UTC Time: October 6, 2017 10:12 AM
> From: andybellenie@xxxxxxxxx
> To: Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>
> mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>
>
> Thanks for the clear explanations.
>
> I wasn't advocating forced hard forks, rather suggesting reserving the flexibility to make future network upgrades by not making public commitments that may boomerang. There's a big difference between saying "we will have up to four hardforks in years 1 and 2" and "we will not have any hardforks after year 2"
>
> Coindesk, LOL. Slow news day.
>
> On 6 October 2017 at 05:04, Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx> wrote:
>
>> 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
>>
>> --
>> Mailing list: https://launchpad.net/~mimblewimble
>> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~mimblewimble
>> More help   : https://help.launchpad.net/ListHelp