diff options
| author | Jameson Lopp <jameson.lopp@gmail.com> | 2015-07-23 15:52:11 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-07-23 19:52:13 +0000 |
| commit | 3b6ca7495280dd6928b58d20daf1c51ed870c8fd (patch) | |
| tree | d3d85203727ab665630a4603b1eed8239189c364 | |
| parent | becf62263ee6d538864ceb7f5ee67511c1833c89 (diff) | |
| download | pi-bitcoindev-3b6ca7495280dd6928b58d20daf1c51ed870c8fd.tar.gz pi-bitcoindev-3b6ca7495280dd6928b58d20daf1c51ed870c8fd.zip | |
Re: [bitcoin-dev] Bitcoin Core and hard forks
| -rw-r--r-- | c5/cc7b336c2982a819d259577fd40d13fbc36526 | 208 |
1 files changed, 208 insertions, 0 deletions
diff --git a/c5/cc7b336c2982a819d259577fd40d13fbc36526 b/c5/cc7b336c2982a819d259577fd40d13fbc36526 new file mode 100644 index 000000000..6681d30c1 --- /dev/null +++ b/c5/cc7b336c2982a819d259577fd40d13fbc36526 @@ -0,0 +1,208 @@ +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"><<a= + href=3D"mailto:elombrozo@gmail.com" target=3D"_blank">elombrozo@gmail.com<= +/a>></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 <<a href=3D"mailto:jameson.lopp@gmail.com" t= +arget=3D"_blank">jameson.lopp@gmail.com</a>> 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'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'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.</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" 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-- + |