public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Btc Drak <btcdrak@gmail.com>
To: Patrick Strateman <patrick.strateman@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Date: Mon, 17 Aug 2015 11:51:26 +0100	[thread overview]
Message-ID: <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=vVyw@mail.gmail.com> (raw)
In-Reply-To: <55D1B077.6070208@gmail.com>

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

On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Nobody is going to click that...

I guess I am nobody. Here's a copy of the text:-

*Dynamically Controlled Bitcoin Block Size Max Cap
<http://upalc.com/maxblocksize.php>*

*Assumption*: This article is for those, who already understand the bitcoin
protocol and aware of the block size controversy. Details of the problem
statement can be found in BIP 100
<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>.
Satoshi's opinion regarding block size can be found here
<https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366>. I will be
directly going into the solution without explaining the problem in details.


*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
block each full node does a calculation to find the next target. We will do
just another calculation here. Nodes will also calculate what % of blocks
in the last difficulty period is higher than 90% of the maximum block size,
which is 1 MB for now. If it is found that more than 90% blocks in the last
difficulty period is higher than 90% of the maximum block size, then double
the maximum block size. If not, then calculate what % of blocks in the last
difficulty period is less than 50% of the maximum block size. If it is
higher than 90%, then half the maximum block size. If none of the above
condition satisfies, keep the maximum block size as it is.

Please note that, while calculating the % of blocks, it is better to take
into account the first 2000 of the 2016, than the whole of 2016. This helps
to avoid the calculation mistake if some of the last few blocks get
orphaned.


*Reasoning*: This solution is derived directly from the indication of the
problem. If transaction volume increases, then we will naturally see bigger
blocks. On the contrary, if there are not enough transaction volume, but
maximum block size is high, then only few blocks may sweep the mempool.
Hence, if block size is itself taken into consideration, then maximum block
size can most rationally be derived. Moreover, this solution not only
increases, but also decreases the maximum block size, just like difficulty.


*Other Solutions of this Problem*:-

Making Decentralized Economic Policy
<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by
Jeff Garzik

Elastic block cap with rollover penalties
<https://bitcointalk.org/index.php?topic=1078521> – by Meni Rosenfeld

Increase maximum block size
<https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by Gavin
Andresen

Block size following technological growth
<https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
<https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon &
Thaddeus Dryja


Please share your opinion regarding this solution below. For mail
communication, feel free to write me at bitcoin [at] upalc.com.


> On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
>
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

  reply	other threads:[~2015-08-17 10:51 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-17  9:44 [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap Upal Chakraborty
2015-08-17  9:54 ` Levin Keller
2015-08-17  9:59 ` Patrick Strateman
2015-08-17 10:51   ` Btc Drak [this message]
2015-08-17 11:57 Rodney Morris
2015-08-17 12:38 ` Angel Leon
2015-08-17 12:43 ` Tier Nolan
2015-08-18 12:13 Upal Chakraborty
2015-08-18 17:26 ` Chris Wardell
2015-08-20  7:31   ` Jorge Timón
2015-08-20 10:23     ` Milly Bitcoin
2015-08-21  0:25       ` Tom Harding
2015-08-21  0:37         ` Peter Todd
2015-08-21 16:52           ` Tom Harding
2015-08-21 22:21             ` Peter Todd
2015-08-21 23:16               ` Tom Harding
2015-08-22  0:01                 ` Peter Todd
2015-08-22  3:21                   ` Jorge Timón
2015-08-22  6:26                     ` Peter Todd
2015-08-23 23:41                   ` Tom Harding
2015-08-24  2:27                     ` Jorge Timón
2015-08-21  0:45         ` Milly Bitcoin
2015-08-21  0:58           ` Peter Todd
2015-08-21  1:30             ` Milly Bitcoin
2015-08-21 20:28       ` Jorge Timón
2015-08-21 12:13     ` Sriram Karra
2015-08-21 20:09       ` Jorge Timón
2015-08-18 19:44 ` cedric perronnet
2015-08-18 20:58 ` Danny Thorpe
2015-08-18 21:17   ` Chris Wardell
2015-08-19 17:21   ` Upal Chakraborty
2015-08-20 15:02 Upal Chakraborty
2015-08-21 21:45 Upal Chakraborty

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='CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=vVyw@mail.gmail.com' \
    --to=btcdrak@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=patrick.strateman@gmail.com \
    /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