path: root/34/f4d0cc680486a2d869f8c7e72ad8733dd36579

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 3B80D82D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 08:52:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com
	[209.85.217.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA025106
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 08:52:45 +0000 (UTC)
Received: by lbbyj8 with SMTP id yj8so73954711lbb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 03 Aug 2015 01:52:44 -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=HepFVkX+GWX76DBE5EfFe4U/Tw8S95lPy30CKxvw6vA=;
	b=zOcIFkP6SKg0b5XWoNEuEJkLmpD5NgCqpIsza9yZjJPyGIQoBuel2YprYBkFVSfqJK
	pWzxxDJlmvgXDha3oBHOA96nLbnRy+u7ox5JDZEW/FDziC9NKuNEmCrm0Q7+kZSyH1S3
	QishgT4IQb1DI0gVTPMklkNIRtwMc9TCciRsCOBRPEwKR9yDUokZncRsvI0WEGXMMrPf
	3xOJAIpB1rXfFBDC8bw6lWp+1n7usOBATqn36zvGUNMZWLYM5oX/5vacwHoAyaCLuEEX
	A17k9Mu8Vo28lk/FRro9S8QvzY8BpSdLRJIRtY8/d9eFxdhfHEliAVk01f5V9+HM/54N
	+loA==
X-Received: by 10.112.160.73 with SMTP id xi9mr15482906lbb.92.1438591964277;
	Mon, 03 Aug 2015 01:52:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.22.25 with HTTP; Mon, 3 Aug 2015 01:52:24 -0700 (PDT)
In-Reply-To: <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>
	<9A5F47B8-AD42-46CB-993B-661BAD0E62AC@gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Mon, 3 Aug 2015 09:52:24 +0100
Message-ID: <CAAO2FKFkMHy0i3GV1aHXu8Hiw5uVnSE2pk17n2mCqOfY-D8Weg@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c235f601f307051c644b6d
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:52:47 -0000

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

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

> 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.
>

There is a degree of difference between cooperation in day-to-day usage of
the system and cooperation in the rare cases the system has a bug.

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 bot=
ched
> something up and need to fix it. And by fix it, I mean fix the protocol s=
o
> that given our best understanding of things in the present we can
> significantly reduce the potential for its occurrence in the future.
>

Distribution by consensus is inherently a fragile system. The network will
continue to break again and again as long as programmers are fallible. But
the types of bugs that occur will change over time as we learn the best
practices for maintaining the system.

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 p=
ut up a fight. if
> you want to design a system around the assumption that this is how all su=
ch
> incidents will be resolved, please don=E2=80=99t spoil this for the rest =
of us.
>

Altruism is a facade that hides other motivations. The party cooperating
with the miners losing money were doing so to maintain good relationships
with those miners and to make sure those miners stay within the system and
not attack it.


>
> - 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? Ma=
n
> is not an island unto himself, we compete with each other and we cooperat=
e
> with each other occasionally if it's mutually beneficial.
>
> You said yourself that a lot of money would have been lost if the two har=
d
> forks cited weren't resolved - that's the correct incentives at work agai=
n.
>
> 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 poo=
l
>> operators that would have either never gotten resolved alone or would ha=
ve
>> 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 disagreem=
ent
>> that directly or indirectly were brought about by bigger blocks. There i=
s
>> *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 manua=
l
>> 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 cann=
ot
>> possibly make these forking tendencies better=E2=80=A6but it very well c=
ould 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 incline=
d
>> 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 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
>>
>>
>>
>
>

--001a11c235f601f307051c644b6d
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 09:38, 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>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.</div></div></blockquote><div><br></div><div>There is =
a degree of difference between cooperation in day-to-day usage of the syste=
m and cooperation in the rare cases the system has a bug.</div><div><br></d=
iv><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>=
These incidents do, fortunately, present some of the better sides of humani=
ty=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 in=
cidents are *not supposed to happen* - and if they do, it means we=E2=80=99=
ve botched something up and need to fix it. And by fix it, I mean fix the p=
rotocol so that given our best understanding of things in the present we ca=
n significantly reduce the potential for its occurrence in the future.</div=
></div></blockquote><div><br></div><div>Distribution by consensus is inhere=
ntly a fragile system. The network will continue to break again and again a=
s long as programmers are fallible. But the types of bugs that occur will c=
hange over time as we learn the best practices for maintaining the system.<=
/div><div><br></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>The correct incentives here were not due to people potenti=
ally losing a lot of money. The incentives here were well-intentioned altru=
ism. Some miners lost money as a result of these actions=E2=80=A6and they d=
idn=E2=80=99t put up a fight. if you want to design a system around the ass=
umption that this is how all such incidents will be resolved, please don=E2=
=80=99t spoil this for the rest of us.<br></div></div></blockquote><div><br=
></div><div>Altruism is a facade that hides other motivations. The party co=
operating with the miners losing money were doing so to maintain good relat=
ionships with those miners and to make sure those miners stay within the sy=
stem and not attack it.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div style=3D"word-wrap:break-word"><div></div><span class=3D"HOEnZb"><fo=
nt color=3D"#888888"><div><br></div><div>- Eric</div></font></span><div><di=
v class=3D"h5"><div><br><div><blockquote type=3D"cite"><div>On Aug 3, 2015,=
 at 1:31 AM, Hector Chu &lt;<a href=3D"mailto:hectorchu@gmail.com" target=
=3D"_blank">hectorchu@gmail.com</a>&gt; wrote:</div><br><div><div dir=3D"lt=
r">What&#39;s wrong with a little cooperation to resolve things now and the=
n? Man is not an island unto himself, we compete with each other and we coo=
perate with each other occasionally if it&#39;s mutually beneficial.<div><b=
r></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 the correct ince=
ntives 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 <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:elombrozo@gmail.com" target=3D"_blank">elombrozo@gma=
il.com</a>&gt;</span> wrote:<br><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">There have already been two notable incidents req=
uiring manual intervention and good-faith cooperation between core devs and=
 mining pool operators that would have either never gotten resolved alone o=
r 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 d=
isagreement 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><br></div><div>Please, can we stop s=
aying this is merely about decentralization and trustlessness? The very mod=
el 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 manipulat=
ed 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 fo=
rking tendencies better=E2=80=A6but it very well could make them worse.</di=
v><span><font color=3D"#888888"><div><br></div><div>- Eric</div></font></sp=
an><div><br><div><blockquote type=3D"cite"><div><div><div>On Aug 3, 2015, a=
t 1:06 AM, Hector Chu via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:</div><br></div></div><div><div><div><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><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">adam@cypherspace.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">Again this should not be a political or business compr=
omise 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>

--001a11c235f601f307051c644b6d--