mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

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

Attachment: signature.asc
Description: PGP signature