path: root/56/933d69f91ce038c1a8aae49a40700f178b02eb

Return-Path: <hectorchu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AA2A4486
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 08:31:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f46.google.com (mail-la0-f46.google.com
	[209.85.215.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C050115E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 08:31:44 +0000 (UTC)
Received: by labpt2 with SMTP id pt2so10666104lab.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 03 Aug 2015 01:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=6BJzdlNPdTRCzowXlE1MMivdvDW7H4NKZ5jkD4Bf6G8=;
	b=njD8TyDdNehSrXtJWhebZaq0CqfjlJMrerD5Sx+DcvDM6PTtF3+m7UBATdBWjwi5a4
	4Y+3dKV6uPcyQ5h30DnTTBI+i0p5MYszDRKjHoHdzyCcfkO3dLbrno+tDqP72l6zF9yI
	AqGL4ofKyVzx7KZuKioypq3j3/FIzgSo0/GA98tAqMK0YDgcX3NwjQbfGwf7b/d9HcaI
	6A6BzksUCkynOfkdQSMUmxc1UVeHmoRfMEp9W7lVucA1w+oTO22UoneLUakQtJZsAww6
	3ibH7wgr5TEUCH4yJTjZYQsAt/y0eOLYVJ/A5UJIeXZOcQSJ7gYKTHa/FkEeptLq42GB
	vdXw==
X-Received: by 10.112.161.40 with SMTP id xp8mr15537708lbb.71.1438590703061;
	Mon, 03 Aug 2015 01:31:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.22.25 with HTTP; Mon, 3 Aug 2015 01:31:23 -0700 (PDT)
In-Reply-To: <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>
	<291F9D27-024C-4982-B638-1ACDC4FE0672@gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Mon, 3 Aug 2015 09:31:23 +0100
Message-ID: <CAAO2FKGGyjJT8UhW9m1ZMRY4gmjf3F05mjW1eZ2byT+dwM28Ow@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c25f52d55169051c63ff20
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:31:45 -0000

--001a11c25f52d55169051c63ff20
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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.

On 3 August 2015 at 09:20, Eric Lombrozo <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 hav=
e
> 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 disagreeme=
nt
> 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 i=
ndividuals
> 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 canno=
t
> possibly make these forking tendencies better=E2=80=A6but it very well co=
uld make
> them worse.
>
> - Eric
>
> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On 3 August 2015 at 08:53, Adam Back <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.
>>
>
> 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 o=
f
> them think the hit to node count in the short term preferable to making i=
t
> expensive and competitive to transact.
>
> 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
>
>
>

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

<div dir=3D"ltr">What&#39;s wrong with a little cooperation to resolve thin=
gs now and then? Man is not an island unto himself, we compete with each ot=
her and we cooperate with each other occasionally if it&#39;s mutually bene=
ficial.<div><br></div><div>You said yourself that a lot of money would have=
 been lost if the two hard forks cited weren&#39;t resolved - that&#39;s th=
e correct incentives at work again.</div></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On 3 August 2015 at 09:20, Eric Lombrozo <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:elombrozo@gmail.com" target=3D"_blank">=
elombrozo@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div style=3D"word-wrap:break-word">There have already been two notable in=
cidents requiring manual intervention and good-faith cooperation between co=
re devs and mining pool operators that would have either never gotten resol=
ved 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 bi=
gger 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 cons=
ensus forks that require manual intervention.<div><br></div><div>Please, ca=
n we stop saying this is merely about decentralization and trustlessness? T=
he 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 deliberate=
ly 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 m=
ake these forking tendencies better=E2=80=A6but it very well could make the=
m worse.</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div=
><div>- Eric</div></font></span><div><br><div><blockquote type=3D"cite"><di=
v><div class=3D"h5"><div>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">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br></di=
v></div><div><div><div class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">On 3 August 2015 at 08:53, Adam Back <span =
dir=3D"ltr">&lt;<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">a=
dam@cypherspace.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" 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>
must focus on scientific evaluation, technical requirements and<br>
security.<br></blockquote><div><br></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 t=
he current configuration as you do. This debate has forgotten the current a=
nd 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></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 decentra=
lisation and trustlessness. The incentives of Bitcoin remain, so everyone&#=
39;s decentralised decision throughout the system, from miners, merchants a=
nd users, will continue to act according to those incentives.</div></div></=
div></div></div><span class=3D"">
_______________________________________________<br>bitcoin-dev mailing list=
<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br><a href=3D"https://lists.l=
inuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://=
lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></span></div>=
</blockquote></div><br></div></div></blockquote></div><br></div>

--001a11c25f52d55169051c63ff20--