public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Date: Sun, 31 May 2015 03:13:30 +0300	[thread overview]
Message-ID: <CAE28kUSe07r=Z4WtcsAQ211iO3W_fb_Na89UhhMOoX95ef-H1A@mail.gmail.com> (raw)
In-Reply-To: <44570322-FBAE-4BAF-A0DA-2E478EF436B4@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]

> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
>
> Do you anticipate linear growth?
>

It's safe to say that absolutely nobody can predict the actual growth with
any degree of an accuracy.
I believe that linear growth compares very favorably to other alternatives:

1. Exponential growth: Linear growth is better at modelling diminishing
returns, that is, risk that it grows too much is much smaller. At the same
time initially it will grow faster than reasonable exponential models.
   E.g. linear year-over-year relative growth:    100% 50% 33% 25% ...10%
   While exponential one which gives the same result in 10 years:
   25% 25% ... 25%
   This is on the same scale, but exponential starts slower than we want at
start (1.25 MB will be too little for 2016 as we already see fully filled 1
MB blocks), but goes a bit too fast in the long term. It's highly unlikely
we'll see bandwidth growing 10x each 10 years in the long term.

2. Single step increase: an obvious advantage is that linear growth gives
us time to adapt to near realities, time to change something if there is an
unwanted effects, etc. At the same a single step is not a long-term
solution.
While a slow-but-steady growth might be.

3. Adaptive solutions (e.g. limit depends on the last N blocks or something
of that nature):
  The problem with them is that they are  rather complex, and also:
  3.1. prone to manipulation: somebody might try to push the limit if it
will favor him in future
  3.2. possibility of a positive feedback loop.
  3.3. possibility of an unhealthy game-theoretic dynamics

The main problem is that we do not understand game theoretic aspects of
bitcoin mining in presence of various real-world factors such as block
propagation delays. Thus we can't design a proper adaptive solution.


There is no perfect solution to this problem as we cannot predict the
future and our understanding is limited.
But among the 5 alternatives (linear, exponential, single step, adaptive,
no limit), linear seems to be the best option at this point as it's both
quite safe and doesn't stunt growth too much.

> bitcoin is really really small right now, any sign of real adoption could
make it grow 100x or even more in a matter of weeks.

This is certainly possible, but the thing is:

1) this can't be predicted;
2) this will be a serious problem for many bitcoind installations;
3) it's not necessarily a healthy thing, perhaps it will grow 100x in a
matter of weeks, and then will go to zero in matter of weeks as well.

So I don't think that sudden growth spurts is something we should take into
account on the planning stage. If anything we'd like to prevent them from
happening, slow growth is usually better.

[-- Attachment #2: Type: text/html, Size: 3791 bytes --]

  reply	other threads:[~2015-05-31  0:13 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-07 22:02 [Bitcoin-development] Block Size Increase Requirements Matt Corallo
2015-05-07 23:24 ` Joseph Poon
2015-05-08  0:05 ` Peter Todd
2015-05-08  6:33   ` Arkady
2015-05-08 10:03 ` Mike Hearn
2015-05-08 16:37   ` Peter Todd
2015-05-08 19:47     ` Tier Nolan
2015-05-09  3:08       ` Peter Todd
2015-05-16  4:39         ` Stephen
2015-05-16 11:29           ` Tier Nolan
2015-05-16 11:25         ` Tier Nolan
2015-05-29 22:36 ` Gavin Andresen
2015-05-29 23:25   ` Matt Corallo
     [not found]     ` <CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
2015-05-30 19:32       ` Matt Corallo
2015-05-30 20:37         ` Gavin Andresen
2015-05-31 14:46           ` Jorge Timón
2015-05-31 14:49             ` Gavin Andresen
2015-05-31 14:59               ` Jorge Timón
2015-05-31 15:08                 ` Gavin Andresen
2015-05-31 15:45                   ` Jorge Timón
2015-05-29 23:42 ` Chun Wang
2015-05-30 13:57   ` Gavin Andresen
2015-05-30 14:08     ` Pindar Wong
2015-05-30 22:05     ` Alex Mizrahi
2015-05-30 23:16       ` Brian Hoffman
2015-05-31  0:13         ` Alex Mizrahi [this message]
2015-05-31  5:05       ` gb
     [not found]     ` <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
2015-05-31  1:31       ` [Bitcoin-development] Fwd: " Chun Wang
2015-05-31  2:20         ` Pindar Wong
2015-05-31 12:40         ` Gavin Andresen
2015-05-31 13:45           ` Alex Mizrahi
2015-05-31 14:54             ` Gavin Andresen
2015-05-31 22:55               ` Alex Mizrahi
2015-05-31 23:23                 ` Ricardo Filipe
2015-05-31 23:40                   ` Pindar Wong
2015-05-31 23:58                     ` Ricardo Filipe
2015-06-01  0:03                       ` Pindar Wong
2015-06-01  7:57                   ` Alex Mizrahi
2015-06-01 10:13                     ` Mike Hearn
2015-06-01 10:42                       ` Pindar Wong
2015-06-01 11:26                         ` Peter Todd
2015-06-01 12:19                           ` Pindar Wong
2015-06-01 11:02                       ` Chun Wang
2015-06-01 11:09                         ` Pindar Wong
2015-06-01 11:20                         ` Chun Wang
2015-06-01 13:59                           ` Gavin Andresen
2015-06-01 14:08                             ` Chun Wang
2015-06-01 15:33                               ` Mike Hearn
2015-06-01 16:06                                 ` Ángel José Riesgo
2015-06-01 14:46                             ` Oliver Egginger
2015-06-01 14:48                               ` Chun Wang
2015-06-01 16:43                             ` Yifu Guo
2015-06-01 20:01                             ` Roy Badami
2015-06-01 20:15                               ` Roy Badami
2015-06-01 13:21                         ` Mike Hearn
2015-06-01 12:29                       ` Warren Togami Jr.
2015-06-01 13:15                 ` Gavin Andresen
2015-05-31 12:52         ` Gavin Andresen
2015-05-31 13:31           ` [Bitcoin-development] [Bulk] " gb
2015-05-31 19:49             ` Gavin Andresen
2015-05-31 14:17           ` [Bitcoin-development] " Dave Hudson
2015-05-31 14:34         ` Yifu Guo
2015-05-31 14:47           ` Gavin Andresen
2015-05-31  7:05   ` [Bitcoin-development] " Peter Todd
2015-05-31 12:51     ` Gavin Andresen
2015-05-30 23:18 Raystonn
2015-05-31  0:32 ` Alex Mizrahi

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='CAE28kUSe07r=Z4WtcsAQ211iO3W_fb_Na89UhhMOoX95ef-H1A@mail.gmail.com' \
    --to=alex.mizrahi@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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