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 <[email protected]> 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: [email protected] > To: Andrew Poelstra <[email protected]> > [email protected] <[email protected]> > > >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: [email protected] > To: Andrew Bellenie <[email protected]> > [email protected] <[email protected]> > > > 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 < > [email protected]> > > 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 : [email protected] > > > Unsubscribe : https://launchpad.net/~mimblewimble > > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > -- > > Mailing list: https://launchpad.net/~mimblewimble > > Post to : [email protected] > > 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 : [email protected] > Unsubscribe : https://launchpad.net/~mimblewimble > More help : https://help.launchpad.net/ListHelp > > > > > -- > Mailing list: https://launchpad.net/~mimblewimble > Post to : [email protected] > Unsubscribe : https://launchpad.net/~mimblewimble > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~mimblewimble Post to : [email protected] Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
