MIME-Version: 1.0
In-Reply-To: <2D7C4E00-7451-45B6-94B6-07A7230FBF88@toom.im>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
	<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
	<CADm_WcbrMyk-=OnQ-3UvnF_8brhn+X2NqRPbo5xUXsbcZpc0=Q@mail.gmail.com>
	<CAPg+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@mail.gmail.com>
	<CA+c4Zozac8=aMrAJ1N_6SR9eBD+w0e70cEnk9CG_2oZ72AS-8g@mail.gmail.com>
	<CAPg+sBhsKD8jd9Y9+ngXY5tKUheO3d4P1b47eYL=Uzpat+KJ2w@mail.gmail.com>
	<751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
	<CAPg+sBiT5=ss9e=iac6J-A=85okF0zxMeV7H4z9-Qfx3CAWHXA@mail.gmail.com>
	<246AA3BE-570D-4B88-A63D-AC76CB2B0CB8@toom.im>
	<CAPg+sBhxnxnQQ-SpWuJ-+_uxRwXkgcU07jkYdZ8BcBwVDyW-vg@mail.gmail.com>
	<2D7C4E00-7451-45B6-94B6-07A7230FBF88@toom.im>
Date: Sun, 27 Dec 2015 00:16:17 +0100
Message-ID: <CAPg+sBi_cD-mQOxVoHrHq5CUmjdEC5afCovSh0q3wD-nGV=R3g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Jonathan Toomim <j@toom.im>
Content-Type: multipart/alternative; boundary=089e0149bb025140770527d54232
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation &
 moral hazard
Precedence: list

--089e0149bb025140770527d54232
Content-Type: text/plain; charset=UTF-8

On Dec 27, 2015 00:06, "Jonathan Toomim" <j@toom.im> wrote:

> Given that a supermajority of users and miners have been asking for a
hard fork to increase the blocksize for years, I do not think that
mobilizing people to upgrade their nodes is going to be hard.
>
> When we do the hard fork, we will need to encourage people to upgrade
their full nodes. We may want to request that miners not trigger the fork
until some percentage of visible full nodes have upgraded.

I am generally not interested in a system where we rely on miners to make
that judgement call to fork off nodes that don't pay attention and/or
disagree with the change. This is not because I don't trust them, but
because I believe one of the principle values of the system is that its
consensus system should be hard to change.

I can't tell you what code to run of course, but I can decide what system I
find interesting to build. And it seems many people have signed off on
working towards a plan that does not include a hard fork being scheduled
right now: https://bitcoin.org/en/bitcoin-core/capacity-increases

Cheers,

-- 
Pieter

--089e0149bb025140770527d54232
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On Dec 27, 2015 00:06, &quot;Jonathan Toomim&quot; &lt;<a href=3D"mailto:j@=
toom.im">j@toom.im</a>&gt; wrote:</p>
<p dir=3D"ltr">&gt; Given that a supermajority of users and miners have bee=
n asking for a hard fork to increase the blocksize for years, I do not thin=
k that mobilizing people to upgrade their nodes is going to be hard.<br>
&gt;<br>
&gt; When we do the hard fork, we will need to encourage people to upgrade =
their full nodes. We may want to request that miners not trigger the fork u=
ntil some percentage of visible full nodes have upgraded.</p>
<p dir=3D"ltr">I am generally not interested in a system where we rely on m=
iners to make that judgement call to fork off nodes that don&#39;t pay atte=
ntion and/or disagree with the change. This is not because I don&#39;t trus=
t them, but because I believe one of the principle values of the system is =
that its consensus system should be hard to change.</p>
<p dir=3D"ltr">I can&#39;t tell you what code to run of course, but I can d=
ecide what system I find interesting to build. And it seems many people hav=
e signed off on working towards a plan that does not include a hard fork be=
ing scheduled right now: <a href=3D"https://bitcoin.org/en/bitcoin-core/cap=
acity-increases">https://bitcoin.org/en/bitcoin-core/capacity-increases</a>=
</p>
<p dir=3D"ltr">Cheers,</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>

--089e0149bb025140770527d54232--