path: root/c5/cc7b336c2982a819d259577fd40d13fbc36526

Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 56CA25B1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 19:52:12 +0000 (UTC)
Received: by wicgb10 with SMTP id gb10so157801516wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
	<CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
	<CAPWm=eW8RgrG1CMEAMN4GeiMjZecFvNtZB_Y4rZNeofWSD0=Wg@mail.gmail.com>
	<CADm_WcYCUHs9Qe_T6WJOCUSK6stXYD8v6z5JcGHfRMURoOSFTA@mail.gmail.com>
	<CABm2gDq3JyZx0QCRDbcNSLSOBKdpi4h_7VN1XL8N42U38+eBAA@mail.gmail.com>
	<55B113AF.40500@thinlink.com>
	<CABsx9T1MTc-GmuQyFN1vaFK=CDWV_L214Pi9nR6jLMouQQD0fw@mail.gmail.com>
	<C5A70F53-4779-457A-A06A-686877706F89@gmail.com>
	<CADL_X_exckh5T2BfzPEp26fPR3TD69QarwroDEdS_9wtnKbf+g@mail.gmail.com>
	<6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com>
Date: Thu, 23 Jul 2015 15:52:11 -0400
Message-ID: <CADL_X_fs3-Zj-9nHu5HXCS=kNFUTJkrUR_8SL+d+M4ziwB66Jw@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <elombrozo@gmail.com> wrote:

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:elombrozo@gmail.com" target=3D"_blank">elombrozo@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-wor=
d"><br><div><span class=3D""><blockquote type=3D"cite"><div>On Jul 23, 2015=
, at 11:10 AM, Jameson Lopp &lt;<a href=3D"mailto:jameson.lopp@gmail.com" t=
arget=3D"_blank">jameson.lopp@gmail.com</a>&gt; wrote:</div><br><div><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varian=
t:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px;float:none;display:inline!important">Larger block sizes don&#39;t s=
cale the network, they merely increase how much load we allow the network t=
o bear.</span></div></blockquote><div><br></div></span><div>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.</div><div><br></div><d=
iv>Larger blocks support more transactions=E2=80=A6but they also incur=C2=
=A0<span>=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.</spa=
n></div></div></div></blockquote><div><br></div>Running a node certainly ha=
s real-world costs that shouldn&#39;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&#39;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&#39;t be &#39;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&#39;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.</div><div=
 class=3D"gmail_quote"><div>=C2=A0=C2=A0</div><div>- Jameson</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div style=3D"word-wrap:break-word"><div><span class=3D""><span><br=
></span><blockquote type=3D"cite"><div><span style=3D"font-family:Helvetica=
;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;le=
tter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;tex=
t-transform:none;white-space:normal;word-spacing:0px;float:none;display:inl=
ine!important">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&quot; usage. This is not an either/or proposition - we clearl=
y need both.</span></div></blockquote></span></div><br><div>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.</div></div></blockquote></div><br></div></div>

--f46d044280ee1ff9e1051b9039b9--