Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F24D7C3 for ; Thu, 23 Jul 2015 19:14:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2EE851E1 for ; Thu, 23 Jul 2015 19:14:54 +0000 (UTC) Received: by padck2 with SMTP id ck2so800101pad.0 for ; Thu, 23 Jul 2015 12:14:53 -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=CGUnlcD8DwYgPQbOmIpfbRQH7cNh4+QXTHExy27e9sg=; b=RTbETUlvidHiJsXz5xFgX0NVxssW8gzzlU7iPqSeWvs498aBALHgwtlizdJ9xsIJ0l MY/M06GUJCo/r8OhVY/RFEYIaOEr/VmqIBNI8jeo9ayfL9JyCifypc5yJwpgBhw1gyQk 86qvI4BGnWRMJIWEHwaJFZoEIT9ksn1fVz6Sb9NuAIaZUM6WuxGIajQpx/OdODhDGw6Q jwD2P+uhHfoLIf/ui47yiG/FKKEngqFMn98SkiAQXj5yJclGNOGWjnZYIlGPcC6vEfIu D+SjlNN+i8P3cOF/2MC4flE1NOjqcxPKnosTx81YQo82IB1OdX9Q8Q4AA2ALKxknFouA iz1w== X-Received: by 10.66.119.136 with SMTP id ku8mr21377151pab.26.1437678893845; Thu, 23 Jul 2015 12:14:53 -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 cr4sm10442642pac.10.2015.07.23.12.14.51 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 12:14:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9FBF5784-AA01-41F6-BAD5-B616C9CA39D9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: Date: Thu, 23 Jul 2015 12:14:50 -0700 Message-Id: <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com> References: <55B113AF.40500@thinlink.com> To: Jameson Lopp 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks 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: Thu, 23 Jul 2015 19:14:54 -0000 --Apple-Mail=_9FBF5784-AA01-41F6-BAD5-B616C9CA39D9 Content-Type: multipart/alternative; boundary="Apple-Mail=_E62BCCCD-DB48-4CA8-BF70-E60D4BF301A3" --Apple-Mail=_E62BCCCD-DB48-4CA8-BF70-E60D4BF301A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 23, 2015, at 11:10 AM, Jameson Lopp = wrote: >=20 > Larger block sizes don't scale the network, they merely increase how = much load we allow the network to bear. Very well put, Jameson. And the cost of bearing this load must be paid = for. And unless we=E2=80=99re willing to accept that computational = resources are finite and subject to the same economic issues as any = other finite resource, our incentive model collapses the security of the = network will be significantly at risk. Whatever your usability concerns = may be regarding fees, when the security model=E2=80=99s busted = usability issues are moot. Larger blocks support more transactions=E2=80=A6but they also incur = =CE=A9(n) overhead in bandwidth, CPU, and space. These are finite = resources that must be paid for somehow=E2=80=A6and as we all already = know miners are willing to cut corners on all this and push the costs = onto others (not to mention wallets and online block explorers). And who = can really blame them? It=E2=80=99s rational behavior given the skewed = incentives. > On the flip side, the scalability proposals will still require larger = blocks if we are ever to support anything close to resembling = "mainstream" usage. This is not an either/or proposition - we clearly = need both. Mainstream usage of cryptocurrency will be enabled primarily by direct = party-to-party contract negotiation=E2=80=A6with the use of the = blockchain primarily as a dispute resolution mechanism. The block size = isn=E2=80=99t about scaling but about supply and demand of finite = resources. As demand for block space increases, we can address it either = by increasing computational resources (block size) or by increasing = fees. But to do the former we need a way to offset the increase in cost = by making sure that those who contribute said resources have incentive = to do so. --Apple-Mail=_E62BCCCD-DB48-4CA8-BF70-E60D4BF301A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 23, 2015, at 11:10 AM, Jameson Lopp <jameson.lopp@gmail.com> wrote:

Larger block sizes don't scale the network, they = merely increase how much load we allow the network to = bear.

Very well = put, Jameson. And the cost of bearing this load must be paid for. And = unless we=E2=80=99re willing to accept that computational resources are = finite and subject to the same economic issues as any other finite = resource, our incentive model collapses the security of the network will = be significantly at risk. Whatever your usability concerns may be = regarding fees, when the security model=E2=80=99s busted usability = issues are moot.

Larger blocks = support more transactions=E2=80=A6but they also incur =CE=A9(n) overhead in bandwidth, CPU, and space. These are = finite resources that must be paid for somehow=E2=80=A6and as we all = already know miners are willing to cut corners on all this and push the = costs onto others (not to mention wallets and online block explorers). = And who can really blame them? It=E2=80=99s rational behavior given the = skewed incentives.

On the flip side, the = scalability proposals will still require larger blocks if we are ever to = support anything close to resembling "mainstream" usage. This is not an = either/or proposition - we clearly need = both.

Mainstream usage of cryptocurrency will be enabled primarily = by direct party-to-party contract negotiation=E2=80=A6with the use of = the blockchain primarily as a dispute resolution mechanism. The block = size isn=E2=80=99t about scaling but about supply and demand of finite = resources. As demand for block space increases, we can address it either = by increasing computational resources (block size) or by increasing = fees. But to do the former we need a way to offset the increase in cost = by making sure that those who contribute said resources have incentive = to do so.
= --Apple-Mail=_E62BCCCD-DB48-4CA8-BF70-E60D4BF301A3-- --Apple-Mail=_9FBF5784-AA01-41F6-BAD5-B616C9CA39D9 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 iQIcBAEBCgAGBQJVsT0qAAoJEJNAI64YFENUUy4QAI2R3om8U7/fEXHjiH+iRFz2 qL8AnmS/7ZyJ1U93vIZkHlqkBsm98RoicPCxMUcaiqI0+C8Nbvv6GUqL4DpraPGu +PR8OdM+HVccdmVQbtd84Cr9oriQN0j/TZkOxxV3RrOXXR4PJYyQ+bIuK4REgV9H FW95w1Z4ydWrzilt3HN2gMZZ9514L40BLBR7s2MRIk6yndVyuq5Dxy/YJ5vXyuXR YKGHAPAvaGyvy08xWErasgBsIL49pILSiop1YS04WrrwmNA+5lELrxZV6KzNdXF+ VLWVsraiV5DjEMNnCLD2hPSBCnY9c/ddWJ0GtqggOwvz0UrXYdkwypK6shumXNWT ziFNoPMDbdZx8TsYI3gNZfkzcaeyXh8Moe+CQCyxOjv+RwmNpnIBhViAoneVDUNr A/ykAZFChkonytb5qh7BvyQ87M5N1qfuGx1Ry5q9ly7UIbxEGY8vMkb+cVl6JCLx Ch9TJH3EynoGovUcUBFlP0mYM/G8G02tI9AH9EP90nDiMJgaQEzFAOJm0L+tA4u6 9EWTu5vhWctBzNZRzl5MW7QPxUetLUf3zh4bTS6ZZPXxe2XsOQMJbrF7oNmSnYoA Qlrmbf70TMBMuKd/hoGVzVKsAuvUpH4zhEqsT2cXwNtioReBGqLpXXDtuW853oCX V9GBKlKs7kHiS62iEnrm =FHgN -----END PGP SIGNATURE----- --Apple-Mail=_9FBF5784-AA01-41F6-BAD5-B616C9CA39D9--