path: root/1b/c02b18082a9b09c1711dd15d7e22123e4c9b46

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 38712273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 08:38:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com
	[209.85.192.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 49C6D142
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 08:38:45 +0000 (UTC)
Received: by pdbbo16 with SMTP id bo16so13784181pdb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 03 Aug 2015 01:38: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=AGSxb0WYtjvRj2cBJvGtaWNt3SwYDP22loaIpGZWilY=;
	b=PvPE0pXSbAmzj5g1TUZ8MztgBdidd+qjyjGHFVKqqLg3PMftXXd3W+NjeQwM8GT4i5
	lAy3hH3XjxwvPOUFa7eyDp527wckd5ug2zf9huUCtDajEq5XNyuNBJcEMiGL8L6zNsMi
	fFo25JfUEQFh0zMHmIiQBOmCAPi/3xXxr231ex3Ty32Qru4L3pjcYJvaE86Wsaw6zFIT
	aW3XZs3SQ9iJBuEiwxuSxZexmTYFTbcJsJSlXLOOTdJNJpIiGll7Z1Bi8l6leInu57Te
	suX2a6NrmFNR1p+SX6xzFrUy+LarKHsteYCePZWLtGNIof5bBO8hpvQEvdEBcwSddM46
	SV2Q==
X-Received: by 10.70.92.67 with SMTP id ck3mr33144474pdb.106.1438591125060;
	Mon, 03 Aug 2015 01:38: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
	oh9sm7028455pbb.26.2015.08.03.01.38.42
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 03 Aug 2015 01:38:43 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_4897DCFC-F4E8-4CFE-A4DB-DC6BDAE4A055";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAAO2FKGGyjJT8UhW9m1ZMRY4gmjf3F05mjW1eZ2byT+dwM28Ow@mail.gmail.com>
Date: Mon, 3 Aug 2015 01:38:41 -0700
Message-Id: <9A5F47B8-AD42-46CB-993B-661BAD0E62AC@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>
	<291F9D27-024C-4982-B638-1ACDC4FE0672@gmail.com>
	<CAAO2FKGGyjJT8UhW9m1ZMRY4gmjf3F05mjW1eZ2byT+dwM28Ow@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:38:46 -0000


--Apple-Mail=_4897DCFC-F4E8-4CFE-A4DB-DC6BDAE4A055
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_70A2DB77-7D90-4E98-BFCF-1D755547EF49"


--Apple-Mail=_70A2DB77-7D90-4E98-BFCF-1D755547EF49
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Bah, I don=E2=80=99t know if you=E2=80=99re just trolling me, =
Hector=E2=80=A6but I=E2=80=99ll give you the benefit of the doubt and =
act like you aren=E2=80=99t.

We already have much more efficient, far more scalable systems that =
allow this kind of cooperation you speak of without the inconveniences =
of blockchains and such. These incidents do, fortunately, present some =
of the better sides of humanity=E2=80=A6but=E2=80=A6the design of the =
network *broke* - and for reasons that are now well understood to be =
only worsened by larger blocks. These incidents are *not supposed to =
happen* - and if they do, it means we=E2=80=99ve botched something up =
and need to fix it. And by fix it, I mean fix the protocol so that given =
our best understanding of things in the present we can significantly =
reduce the potential for its occurrence in the future.

The correct incentives here were not due to people potentially losing a =
lot of money. The incentives here were well-intentioned altruism. Some =
miners lost money as a result of these actions=E2=80=A6and they didn=E2=80=
=99t put up a fight. if you want to design a system around the =
assumption that this is how all such incidents will be resolved, please =
don=E2=80=99t spoil this for the rest of us.

- Eric

> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu@gmail.com> wrote:
>=20
> What's wrong with a little cooperation to resolve things now and then? =
Man is not an island unto himself, we compete with each other and we =
cooperate with each other occasionally if it's mutually beneficial.
>=20
> You said yourself that a lot of money would have been lost if the two =
hard forks cited weren't resolved - that's the correct incentives at =
work again.
>=20
> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo@gmail.com =
<mailto:elombrozo@gmail.com>> wrote:
> 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.
>=20
> 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.
>=20
> - Eric
>=20
>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto: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 =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20


--Apple-Mail=_70A2DB77-7D90-4E98-BFCF-1D755547EF49
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"">Bah, I don=E2=80=99t know if you=E2=80=99re just trolling me, =
Hector=E2=80=A6but I=E2=80=99ll give you the benefit of the doubt and =
act like you aren=E2=80=99t.<div class=3D""><br class=3D""></div><div =
class=3D"">We already have much more efficient, far more scalable =
systems that allow this kind of cooperation you speak of without the =
inconveniences of blockchains and such. These incidents do, fortunately, =
present some of the better sides of humanity=E2=80=A6but=E2=80=A6the =
design of the network *broke* - and for reasons that are now well =
understood to be only worsened by larger blocks. These incidents are =
*not supposed to happen* - and if they do, it means we=E2=80=99ve =
botched something up and need to fix it. And by fix it, I mean fix the =
protocol so that given our best understanding of things in the present =
we can significantly reduce the potential for its occurrence in the =
future.</div><div class=3D""><br class=3D""></div><div class=3D"">The =
correct incentives here were not due to people potentially losing a lot =
of money. The incentives here were well-intentioned altruism. Some =
miners lost money as a result of these actions=E2=80=A6and they didn=E2=80=
=99t put up a fight. if you want to design a system around the =
assumption that this is how all such incidents will be resolved, please =
don=E2=80=99t spoil this for the rest of us.</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:31 AM, Hector Chu &lt;<a =
href=3D"mailto:hectorchu@gmail.com" class=3D"">hectorchu@gmail.com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">What's wrong with a little cooperation to resolve =
things now and then? Man is not an island unto himself, we compete with =
each other and we cooperate with each other occasionally if it's =
mutually beneficial.<div class=3D""><br class=3D""></div><div =
class=3D"">You said yourself that a lot of money would have been lost if =
the two hard forks cited weren't resolved - that's the correct =
incentives at work again.</div></div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On 3 August 2015 at 09:20, Eric =
Lombrozo <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:elombrozo@gmail.com" target=3D"_blank" =
class=3D"">elombrozo@gmail.com</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"><div =
style=3D"word-wrap:break-word" 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><span class=3D"HOEnZb"><font color=3D"#888888" =
class=3D""><div class=3D""><br class=3D""></div><div class=3D"">- =
Eric</div></font></span><div class=3D""><br class=3D""><div =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D"h5"><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" =
target=3D"_blank" class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
 wrote:</div><br class=3D""></div></div><div class=3D""><div =
class=3D""><div class=3D"h5"><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></div></div><span =
class=3D"">
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D""></span></div></blockquote></div><br =
class=3D""></div></div></blockquote></div><br class=3D""></div>
</div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_70A2DB77-7D90-4E98-BFCF-1D755547EF49--

--Apple-Mail=_4897DCFC-F4E8-4CFE-A4DB-DC6BDAE4A055
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

iQIcBAEBCgAGBQJVvyiRAAoJEJNAI64YFENUuXQP/104lZEDzstm5T8+kcVgNBip
R0KF3qxSWNV7OL4S6wIff6jdt03UAt7Yb25n26vDmr+RfwEGnHcc9LS9kiXzssYV
Z08QCikImWGhFjwW3CfWPaTgO5aFzea+G184yZmDLuBxkUQyZfjDm5T7V+7AeTQu
a/vjt+ovb/qc6/EynMkAPUeAqpLYFLMgcNAJO5oe0MFE5D8IHUbcRRqORM9JF+kc
XDCBnppesFnIKMx8ENa4JyUuT+UgZOMOjAUmeFtYtMTPzamFjB3DKotAn4fh8My3
rpgL+Yznk4wBnJW1wKjYgu+QZRS5uW9wte5tPJPdJ8j3YKMTb3r28xl1WYWYh80y
LsUR4RnhqoD7kjIaLodBlFIUewlK2C4qwFV5HyZ9I9C3HVzz+/ImG2q4ic/AGjXS
nQtSlCwwPpdq3Gpn7waT8OEIK0NmBljQHqk4EXFuI0Qtn568XSF+mT6wMGQhjDLs
OQGbf/Nq2mCEw1Pn0fOJQsjZ5BDFuN5V0Re91/XNfuhhLaLHuOMPQ18cNjE/aILE
h7cKYHrFMvxU7NEER+9geMXNk9jDUqm5RXfKB258BJ3FV07WSXc2B81Pl9qn58NM
3ZQtJHg2QPO7w3XY+RRpFORGfykTnQHDsGvrpNLjhMTdlEhUTNWZ1bwczXoQH/M8
oAXNZm72cnehpAbPIhIJ
=5iAS
-----END PGP SIGNATURE-----

--Apple-Mail=_4897DCFC-F4E8-4CFE-A4DB-DC6BDAE4A055--