MIME-Version: 1.0
In-Reply-To: <559012A9.3050606@sky-ip.org>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
	<20150627074259.GA25420@amethyst.visucore.com>
	<20150627095501.C59B541A40@smtp.hushmail.com>
	<20150627100400.GC25420@amethyst.visucore.com>
	<20150627102912.06E2641A3E@smtp.hushmail.com>
	<CABm2gDpnzjph5SKTf+8GWgwe+njS=k2GNm9uL73RC-EV=Y5wug@mail.gmail.com>
	<20150627121016.2360041A3E@smtp.hushmail.com>
	<CABm2gDovynxmZmf_voz-19mmb5k0R4Snxcucx-WObt_stkAL9A@mail.gmail.com>
	<559012A9.3050606@sky-ip.org>
Date: Sun, 28 Jun 2015 17:45:24 +0200
Message-ID: <CABm2gDrWfJwk3jQCC0+7JWkXAWWSuRaXLwLeUQB23GNPOQkaMA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: s7r@sky-ip.org
Content-Type: text/plain; charset=UTF-8
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Precedence: list

On Sun, Jun 28, 2015 at 5:28 PM, s7r <s7r@sky-ip.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> +1 for this  Jorge.
> Agreed the majority should not be able to enforce rules over the
> minority. But if the majority will just leave and create an altcoin or
> whatever, this will leave the remaining minority with a less value (or
> even 0 value) product or service. By enforcing some rules agreed by
> the majority or supermajority, the minority will be dragged along and
> even so with rules they haven't signed up for, they will still have a
> product or service which is worth something.

If the Schism fork goes wrong (ie 2 chains coexist in parallel for
long) the result may as well be that NOBODY will be left any value.
Both the majority and the minority can lose simultaneusly.
See https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#schism1-hardforks
That kind of hardfork is basically like forcing the users to go to war
against each other.
Really, I don't think civil war is an exaggerated analogy.

> That is why we have to be very careful into deciding this.
>
> This debate is good, there are lots of valid points from smart people
> and I am happy to see there is so much interest in this project, and
> regardless if the blocksize hard cap will be changed or not I do hope,
> if a hardfork will happen, it will also include a smart change that
> will allow future changes (requiring hardforks) simpler, with less
> headache and risks involved.

That sounds great. Do you have any proposal in mind?
I really want hardforks to be made, I just don't want to kill the
system attempting it.