path: root/c8/775e996da2d6b81e6d2b11c1fad318f1825a30

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 5E8AF8A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 09:22:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com
	[209.85.217.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10225E8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 09:22:41 +0000 (UTC)
Received: by lbqc9 with SMTP id c9so49067789lbq.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 03 Aug 2015 02:22:39 -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=paNBNa6EGoIzODnba/G24lMuUWYK7X227fPiclUs5MU=;
	b=hcLHF7KN8NJOaO4BgiPGVRerBu4sCQrN9NyM6c296Ap6BJ/p4ABMU0CZALqpMCAx9P
	avxEpykK4i4ekqkIM5WmxnvKy3tgt1Hx7RRx6cTwKnndI+UUlDByH0njiuet+aN4o5qz
	nYLSvf9R6gXaksWpfwj0CrJyNEBROzWdGxQPapSLmVvJFdLWeglL4uEukj5RSUhyL0ys
	mWQQfK0VPpG9uVrnLeMyKidinYIaLM43383fC0aLbedaL6Awf3v9zyzwM9NRDe9atu6x
	NIgkT1iAR3AfpX8wHVIvi9F+T3m1PGEe9sqipSY0LAxMVh8EAXuVjRkfZnquafHgswqT
	Fn7Q==
X-Received: by 10.112.160.73 with SMTP id xi9mr15592276lbb.92.1438593759258;
	Mon, 03 Aug 2015 02:22:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.22.25 with HTTP; Mon, 3 Aug 2015 02:22:19 -0700 (PDT)
In-Reply-To: <9D6A80DF-83E6-4F98-B7C2-2EE2F79CB2D1@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>
	<9A5F47B8-AD42-46CB-993B-661BAD0E62AC@gmail.com>
	<CAAO2FKFkMHy0i3GV1aHXu8Hiw5uVnSE2pk17n2mCqOfY-D8Weg@mail.gmail.com>
	<9D6A80DF-83E6-4F98-B7C2-2EE2F79CB2D1@gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Mon, 3 Aug 2015 10:22:19 +0100
Message-ID: <CAAO2FKEzzYaHa9ZOC1Dq-F1RK61X9dt=2cvq97p2yOzYhLSCMQ@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c235f6ff308f051c64b55b
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 09:22:42 -0000

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

On 3 August 2015 at 10:01, Eric Lombrozo <elombrozo@gmail.com> wrote:

> I agree. But again, once we=E2=80=99ve identified specific issues, it is
> irresponsible to continue to pretend they don=E2=80=99t exist=E2=80=A6and=
 to more highly
> prioritize changes that can only make the problem worse.
>

> Again, for the record, I am not against ultimately allowing bigger blocks=
.
> I think it would be a good thing to be able to do this=E2=80=A6and my mai=
n concerns
> are not around things like equipment costs or typical household bandwidth=
.
> I just think security is a more important feature than greater throughput
> and prioritize it thusly.
>

Security is an ongoing incremental process and everyone is giving it the
highest priority. Forgive me for being a bit behind on this - are you able
to point me to the potential solutions for the problems that were
identified from the unintentional hard forks?


> I don=E2=80=99t disagree=E2=80=A6clearly even the miners that lost money =
believed that
> consensus was more valuable to them than a few bitcoins. However, it seem=
s
> to be EXTREMELY dangerous to assume that it will always work out this way=
.
> What=E2=80=99s to stop a mining majority from deciding on-the-fly they wa=
nt to keep
> a particular consensus rule that benefits them even if the core developer=
s
> disagree?
>

The users of Bitcoin are living in a free world. Bitcoin like many
political systems requires the cooperation of the majority. If a majority
of miners decide to change the rules to benefit only themselves then the
system will quickly lead to collapse, until a new system arising from the
ashes of the previous one is erected.

In fact the situation is more optimistic than this. Miners don't set the
rules, the economic majority does. The miners must follow the rules that
are acceptable by the economic majority, or quickly go out of business.


>
>> - Eric
>>
>> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu@gmail.com> wrote:
>>
>> 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 wor=
k
>> 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 po=
ol
>>> operators that would have either never gotten resolved alone or would h=
ave
>>> ended up costing a lot of people a lot of money had no action been take=
n
>>> (March 2013 and July 2015). They were both caused by consensus disagree=
ment
>>> 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 manu=
al
>>> 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. Should=
n=E2=80=99t
>>> we more highly prioritize fixing the issues that can lead to these
>>> incidents than trying to increase throughput? Increasing block size can=
not
>>> 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:
>>>
>>> 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 nearl=
y
>>> all users to some degree and not all those users are technically inclin=
ed
>>> 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.
>>>
>>> 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 degre=
e of
>>> decentralisation and trustlessness. The incentives of Bitcoin remain, s=
o
>>> 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
>>>
>>>
>>>
>>
>>
>
>

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3=
 August 2015 at 10:01, Eric Lombrozo <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:elombrozo@gmail.com" target=3D"_blank">elombrozo@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wor=
d"><div>I agree. But again, once we=E2=80=99ve identified specific issues, =
it is irresponsible to continue to pretend they don=E2=80=99t exist=E2=80=
=A6and to more highly prioritize changes that can only make the problem wor=
se.</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"wo=
rd-wrap:break-word"><div><br></div><div>Again, for the record, I am not aga=
inst ultimately allowing bigger blocks. I think it would be a good thing to=
 be able to do this=E2=80=A6and my main concerns are not around things like=
 equipment costs or typical household bandwidth. I just think security is a=
 more important feature than greater throughput and prioritize it thusly.</=
div></div></blockquote><div><br></div><div>Security is an ongoing increment=
al process and everyone is giving it the highest priority. Forgive me for b=
eing a bit behind on this - are you able to point me to the potential solut=
ions for the problems that were identified from the unintentional hard fork=
s?</div><div>=C2=A0</div><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"><div><span class=3D""><div>I don=E2=80=99t disagree=E2=80=
=A6clearly even the miners that lost money believed that consensus was more=
 valuable to them than a few bitcoins. However, it seems to be EXTREMELY da=
ngerous to assume that it will always work out this way. What=E2=80=99s to =
stop a mining majority from deciding on-the-fly they want to keep a particu=
lar consensus rule that benefits them even if the core developers disagree?=
</div></span></div></div></blockquote><div><br></div><div>The users of Bitc=
oin are living in a free world. Bitcoin like many political systems require=
s the cooperation of the majority. If a majority of miners decide to change=
 the rules to benefit only themselves then the system will quickly lead to =
collapse, until a new system arising from the ashes of the previous one is =
erected.</div><div><br></div><div>In fact the situation is more optimistic =
than this. Miners don&#39;t set the rules, the economic majority does. The =
miners must follow the rules that are acceptable by the economic majority, =
or quickly go out of business.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div style=3D"word-wrap:break-word"><span class=3D""><div><blockqu=
ote type=3D"cite"><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><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:b=
reak-word"><div></div><span><font color=3D"#888888"><div><br></div><div>- E=
ric</div></font></span><div><div><div><br><div><blockquote type=3D"cite"><d=
iv>On Aug 3, 2015, at 1:31 AM, Hector Chu &lt;<a href=3D"mailto:hectorchu@g=
mail.com" target=3D"_blank">hectorchu@gmail.com</a>&gt; wrote:</div><br><di=
v><div dir=3D"ltr">What&#39;s wrong with a little cooperation to resolve th=
ings now and then? Man is not an island unto himself, we compete with each =
other and we cooperate with each other occasionally if it&#39;s mutually be=
neficial.<div><br></div><div>You said yourself that a lot of money would ha=
ve been lost if the two hard forks cited weren&#39;t resolved - that&#39;s =
the 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 <s=
pan 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_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div style=3D"word-wrap:break-word">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 res=
olved alone or would have ended up costing a lot of people a lot of money h=
ad no action been taken (March 2013 and July 2015). They were both caused b=
y consensus disagreement that directly or indirectly were brought about by =
bigger blocks. There is *strong* evidence=E2=80=A6and a great deal of theor=
y explaining it=E2=80=A6that links larger blocks with the propensity for co=
nsensus forks that require manual intervention.<div><br></div><div>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 deliber=
ately manipulated the consensus rules to fix it manually. Shouldn=E2=80=99t=
 we more highly prioritize fixing the issues that can lead to these inciden=
ts than trying to increase throughput? Increasing block size cannot possibl=
y make these forking tendencies better=E2=80=A6but it very well could make =
them worse.</div><span><font color=3D"#888888"><div><br></div><div>- Eric</=
div></font></span><div><br><div><blockquote type=3D"cite"><div><div><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></div></div><div><div><div><div=
 dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3 Aug=
ust 2015 at 08:53, Adam Back <span dir=3D"ltr">&lt;<a href=3D"mailto:adam@c=
ypherspace.org" target=3D"_blank">adam@cypherspace.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft: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>
_______________________________________________<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>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br=
></div></div>
</div></blockquote></div><br></span></div></blockquote></div><br></div></di=
v>

--001a11c235f6ff308f051c64b55b--