path: root/81/49ed28c570c7272bfd681828d1a4250ce06a7d

Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 629611178
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 27 Dec 2015 00:03:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB871A5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 27 Dec 2015 00:03:32 +0000 (UTC)
Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197]
	(may be forged)) (authenticated bits=0)
	by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tBR03SoP028673
	(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
	Sat, 26 Dec 2015 16:03:29 -0800
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_C2150F1B-E8EE-48EE-AA22-B31C1019CF54";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Jonathan Toomim <j@toom.im>
In-Reply-To: <CAPg+sBi_cD-mQOxVoHrHq5CUmjdEC5afCovSh0q3wD-nGV=R3g@mail.gmail.com>
Date: Sat, 26 Dec 2015 16:03:58 -0800
Message-Id: <A9548C1C-3DA5-4631-B399-50CC301FB8A8@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>
	<CAPg+sBi_cD-mQOxVoHrHq5CUmjdEC5afCovSh0q3wD-nGV=R3g@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVZwzOkIhZ/FDhIbQqGNJRy2zLYO8eDBNjjUQE3bcjMO0Btm5k2D0Wj+aR7vrmr97kIOCdy+EsnVJ69MNgfscAKi
X-Sonic-ID: C;Ci0CQi2s5RGTZ/8vZz0oYQ== M;mhl7Qi2s5RGTZ/8vZz0oYQ==
X-Sonic-Spam-Details: 3.8/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation &
	moral hazard
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Dec 2015 00:03:33 -0000


--Apple-Mail=_C2150F1B-E8EE-48EE-AA22-B31C1019CF54
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0730E890-4843-4789-82DD-0C394C186BBF"


--Apple-Mail=_0730E890-4843-4789-82DD-0C394C186BBF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Dec 26, 2015, at 3:16 PM, Pieter Wuille <pieter.wuille@gmail.com> =
wrote:

> 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.
>=20
I'm not proposing that we rely on miners' assessments of full node =
counts. I'm simply proposing that they serve as an extra layer of =
safety.

For the users that don't pay attention, I don't think the miners should =
be the sole parties to make that judgment call. That's why I suggested =
the grace period. I think that 1 or 2 months more than enough time for a =
business or active bitcoin user to download a new version of the =
software. I think that 1 or 2 months after a majority of nodes and =
miners have upgraded is more than more than enough time. For non-active =
businesses and users, there is no risk from the hard fork. If you're not =
transacting, you can't be defrauded.

Nodes that disagree with the change are welcome to continue to run the =
old version and watch the small fork if they so choose. Their numbers =
should be small if indeed this is an uncontroversial hardfork, but they =
won't be zero, and that's fine. The software supports this (except for =
peer discovery, which can get a little bit tricky in hardfork scenarios =
for the minority fork). Miners have no ethical obligation to protect =
individuals who choose not to follow consensus.

I think that use of the Alert System =
https://en.bitcoin.it/wiki/Alert_system would be justified in the weeks =
preceding the hard fork. Maybe we can create an "Upgrade now!" message =
that the new version would ignore, and set it to broadcast forever to =
all old nodes?

--Apple-Mail=_0730E890-4843-4789-82DD-0C394C186BBF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>On Dec 26, 2015, at 3:16 PM, Pieter Wuille =
&lt;<a =
href=3D"mailto:pieter.wuille@gmail.com">pieter.wuille@gmail.com</a>&gt; =
wrote:</div><div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><p dir=3D"ltr">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.</p></blockquote><div>I'm not proposing that we rely on miners' =
assessments of full node counts. I'm simply proposing that they serve as =
an extra layer of safety.&nbsp;</div><div><br></div><div>For the users =
that don't pay attention, I don't think the miners should be the sole =
parties to make that judgment call. That's why I suggested the grace =
period. I think that 1 or 2 months more than enough time for a business =
or active bitcoin user to download a new version of the software. I =
think that 1 or 2 months after a majority of nodes and miners have =
upgraded is more than more than enough time. For non-active businesses =
and users, there is no risk from the hard fork. If you're not =
transacting, you can't be =
defrauded.</div><div><br></div></div><div>Nodes that disagree with the =
change are welcome to continue to run the old version and watch the =
small fork if they so choose. Their numbers should be small if indeed =
this is an uncontroversial hardfork, but they won't be zero, and that's =
fine. The software supports this (except for peer discovery, which can =
get a little bit tricky in hardfork scenarios for the minority fork). =
Miners have no ethical obligation to protect individuals who choose not =
to follow consensus.</div><div><br></div><div>I think that use of the =
Alert System&nbsp;<a =
href=3D"https://en.bitcoin.it/wiki/Alert_system">https://en.bitcoin.it/wik=
i/Alert_system</a>&nbsp;would be justified in the weeks preceding the =
hard fork. Maybe we can create an "Upgrade now!" message that the new =
version would ignore, and set it to broadcast forever to all old =
nodes?</div></body></html>=

--Apple-Mail=_0730E890-4843-4789-82DD-0C394C186BBF--

--Apple-Mail=_C2150F1B-E8EE-48EE-AA22-B31C1019CF54
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJWfyrvAAoJEIEuMk4MG0P136EH/A+5ygOjNEg9jK4JlJ5bVle8
vmCE/RUpg15xsCI0cu5YqCEqmBL3v2ZXL5lQSxG7hKqgnzF5MGKkkgDCBvQr5Ajy
AjvNcTBJTI9Z7BQcrnN5eqIJ87wbG5U7y023t10uQxjv2vSYq5c/KzqPnDE8dkgR
1zP9ItaagtslSo1xEBgQm2HCgWd67obxpm4yY8iM+oQkLxJFIzO3izdC9DOO1LAW
zOs0CHsATA2xS9WugFO0TGyT1SXyRqZiw/5xHPv+zmiqfxLVpdrHE/fKHxTCm5gE
N4H89sTAZqRnXZz22s9QNN25p3L1m1Mi+l74tAjjJRBN8K9GX2+pl8Ala9Q33z4=
=Co6v
-----END PGP SIGNATURE-----

--Apple-Mail=_C2150F1B-E8EE-48EE-AA22-B31C1019CF54--