Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 629611178 for ; 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 ; 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 In-Reply-To: Date: Sat, 26 Dec 2015 16:03:58 -0800 Message-Id: References: <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com> <246AA3BE-570D-4B88-A63D-AC76CB2B0CB8@toom.im> <2D7C4E00-7451-45B6-94B6-07A7230FBF88@toom.im> To: Pieter Wuille 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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
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.

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/wik= i/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-- --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--