From: Tom Harding <tomh@thinlink•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Block Size Experiment Underway
Date: Sun, 07 Jun 2015 17:36:44 -0700 [thread overview]
Message-ID: <5574E39C.3090904@thinlink.com> (raw)
In September, 2014, a collective experiment began in the bitcoin
ecosystem. Available block space (1MB) began to sometimes fall short of
the space required to mine all of the transactions that would otherwise
have been included.
This chart, posted earlier, shows the onset of the
some-blocks-at-maximum era. http://i.imgur.com/5Gfh9CW.png
Although the average block is only about 400K, real blocks are bigger or
smaller due to the random length of time between blocks (and other
factors). I look at how often this is predicted to happen.
Recently, transactions have been confirmed at a rate of about
100000/day*. The average transaction size for the past 6000 blocks has
been 545 bytes. Using these values,
txesPerMinute = 100000 / 24 / 60 = 69.4
txesInMaxBlock = 999977 / 545 = 1834
minutesToFillBlock = txesInMaxBlock/txesPerMinute = 26.4
Using the theoretical formula for the time before an inter-block
interval of at least a given length **
blockChickenMinutes[x] := 10 (exp(x/10) - x/10 - 1)
we obtain
minutesBetweenFullBlocks = blockChickenMinutes[minutesToFillBlock] = 104
We currently expect a maximum-size block every 1 hour + 44 minutes, on
average. If the transaction rate doubles, we should expect a
maximum-size block every 14 minutes, on average. The non-linearity
makes sense, because doubling the average without raising the maximum
requires disproportionately more maximum-size blocks.
This estimate is understated because transaction size and submission
rate have their own distributions. Using the averages of 545 bytes and
100000/day ignores the fact that for some blocks, there are unusually
big and/or numerous transactions, which increases the block size
variance and causes blocks over the threshold to be encountered more
frequently.
These calculations are confirmed by empirical observation of the most
recent 6000 blocks:
http://i.imgur.com/0pQUsdl.png
In many cases, the miner chose to create a 750KB block, which is
unusually likely to be followed by another 750KB or 1MB block, because
the next interval starts off with a 250KB backlog. Some backlog
transactions may experience more than 1 block delay in these cases.
* https://www.quandl.com/data/BCHAIN/NTRAN-Bitcoin-Number-of-Transactions
** This is a chicken-crossing-the-road problem. Wait time = (exp(λx) −
λx - 1) / λ
Some discussion at
https://github.com/nanotube/supybot-bitcoin-marketmonitor/pull/68.
next reply other threads:[~2015-06-08 0:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 0:36 Tom Harding [this message]
2015-06-08 20:07 ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit Raystonn .
[not found] ` <AD4A025F-D782-4094-9CBC-EBEF0DD04838@newcastle.ac.uk>
2015-06-08 21:14 ` Raystonn .
2015-06-08 21:33 ` Peter Todd
2015-06-08 21:40 ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit Raystonn .
[not found] ` <4A74E0B9-869E-448A-BFC7-7FD2F50F142F@newcastle.ac.uk>
2015-06-08 22:26 ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit Peter Todd
[not found] ` <7E7DF414-6DDB-48A6-9199-D6883209B67D@newcastle.ac.uk>
2015-06-08 21:33 ` Raystonn .
2015-06-08 21:44 ` Peter Todd
2015-06-08 22:01 ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit Raystonn .
2015-06-08 22:07 ` Btc Drak
2015-06-08 22:10 ` Raystonn .
2015-06-08 22:18 ` Peter Todd
2015-06-08 22:46 ` Raystonn .
2015-06-08 22:06 ` [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit Bob McElrath
2015-06-08 22:28 ` Peter Todd
2015-06-09 9:33 ` Loi Luu
2015-06-09 13:36 ` Gavin Andresen
2015-06-09 14:18 ` Tier Nolan
2015-06-09 17:52 ` Raystonn .
2015-06-09 18:25 ` Gavin Andresen
2015-06-09 19:03 ` Raystonn .
2015-06-20 3:49 ` David Vorick
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=5574E39C.3090904@thinlink.com \
--to=tomh@thinlink$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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