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 9DA77273 for ; Mon, 3 Aug 2015 08:20:46 +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 E1A6914E for ; Mon, 3 Aug 2015 08:20:45 +0000 (UTC) Received: by pawu10 with SMTP id u10so7227668paw.1 for ; Mon, 03 Aug 2015 01:20: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=T//hMPrZvGDLfFzTV6dNXgmHhHnLY8fIxfqc6i5Bn2c=; b=rtxEZQaUmaU4f9yPhsgceaUdPjIUDs5jRNT9cM/pc9wcaupvLzJdsTFvd/5nJqjDnH ZVWObgzKDweqOSI0Gs4YBPlForx1YolblbX92U/wQqNcmh5+y42e3ZdyaFjR9fPn6Gi9 UTXnmFnk+yn9Nufe0MKUNPL2atEk5UVhLzQ/4oczfP6ph540mYxMBwb/71gR0jaK6PDF jBgquSRo+rN3FLiLupDLH90FHARZmq1dB9pUPoPMN8oluIIBWu8P8EXwbVwqSnlbj3HP +RwAXIuDvybbzGy1m8Kz7zcb5o0lbBRW5cvZszvYk65q0b/jrgVQUBb4b2d8yOxlkRSG BtUQ== X-Received: by 10.66.194.201 with SMTP id hy9mr33626480pac.140.1438590045652; Mon, 03 Aug 2015 01:20: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 hb1sm6965547pbd.36.2015.08.03.01.20.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Aug 2015 01:20:42 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_56AD65B9-5CF0-45D0-A28B-F192CAF4CDFD"; 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:20:39 -0700 Message-Id: <291F9D27-024C-4982-B638-1ACDC4FE0672@gmail.com> References: <55BF153B.9030001@bitcartel.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:20:46 -0000 --Apple-Mail=_56AD65B9-5CF0-45D0-A28B-F192CAF4CDFD Content-Type: multipart/alternative; boundary="Apple-Mail=_AC793FED-BBDD-4E36-91A2-DF4B7F37AE6F" --Apple-Mail=_AC793FED-BBDD-4E36-91A2-DF4B7F37AE6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = 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 --Apple-Mail=_AC793FED-BBDD-4E36-91A2-DF4B7F37AE6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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<= br class=3D"">

= --Apple-Mail=_AC793FED-BBDD-4E36-91A2-DF4B7F37AE6F-- --Apple-Mail=_56AD65B9-5CF0-45D0-A28B-F192CAF4CDFD 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 iQIcBAEBCgAGBQJVvyRXAAoJEJNAI64YFENUIDAP/jLEUfO3nILE/63CqwuVasnu Lgk+7MIzaxVaxYbdWaJCTshfck2GAldM3Sgm0zJQ5+QqhrfPLncCQkTlYTSkQ5EY 7Q8cu1VoP9Zm6hhGzQt8b2Q072pWY8SbHm1tZBhA5isIN4AMgR8VqIHUcA683XYb Cd3UHlkE2IQjzxiOdY7CrD5x0Li87yAXw6f0iPI/eJ8SuzBt4syz2aEiG9EPCTSy ZFJHCdeEjXqyPkiHI/AcPnG0vbm/G1bitQmdwdmYF6ESQ3oUL137SndH38X2tX0w Wr5VATzZ4DYMa2HwXOZaKZJ+61L/mQ/9g3B0t4ZSsWeqTs4oZLK5TDQF6n0lQDJJ VfpS4H8uZBKJd6NjJpwvMtKXbomyBnDej6GNiDXcleMEZ9X9N/96GgSPZQBYh83c ++0nj6nDtmFMaq4LUxVYFm915/ZQHDDT2cFHjmU7oLzXRwfSWBC25FIEEz8vpquC EEUK5c/S0F+vdfsJfe7IhU8je3d4qJfxOADcSe+OUD3/4K/SE3FoYCpnEyiB8Biv lmp39rs6OvUcO2jHOQa/DgqgwKO8+y8DFYrJDhRa2cu05y4kFOwi5s0VfCf9GzQD dmRENp5lR0PJ83kcl1PRz3xOwd5jHlb+Yepl+OptZZXXMg+oB90tnPg9wNXTRguT UTXF40Hi+ETDd4u4WNNu =o7QC -----END PGP SIGNATURE----- --Apple-Mail=_56AD65B9-5CF0-45D0-A28B-F192CAF4CDFD--