From: Tom Harding <tomh@thinlink•com>
To: Adam Back <adam@cypherspace•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] block-size tradeoffs & hypothetical alternatives (Re: Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it)
Date: Tue, 30 Jun 2015 15:56:04 -0700 [thread overview]
Message-ID: <55931E84.3060307@thinlink.com> (raw)
In-Reply-To: <CALqxMTG1=+F8DSeRAThtTSmj4F3YhgUiCbqJ1CfBy9Z-LLZvSQ@mail.gmail.com>
On 6/30/2015 12:54 PM, Adam Back wrote:
> Secondly on the interests and incentives - miners also play an
> important part of the ecosystem and have gone through some lean times,
> they may not be overjoyed to hear a plan to just whack the block-size
> up to 8MB. While it's true (within some limits) that miners could
> collectively keep blocks smaller, there is the ongoing reality that
> someone else can take break ranks and take any fee however de minimis
> fee if there is a huge excess of space relative to current demand and
> drive fees to zero for a few years. A major thing even preserving
> fees is wallet defaults, which could be overridden(plus protocol
> velocity/fee limits).
Let's pretend it is late 2012.
Nobody has ever violated the soft limit of 500KB/block.
Block reward is about to be cut in half.
Fees are right where they are today.
1 BTC = about $15.
It's a good thing nothing was done in 2012 to try to boost fees out of
concern for miner profits.
Nor should we today. The 16X rise in the economic value¹ of the block
reward since that time covers the entire .5X effect of the halving
itself, plus three additional halvings. There is far less reason today
to worry on miners' behalf about fees than there was in late 2012.
Running out of ways to grow does threaten miner profit, and therefore
security, growth. So let's hope all the scaling ideas work.
> I'm not sure if anyone has a clear picture of what limits are imposed
> by hash-rate even today.
From the all-blocksizes plot, it's clear visually that the 750K soft
limit, and another less common soft limit at 900K, are being imposed,
but broken more and more frequently as demand outpaces them.
These soft limits serve no purpose, other than to delay transactions. A
750KB block is followed by another 750KB or larger block just as
frequently as you would expect from the actual block time distribution,
which recently (prior to spam now underway) had a rate of a full 1MB
block being needed every 104 minutes (in an earlier post I gave a
relation which is very stable, given the stable average transaction size).
___________________
¹Someday, if bitcoin is wildly successful, exchange rates vs. obsolete
currencies won't be meaningful. If that happens, increases in the
economic value of bitcoin will likely be measured by decreases in the
general price level of all goods and services.
prev parent reply other threads:[~2015-06-30 22:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 19:54 Adam Back
2015-06-30 20:08 ` Justus Ranvier
2015-06-30 20:29 ` Milly Bitcoin
2015-06-30 22:55 ` Simon Liu
2015-06-30 22:56 ` Tom Harding [this message]
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=55931E84.3060307@thinlink.com \
--to=tomh@thinlink$(echo .)com \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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