Re: [Mimblewimble] Scheduled hard forks

2017-10-10 Thread Ignotus Peverell
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 > L

Re: [Mimblewimble] Scheduled hard forks

2017-10-06 Thread Andrew Bellenie
> - 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: Octo

Re: [Mimblewimble] Scheduled hard forks

2017-10-05 Thread Ignotus Peverell
trive 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

Re: [Mimblewimble] Scheduled hard forks

2017-10-05 Thread percytheprefect
ps://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: apoels...@wpsoftware.net > To: Andrew Bellenie > mimblewimble@lists.laun

Re: [Mimblewimble] Scheduled hard forks

2017-10-05 Thread Andrew Poelstra
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 valid

Re: [Mimblewimble] Scheduled hard forks

2017-10-03 Thread Andrew Bellenie
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).

Re: [Mimblewimble] Scheduled hard forks

2017-10-03 Thread Casey Rodarmor
Hi Igno, A hard fork where everyone has a lot of time to upgrade is much less painful than one in which the new client is available for only a short time before the new rules go into effect. So, it might be nice to also commit to a lower bound on the lead time that users will have to upgrade and

[Mimblewimble] Scheduled hard forks

2017-10-03 Thread Ignotus Peverell
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 ca