summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMike Hearn <hearn@vinumeris.com>2015-09-19 21:43:32 +0100
committerbitcoindev <bitcoindev@gnusha.org>2015-09-19 20:43:34 +0000
commit543d9879b778bafa4170e2840311f33e52aaa664 (patch)
tree0cf2ce67e0f4c6194e5dd8545d6fdaa0ed58b18b
parent1d0e2ea01186f3a2706fc962082fd7f8c114cc3d (diff)
downloadpi-bitcoindev-543d9879b778bafa4170e2840311f33e52aaa664.tar.gz
pi-bitcoindev-543d9879b778bafa4170e2840311f33e52aaa664.zip
Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
-rw-r--r--12/9034a5675d619094d9be1548f9bab344e1af26142
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 &quot;kick the can down the road&quot; 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 &quot;kicka the can&quot; proposal=
+ you will outright reject it?</div></div></div></div></blockquote><div><br>=
+</div><div>Which part of &quot;in the next few years&quot; 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&#39;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&#39;d have been ha=
+ppy with no upper limit at all. There&#39;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&#39;m willing to compromise.</div></div=
+></div></div>
+
+--089e011767bf9c42cd05201fb3ac--
+