From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 16E648A7 for ; Mon, 3 Aug 2015 09:01:09 +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 E0D2C143 for ; Mon, 3 Aug 2015 09:01:07 +0000 (UTC) Received: by pasy3 with SMTP id y3so9921535pas.2 for ; Mon, 03 Aug 2015 02:01:07 -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=IPCmP0hTr9xNhv/HNOIWvd0lKq9mc7GZxThpyQx3jcQ=; b=cGp+K5sddqut6+Cj8R7Fo4s2/NXfahnCSA+7AooZ0XIzZ2vYW6ababXVUa93OJ1k+i fR0bIj5y1NTvYEnRYDmPYJAh+auUNeMFRxpKLguWm9VaZIa6rwFIlinZ6qN853hf0ggE drpUQqW6w/EXx4ftFtFkcQAzLvSddRGGB6d+ENQvVOzcd6LvdeksfaUuj4Gu93kxPAU1 oEMvntx7lLUcpsXIfEy8zLSglidwWDEVSRYYmnwzRwYT3cncWd/S6yp2d6Rq2G2IfHV8 /hGTrNbUg4LZ2con84dE0qXi7UQhnCnQIK21cORY70xesZyFHaAdEJdaCfz4ayKz9Fzt COHw== X-Received: by 10.66.221.138 with SMTP id qe10mr32794071pac.45.1438592467602; Mon, 03 Aug 2015 02:01:07 -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 cr4sm16768026pac.10.2015.08.03.02.01.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Aug 2015 02:01:05 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Eric Lombrozo In-Reply-To: Date: Mon, 3 Aug 2015 02:01:02 -0700 Message-Id: <9D6A80DF-83E6-4F98-B7C2-2EE2F79CB2D1@gmail.com> References: <55BF153B.9030001@bitcartel.com> <291F9D27-024C-4982-B638-1ACDC4FE0672@gmail.com> <9A5F47B8-AD42-46CB-993B-661BAD0E62AC@gmail.com> To: Hector Chu X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 09:01:09 -0000 --Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E Content-Type: multipart/alternative; boundary="Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62" --Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 3, 2015, at 1:52 AM, Hector Chu wrote: >=20 > On 3 August 2015 at 09:38, Eric Lombrozo > 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. >=20 > 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. >=20 If it=E2=80=99s an as-of-yet unidentified issue that comes up, = yes=E2=80=A6obviously we can=E2=80=99t plan for everything and we=E2=80=99= ll make some mistakes. But here we=E2=80=99re talking about specific = well-known issues (or at least well-known today) for which several = people have proposed potential solutions. However, these things have = been all but ignored in the public discourse. > 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. >=20 > 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. 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 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. > 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. >=20 > 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. 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 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 want to keep a particular consensus rule that = benefits them even if the core developers disagree? >=20 > - Eric >=20 >> On Aug 3, 2015, at 1:31 AM, Hector Chu > 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 > 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 = > wrote: >>>=20 >>> On 3 August 2015 at 08:53, Adam Back > 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 = >>=20 >>=20 >=20 >=20 --Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 3, 2015, at 1:52 AM, Hector Chu <hectorchu@gmail.com>= wrote:

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.


If it=E2=80=99s an as-of-yet unidentified issue = that comes up, yes=E2=80=A6obviously we can=E2=80=99t plan for = everything and we=E2=80=99ll make some mistakes. But here we=E2=80=99re = talking about specific well-known issues (or at least well-known today) = for which several people have proposed potential solutions. However, = these things have been all but ignored in the public discourse.

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.

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.

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


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.

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.

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 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 want to keep a particular consensus rule that = benefits them even if the core developers disagree?


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

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 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<= /a>





= --Apple-Mail=_A6485220-5643-4509-9DE1-FB5C37267D62-- --Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E 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 iQIcBAEBCgAGBQJVvy3OAAoJEJNAI64YFENUcb0P/3nOiopGk2CoFksA2C+2iTdv p3DUS/Z+m8/CfkekJjlojUCtH5sfZNmG/9/Kp4ds94ug/IPD/KuEYYuGiJ7VJ2OF +8iRUi2Pny1uI6yhDtWMiX7R52K22pU2HjX0gAh+Nrkkt2jqF4KfXNi/H82zS9p5 h6McHwSNbIqAJRFi/QEwS25OjY06nAA91Rm8yMbk4m6CdqWlgonyu969FTTX5XHw ZtbQ590Ugs3UUZiDJMoSpjv2aaVB3ORdX67O6hdSc2EripKYP5I2cBG6r64hsJJu HPZhzPfPY3NUSRCqO6RP/mZhKrenAd2TTylqvLSLGg44vJd3qcPb5BoxZ/RbMaOM As8RSoUrwUJdL8c83YzE3SlnurF7A+BB6PGksJJM3+mvsrLgZobU5SdjMlhZnxGz 8xLApaE3b/AM0ADSI6nkuBvYkK7Ucklh4fF3CXhzrkF2MKuMrQHy1uMcKv+lm9dd 8/vPkjyC/zUl4DpvhwxmoR/7Dh4VFfSUlFQyAAaRxqVKxJVThQnlN7Bl3RHKhgQv 6fK5aVwnbhP9I3voNSFTuld8WfFR0AxXizd73JpjOXC5n6JEELfztlZ222JUHjww dsx7pEYTl84ipgtag8gR+N8ymiRB716kM54JSWXrry9aVQjRWlLOHlDeAcINAnxP MhSEmx4oaOOOxq1tMiB5 =Wmhe -----END PGP SIGNATURE----- --Apple-Mail=_1ED4908E-80B8-4F2A-B4A5-676D6BA5CE7E--