From: Mike Hearn <hearn@vinumeris•com>
To: cipher anthem <cipher.anthem@gmx•com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
Date: Sat, 19 Sep 2015 21:43:32 +0100 [thread overview]
Message-ID: <CA+w+GKRYVbck1rfAAVcxkG8FwoSK93ZSjL0xTBd87J1Xs1Dmuw@mail.gmail.com> (raw)
In-Reply-To: <trinity-83bd9372-08bc-4c3e-812f-206ed3322913-1442678624612@3capp-mailcom-bs16>
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 2024 bytes --]
next prev parent reply other threads:[~2015-09-19 20:43 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-16 21:32 Jeff Garzik
2015-09-16 21:51 ` Matt Corallo
2015-09-18 5:55 ` Mark Friedenbach
2015-09-18 17:10 ` Dave Scotese
2015-09-18 17:28 ` Eric Lombrozo
2015-09-18 20:06 ` Matt Corallo
2015-09-18 22:33 ` Mike Hearn
2015-09-19 16:03 ` cipher anthem
2015-09-19 20:43 ` Mike Hearn [this message]
2015-09-19 1:47 ` Peter Todd
2015-09-19 6:06 ` NxtChg
2015-09-19 6:56 ` Eric Voskuil
2015-09-19 7:27 ` NxtChg
2015-09-19 7:39 ` Eric Voskuil
2015-09-19 7:57 ` NxtChg
2015-09-19 8:52 ` Eric Voskuil
2015-09-19 13:32 ` NxtChg
2015-09-19 20:57 ` Mike Hearn
2015-09-19 21:53 ` phm
2015-09-20 1:26 ` Dave Scotese
2015-09-20 2:18 ` Milly Bitcoin
2015-09-20 9:18 ` NxtChg
2015-09-20 9:25 ` Mike Hearn
2015-09-20 15:43 ` Mark Friedenbach
2015-09-20 16:21 ` NxtChg
2015-09-20 16:34 ` Milly Bitcoin
2015-09-20 20:23 ` Steven Pine
2015-09-20 20:54 ` Milly Bitcoin
2015-09-20 21:33 ` s7r
2015-09-20 21:45 ` Eric Lombrozo
2015-09-20 22:02 ` Milly Bitcoin
2015-09-20 22:21 ` Eric Lombrozo
2015-09-20 22:51 ` Milly Bitcoin
2015-09-20 23:11 ` Eric Lombrozo
2015-09-21 0:11 ` Dave Scotese
2015-09-21 5:04 ` Corey Haddad
2015-09-21 11:45 ` Milly Bitcoin
2015-09-21 8:48 ` NxtChg
2015-09-20 21:10 ` NxtChg
2015-09-20 21:13 ` Steven Pine
2015-09-20 21:34 ` Milly Bitcoin
2015-09-20 21:24 ` Milly Bitcoin
2015-09-20 21:16 ` Eric Lombrozo
2015-09-21 10:30 ` Mike Hearn
2015-09-18 22:15 ` [bitcoin-dev] Improving Blocksize Communication Through Markets Paul Sztorc
2015-09-20 11:41 ` Isidor Zeuner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+w+GKRYVbck1rfAAVcxkG8FwoSK93ZSjL0xTBd87J1Xs1Dmuw@mail.gmail.com \
--to=hearn@vinumeris$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=cipher.anthem@gmx$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox