diff options
author | Mike Hearn <hearn@vinumeris.com> | 2015-09-19 21:43:32 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-19 20:43:34 +0000 |
commit | 543d9879b778bafa4170e2840311f33e52aaa664 (patch) | |
tree | 0cf2ce67e0f4c6194e5dd8545d6fdaa0ed58b18b | |
parent | 1d0e2ea01186f3a2706fc962082fd7f8c114cc3d (diff) | |
download | pi-bitcoindev-543d9879b778bafa4170e2840311f33e52aaa664.tar.gz pi-bitcoindev-543d9879b778bafa4170e2840311f33e52aaa664.zip |
Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
-rw-r--r-- | 12/9034a5675d619094d9be1548f9bab344e1af26 | 142 |
1 files changed, 142 insertions, 0 deletions
diff --git a/12/9034a5675d619094d9be1548f9bab344e1af26 b/12/9034a5675d619094d9be1548f9bab344e1af26 new file mode 100644 index 000000000..d84d8f278 --- /dev/null +++ b/12/9034a5675d619094d9be1548f9bab344e1af26 @@ -0,0 +1,142 @@ +Return-Path: <hearn@vinumeris.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 5A62519B5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 19 Sep 2015 20:43:34 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com + [209.85.213.173]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C6B117F + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 19 Sep 2015 20:43:33 +0000 (UTC) +Received: by igbkq10 with SMTP id kq10so38770755igb.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 19 Sep 2015 13:43:33 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=vinumeris.com; s=google; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=KFYsMC1jq1v42d5xxrcXJ6J7RstDUoGVy92V/JSsu/w=; + b=o8yuUJl5zcWM1n0+URcJdsxVI+aVoHYnEa7uIvPGufivL79GQZakGpJa5Qi3XSTihA + RS9mT8sUj16Mf7R7+S7UzG6rjMfs8ZL8sqvN1lVWFbhxBn/rKuBD40vQf//duNjTOakn + oGBz9XB9UGel7JjZFnNtCxPnJ6aRP9KN4ouso= +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:date + :message-id:subject:from:to:cc:content-type; + bh=KFYsMC1jq1v42d5xxrcXJ6J7RstDUoGVy92V/JSsu/w=; + b=d/NoPet6gI4vPAZcP5pfg2WHpKm1SZiNw3yW51FyK9rh7bDb8n8NxAR5eWwsK/VaoO + kLewhpnC8LG4MooPz7Zy8JfvTRlx1L2NVObdS5T6qnd/aAKKXPlWWKLF0DdITYxBMlbj + y/fhz+sRYy47FPtaWqL8QozK2izrAz7EuiAPoCGYgEZEKVxz/ruQr7WV7YqWdWFTGSrt + ZXFkQf5pNDAOfPAwscap6KFx0zrSSxzKCeTCGESp0RD0SBBEXQC9Eud4gYNxfxHSfkZQ + +3hIUwZQEU//la0GYrexLg4UCqeqXbqpxIWvFeZyR6vsffthJJTbvHPgcTVBxqardT0y + sbgQ== +X-Gm-Message-State: ALoCoQm8APVUvqaGhxmAPQN+FSBS+dFMCaT6yCKgBxDzt0qGNcQ5/s1uAH8Cs1pZihsNekOTJZuN +MIME-Version: 1.0 +X-Received: by 10.50.17.4 with SMTP id k4mr4629052igd.34.1442695412980; Sat, + 19 Sep 2015 13:43:32 -0700 (PDT) +Received: by 10.50.192.233 with HTTP; Sat, 19 Sep 2015 13:43:32 -0700 (PDT) +In-Reply-To: <trinity-83bd9372-08bc-4c3e-812f-206ed3322913-1442678624612@3capp-mailcom-bs16> +References: <CADm_WcaLKqhR=WcJ5B52Q9SAAa+AdZY6Kz5OCQVUc_RQm6e9gg@mail.gmail.com> + <55F9E47D.50507@mattcorallo.com> + <CAOG=w-t2ZYQbx8+mG5FX8vzgAC_tb8A6KMABmudHQbrquEqX-Q@mail.gmail.com> + <55FC6EBF.9090504@mattcorallo.com> + <CA+w+GKSK42DjSKqpWj9=s=catGox-n5+AWjh=Mg5=nRpxsf4HQ@mail.gmail.com> + <trinity-83bd9372-08bc-4c3e-812f-206ed3322913-1442678624612@3capp-mailcom-bs16> +Date: Sat, 19 Sep 2015 21:43:32 +0100 +Message-ID: <CA+w+GKRYVbck1rfAAVcxkG8FwoSK93ZSjL0xTBd87J1Xs1Dmuw@mail.gmail.com> +From: Mike Hearn <hearn@vinumeris.com> +To: cipher anthem <cipher.anthem@gmx.com> +Content-Type: multipart/alternative; boundary=089e011767bf9c42cd05201fb3ac +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,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 development mailing list <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report +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: Sat, 19 Sep 2015 20:43:34 -0000 + +--089e011767bf9c42cd05201fb3ac +Content-Type: text/plain; charset=UTF-8 + +> +> Let me get this straight. You start this whole debate with a "kick the can +> down the road" proposal to increase the block size to 20MB, which obviously +> would require another hard fork in the future, but if someone else proposes +> a similar "kicka the can" proposal you will outright reject it? +> + +Which part of "in the next few years" was unclear? + +This seems to be a persistent problem in the block size debates: the +assumption that there are only two numbers, zero and infinity. + +BIP101 tops out at 8 gigabyte blocks, which would represent extremely high +transaction rates compared to today. *If* Bitcoin ever became so popular, +it would be a long way in the future, and many things could have happened: + + 1. Bitcoin may have become as irrelevant as the Commodore 64 is. + 2. We may have invented upgrades that make Bitcoin 100x more efficient + than today. + 3. Hardware may have improved so much that it no longer matters. + 4. The world may have been devastated by nuclear war and nobody gives a + shit about internet currencies anymore, because there is no internet. + +It's silly to ignore the time dimension in these decisions. Bitcoin will +not last forever: even if it becomes very successful it will one day it +will be replaced by something better, so it does not have to handle +infinite usage. + +But hey, as you bring it up, I'd have been happy with no upper limit at +all. There's nothing magic about 8 gigabytes. I go along with BIP 101 +because it is still the only proposal that is both reasonable and +implemented, and I'm willing to compromise. + +--089e011767bf9c42cd05201fb3ac +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= +ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= +cc solid;padding-left:1ex"><div><div style=3D"font-family:Verdana;font-size= +:12.0px"><div><div>Let me get this straight. You start this whole debate wi= +th a "kick the can down the road" proposal to increase the block = +size to 20MB, which obviously would require another hard fork in the future= +, but if someone else proposes a similar "kicka the can" proposal= + you will outright reject it?</div></div></div></div></blockquote><div><br>= +</div><div>Which part of "in the next few years" was unclear?</di= +v><div><br></div><div>This seems to be a persistent problem in the block si= +ze debates: the assumption that there are only two numbers, zero and infini= +ty.</div><div><br></div><div>BIP101 tops out at 8 gigabyte blocks, which wo= +uld represent extremely high transaction rates compared to today. <b>If</b>= +=C2=A0Bitcoin ever became so popular, it would be a long way in the future,= + and many things could have happened:</div><div><ol><li>Bitcoin may have be= +come as irrelevant as the Commodore 64 is.</li><li>We may have invented upg= +rades that make Bitcoin 100x more efficient than today.</li><li>Hardware ma= +y have improved so much that it no longer matters.</li><li>The world may ha= +ve been devastated by nuclear war and nobody gives a shit about internet cu= +rrencies anymore, because there is no internet.</li></ol><div>It's sill= +y to ignore the time dimension in these decisions. Bitcoin will not last fo= +rever: even if it becomes very successful it will one day it will be replac= +ed by something better, so it does not have to handle infinite usage.</div>= +</div><div><br></div><div>But hey, as you bring it up, I'd have been ha= +ppy with no upper limit at all. There's nothing magic about 8 gigabytes= +. I go along with BIP 101 because it is still the only proposal that is bot= +h reasonable and implemented, and I'm willing to compromise.</div></div= +></div></div> + +--089e011767bf9c42cd05201fb3ac-- + |