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 38712273 for ; 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 ; Mon, 3 Aug 2015 08:38:45 +0000 (UTC) Received: by pdbbo16 with SMTP id bo16so13784181pdb.1 for ; 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 In-Reply-To: Date: Mon, 3 Aug 2015 01:38:41 -0700 Message-Id: <9A5F47B8-AD42-46CB-993B-661BAD0E62AC@gmail.com> References: <55BF153B.9030001@bitcartel.com> <291F9D27-024C-4982-B638-1ACDC4FE0672@gmail.com> To: Hector Chu 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 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 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 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 --Apple-Mail=_70A2DB77-7D90-4E98-BFCF-1D755547EF49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; 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:

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=_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--