mimblewimble team mailing list archive

[Andrew Bellenie <andybellenie@xxxxxxxxx>]

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
>
>