MIME-Version: 1.0
Date: Sat, 27 Jun 2015 13:29:11 +0300
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
From: "NxtChg" <nxtchg@hush.com>
In-Reply-To: <20150627100400.GC25420@amethyst.visucore.com>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
	<20150627074259.GA25420@amethyst.visucore.com>
	<20150627095501.C59B541A40@smtp.hushmail.com>
	<20150627100400.GC25420@amethyst.visucore.com> 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20150627102912.06E2641A3E@smtp.hushmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Precedence: list


On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" <laanwj@gmail.com> wrote:

> Then you won't risk the other 'passengers' who don't consent to it.

But you can look at it the other way: what about risking the 'passengers' when the plane suddenly doesn't fly anymore? 

Increasing block limit increases the risk of centralization, but it also keeps the current status quo of blocks not being filled, rather then risking an unknown option of hitting the limit hard.
 

>... and pretending is only going to cause damage by creating false expectations, or eventually even double-spending possibility because of conflicting forks.

So you personally see the risks of a hard-fork outweigh the risks of not increasing the block size.

It's a valid opinion, but you probably don't want to decide the fate of Bitcoin single-handedly by denying any change, which is not a technical emergency.

That's why there should be a mechanism where the whole community can vote. Lacking that, that's what Gavin and Mike are doing: creating their own mechanism for consensus changes.