path: root/31/a7a53aafee3c11b51e0f027ba54196cc355132

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9DA77273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 08:20:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com
	[209.85.220.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1A6914E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 08:20:45 +0000 (UTC)
Received: by pawu10 with SMTP id u10so7227668paw.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 03 Aug 2015 01:20:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=T//hMPrZvGDLfFzTV6dNXgmHhHnLY8fIxfqc6i5Bn2c=;
	b=rtxEZQaUmaU4f9yPhsgceaUdPjIUDs5jRNT9cM/pc9wcaupvLzJdsTFvd/5nJqjDnH
	ZVWObgzKDweqOSI0Gs4YBPlForx1YolblbX92U/wQqNcmh5+y42e3ZdyaFjR9fPn6Gi9
	UTXnmFnk+yn9Nufe0MKUNPL2atEk5UVhLzQ/4oczfP6ph540mYxMBwb/71gR0jaK6PDF
	jBgquSRo+rN3FLiLupDLH90FHARZmq1dB9pUPoPMN8oluIIBWu8P8EXwbVwqSnlbj3HP
	+RwAXIuDvybbzGy1m8Kz7zcb5o0lbBRW5cvZszvYk65q0b/jrgVQUBb4b2d8yOxlkRSG
	BtUQ==
X-Received: by 10.66.194.201 with SMTP id hy9mr33626480pac.140.1438590045652; 
	Mon, 03 Aug 2015 01:20:45 -0700 (PDT)
Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	hb1sm6965547pbd.36.2015.08.03.01.20.41
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Aug 2015 01:20:42 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_56AD65B9-5CF0-45D0-A28B-F192CAF4CDFD";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAAO2FKHZa_3VzMhQ-EVK9MzSnNGCfwb_GcKJHV52bYcWayJvig@mail.gmail.com>
Date: Mon, 3 Aug 2015 01:20:39 -0700
Message-Id: <291F9D27-024C-4982-B638-1ACDC4FE0672@gmail.com>
References: <CANe1mWxsAPzWut_gDqe4R-SkDPBYM392NzeVqbUzjwh+pydsWQ@mail.gmail.com>
	<CALqxMTEMajz6oHnGvocxy=xDFMBc1LaX1iWYM=w1PF0rH3syFg@mail.gmail.com>
	<55BF153B.9030001@bitcartel.com>
	<CAAO2FKEBBS5wxefGCPcurcRGg76sORrBMHvd2SSNiW1q_zWBWQ@mail.gmail.com>
	<CALqxMTE69h5OcnDSqSMeK+BbzFaScEqouQG=pVuyWrqG17BeXQ@mail.gmail.com>
	<CAAO2FKHZa_3VzMhQ-EVK9MzSnNGCfwb_GcKJHV52bYcWayJvig@mail.gmail.com>
To: Hector Chu <hectorchu@gmail.com>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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] A reason we can all agree on to increase block
	size
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: Mon, 03 Aug 2015 08:20:46 -0000


--Apple-Mail=_56AD65B9-5CF0-45D0-A28B-F192CAF4CDFD
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_AC793FED-BBDD-4E36-91A2-DF4B7F37AE6F"


--Apple-Mail=_AC793FED-BBDD-4E36-91A2-DF4B7F37AE6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

There have already been two notable incidents requiring manual =
intervention and good-faith cooperation between core devs and mining =
pool operators that would have either never gotten resolved alone or =
would have ended up costing a lot of people a lot of money had no action =
been taken (March 2013 and July 2015). They were both caused by =
consensus disagreement that directly or indirectly were brought about by =
bigger blocks. There is *strong* evidence=E2=80=A6and a great deal of =
theory explaining it=E2=80=A6that links larger blocks with the =
propensity for consensus forks that require manual intervention.

Please, can we stop saying this is merely about decentralization and =
trustlessness? The very model upon which the security of the system is =
based *broke*=E2=80=A6as in, we were only able to recover because a few =
individuals deliberately manipulated the consensus rules to fix it =
manually. Shouldn=E2=80=99t we more highly prioritize fixing the issues =
that can lead to these incidents than trying to increase throughput? =
Increasing block size cannot possibly make these forking tendencies =
better=E2=80=A6but it very well could make them worse.

- Eric

> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace.org =
<mailto:adam@cypherspace.org>> wrote:
> Again this should not be a political or business compromise model - we
> must focus on scientific evaluation, technical requirements and
> security.
>=20
> I will assert that the block size is political because it affects =
nearly all users to some degree and not all those users are technically =
inclined or care to keep decentralisation in the current configuration =
as you do. This debate has forgotten the current and future users of =
Bitcoin. Most of them think the hit to node count in the short term =
preferable to making it expensive and competitive to transact.
>=20
> We all need a little faith that the system will reorganise and =
readjust after the move to big blocks in a way that still has a =
reasonable degree of decentralisation and trustlessness. The incentives =
of Bitcoin remain, so everyone's decentralised decision throughout the =
system, from miners, merchants and users, will continue to act according =
to those incentives.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_AC793FED-BBDD-4E36-91A2-DF4B7F37AE6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">There have already been two notable incidents requiring =
manual intervention and good-faith cooperation between core devs and =
mining pool operators that would have either never gotten resolved alone =
or would have ended up costing a lot of people a lot of money had no =
action been taken (March 2013 and July 2015). They were both caused by =
consensus disagreement that directly or indirectly were brought about by =
bigger blocks. There is *strong* evidence=E2=80=A6and a great deal of =
theory explaining it=E2=80=A6that links larger blocks with the =
propensity for consensus forks that require manual intervention.<div =
class=3D""><br class=3D""></div><div class=3D"">Please, can we stop =
saying this is merely about decentralization and trustlessness? The very =
model upon which the security of the system is based *broke*=E2=80=A6as =
in, we were only able to recover because a few individuals deliberately =
manipulated the consensus rules to fix it manually. Shouldn=E2=80=99t we =
more highly prioritize fixing the issues that can lead to these =
incidents than trying to increase throughput? Increasing block size =
cannot possibly make these forking tendencies better=E2=80=A6but it very =
well could make them worse.</div><div class=3D""><br class=3D""></div><div=
 class=3D"">- Eric</div><div class=3D""><br class=3D""><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Aug 3, 2015, at 1:06 AM, =
Hector Chu via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3 =
August 2015 at 08:53, Adam Back <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:adam@cypherspace.org" target=3D"_blank" =
class=3D"">adam@cypherspace.org</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">Again this should not =
be a political or business compromise model - we<br class=3D"">
must focus on scientific evaluation, technical requirements and<br =
class=3D"">
security.<br class=3D""></blockquote><div class=3D""><br =
class=3D""></div>I will assert that the block size is political because =
it affects nearly all users to some degree and not all those users are =
technically inclined or care to keep decentralisation in the current =
configuration as you do. This debate has forgotten the current and =
future users of Bitcoin. Most of them think the hit to node count in the =
short term preferable to making it expensive and competitive to =
transact.</div><div class=3D"gmail_quote"><br class=3D""></div><div =
class=3D"gmail_quote">We all need a little faith that the system will =
reorganise and readjust after the move to big blocks in a way that still =
has a reasonable degree of decentralisation and trustlessness. The =
incentives of Bitcoin remain, so everyone's decentralised decision =
throughout the system, from miners, merchants and users, will continue =
to act according to those incentives.</div></div></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_AC793FED-BBDD-4E36-91A2-DF4B7F37AE6F--

--Apple-Mail=_56AD65B9-5CF0-45D0-A28B-F192CAF4CDFD
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

iQIcBAEBCgAGBQJVvyRXAAoJEJNAI64YFENUIDAP/jLEUfO3nILE/63CqwuVasnu
Lgk+7MIzaxVaxYbdWaJCTshfck2GAldM3Sgm0zJQ5+QqhrfPLncCQkTlYTSkQ5EY
7Q8cu1VoP9Zm6hhGzQt8b2Q072pWY8SbHm1tZBhA5isIN4AMgR8VqIHUcA683XYb
Cd3UHlkE2IQjzxiOdY7CrD5x0Li87yAXw6f0iPI/eJ8SuzBt4syz2aEiG9EPCTSy
ZFJHCdeEjXqyPkiHI/AcPnG0vbm/G1bitQmdwdmYF6ESQ3oUL137SndH38X2tX0w
Wr5VATzZ4DYMa2HwXOZaKZJ+61L/mQ/9g3B0t4ZSsWeqTs4oZLK5TDQF6n0lQDJJ
VfpS4H8uZBKJd6NjJpwvMtKXbomyBnDej6GNiDXcleMEZ9X9N/96GgSPZQBYh83c
++0nj6nDtmFMaq4LUxVYFm915/ZQHDDT2cFHjmU7oLzXRwfSWBC25FIEEz8vpquC
EEUK5c/S0F+vdfsJfe7IhU8je3d4qJfxOADcSe+OUD3/4K/SE3FoYCpnEyiB8Biv
lmp39rs6OvUcO2jHOQa/DgqgwKO8+y8DFYrJDhRa2cu05y4kFOwi5s0VfCf9GzQD
dmRENp5lR0PJ83kcl1PRz3xOwd5jHlb+Yepl+OptZZXXMg+oB90tnPg9wNXTRguT
UTXF40Hi+ETDd4u4WNNu
=o7QC
-----END PGP SIGNATURE-----

--Apple-Mail=_56AD65B9-5CF0-45D0-A28B-F192CAF4CDFD--