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 56CA25B1 for ; Thu, 23 Jul 2015 19:52:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69E4B157 for ; Thu, 23 Jul 2015 19:52:12 +0000 (UTC) Received: by wicgb10 with SMTP id gb10so157801516wic.1 for ; Thu, 23 Jul 2015 12:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MBcduCvf8IBlVrPbmjo8Md/FgjaukjoEOW3UL6TR3N8=; b=IU1qFgfzdF5Dg/pEUYCAdy5/6OMuvcmMrfp5TUJoCXGqpw8eeDUE5BvPkdsDgW6Tpl QRSUM5VIZcBzITvi64rXYvlXr3db6qoVEYJPQfOH2fMdGokUNLvTq9snPVyPbtoNRidv h5rqOHIzDNZYYp05fCvaTvELfZH+3jFYeDrZVhc1LeKdXw1Rz7oyMEAS5E2cU5R0/DEX DVP6ryLU8xJ2zgUBwI30WBtk8j7CaMTCYPCay7IHJUPy76MN2vzTaZR9tyh+yBeRngKO uy557vVFWc9CkG1Dkv7wdmM6vLuWtz1yg2scZQu8v1ynuNOMId4JUTB2AOEScsstYWso YzAQ== MIME-Version: 1.0 X-Received: by 10.180.83.101 with SMTP id p5mr19773219wiy.52.1437681131189; Thu, 23 Jul 2015 12:52:11 -0700 (PDT) Received: by 10.27.171.138 with HTTP; Thu, 23 Jul 2015 12:52:11 -0700 (PDT) In-Reply-To: <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com> References: <55B113AF.40500@thinlink.com> <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com> Date: Thu, 23 Jul 2015 15:52:11 -0400 Message-ID: From: Jameson Lopp To: Eric Lombrozo Content-Type: multipart/alternative; boundary=f46d044280ee1ff9e1051b9039b9 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:52:13 -0000 --f46d044280ee1ff9e1051b9039b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo wrote: > > On Jul 23, 2015, at 11:10 AM, Jameson Lopp 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 resour= ces 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 pai= d > 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 onlin= e > block explorers). And who can really blame them? It=E2=80=99s rational be= havior > given the skewed incentives. > Running a node certainly has real-world costs that shouldn't be ignored. There are plenty of advocates who argue that Bitcoin should strive to keep it feasible for the average user to run their own node (as opposed to Satoshi's vision of beefy servers in data centers.) My impression is that even most of these advocates agree that it will be acceptable to eventually increase block sizes as resources become faster and cheaper because it won't be 'pricing out' the average user from running their own node. If this is the case, it seems to me that we have a problem given that there is no established baseline for the acceptable performance / hardware cost requirements to run a node. I'd really like to see further clarification from these advocates around the acceptable cost of running a node and how we can measure the global reduction in hardware and bandwidth costs in order to establish a baseline that we can use to justify additional resource usage by nodes. - Jameson > > 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 blockchai= n > 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 computation= al > resources (block size) or by increasing fees. But to do the former we nee= d > a way to offset the increase in cost by making sure that those who > contribute said resources have incentive to do so. > --f46d044280ee1ff9e1051b9039b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo@gmail.com<= /a>> wrote:

On Jul 23, 2015= , at 11:10 AM, Jameson Lopp <jameson.lopp@gmail.com> wrote:

Larger block sizes don't s= cale the network, they merely increase how much load we allow the network t= o 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 s= ubject to the same economic issues as any other finite resource, our incent= ive model collapses the security of the network will be significantly at ri= sk. Whatever your usability concerns may be regarding fees, when the securi= ty model=E2=80=99s busted usability issues are moot.

Larger blocks support more transactions=E2=80=A6but they also incur=C2= =A0=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 other= s (not to mention wallets and online block explorers). And who can really b= lame them? It=E2=80=99s rational behavior given the skewed incentives.

Running a node certainly ha= s real-world costs that shouldn't be ignored. There are plenty of advoc= ates who argue that Bitcoin should strive to keep it feasible for the avera= ge user to run their own node (as opposed to Satoshi's vision of beefy = servers in data centers.) My impression is that even most of these advocate= s agree that it will be acceptable to eventually increase block sizes as re= sources become faster and cheaper because it won't be 'pricing out&= #39; the average user from running their own node. If this is the case, it = seems to me that we have a problem given that there is no established basel= ine for the acceptable performance / hardware cost requirements to run a no= de. I'd really like to see further clarification from these advocates a= round the acceptable cost of running a node and how we can measure the glob= al reduction in hardware and bandwidth costs in order to establish a baseli= ne that we can use to justify additional resource usage by nodes.
=C2=A0=C2=A0
- Jameson
On the flip side, the scalability proposals will still requi= re larger blocks if we are ever to support anything close to resembling &qu= ot;mainstream" usage. This is not an either/or proposition - we clearl= y need both.

Mainstream usag= e of cryptocurrency will be enabled primarily by direct party-to-party cont= ract negotiation=E2=80=A6with the use of the blockchain primarily as a disp= ute resolution mechanism. The block size isn=E2=80=99t about scaling but ab= out supply and demand of finite resources. As demand for block space increa= ses, 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 t= he increase in cost by making sure that those who contribute said resources= have incentive to do so.

--f46d044280ee1ff9e1051b9039b9--