public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
@ 2015-08-17  9:44 Upal Chakraborty
  2015-08-17  9:54 ` Levin Keller
  2015-08-17  9:59 ` Patrick Strateman
  0 siblings, 2 replies; 33+ messages in thread
From: Upal Chakraborty @ 2015-08-17  9:44 UTC (permalink / raw)
  To: bitcoin-dev

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

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

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

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
@ 2015-08-17 11:57 Rodney Morris
  2015-08-17 12:38 ` Angel Leon
  2015-08-17 12:43 ` Tier Nolan
  0 siblings, 2 replies; 33+ messages in thread
From: Rodney Morris @ 2015-08-17 11:57 UTC (permalink / raw)
  To: bitcoin-dev

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

Words cannot capture how much I wish Satoshi had put logic like this (or
even just a simple block size doubling every reward halving) in place when
he put in the "temporary" 1MB anti-spam block size limit...

I see problems to this approach.  The biggest one I see is that a miner
with 11% of hash power could sabotage block size increases by only ever
mining empty blocks.

I haven't run any statistics or simulations, but I'm concerned that the
interplay between the random distribution of transaction arrival and the
random distribution of block times may lead to false signals.

A 90% full block 1 minute after the previous block is a more "serious"
problem than a 90% full block 30 minutes after the previous block.  A 90%
full block after a 90% full block is a more "serious" problem than a 90%
full block after an empty block.

I would expect a robust approach in this manner to look at block sizes
weighted by block times, but this is an interesting proposal regardless.

But I think you'll run up against one of the great schisms in this debate -
those that believe blocks should always be full (or close to it), to
encourage a "fee market" and to encourage off-chain transactions, and those
that think that the blockchain should be useable by almost anyone for
almost anything, implying there should always be spare space in blocks,
with off-chain transactions reserved for microtransactions and zero-conf
(and possibly low-fee transactions).  At least, that's my take on it.

Rodney



>
>
> Date: Mon, 17 Aug 2015 11:51:26 +0100
> 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
> Message-ID:
>         <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=
> vVyw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
>
>

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

^ permalink raw reply	[flat|nested] 33+ messages in thread
* [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
@ 2015-08-18 12:13 Upal Chakraborty
  2015-08-18 17:26 ` Chris Wardell
                   ` (2 more replies)
  0 siblings, 3 replies; 33+ messages in thread
From: Upal Chakraborty @ 2015-08-18 12:13 UTC (permalink / raw)
  To: bitcoin-dev

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

Regarding:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html


I am arguing with the following statement here...

*I see problems to this approach. The biggest one I see is that a miner
> with 11% of hash power could sabotage block size increases by only ever
> mining empty blocks.*



First, I would like to argue from economics' point of view. If someone
wants to hold back the block size increase with 11% hash power by mining
empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
hash power will most likely be a pool and pool miners will find out soon
that they are losing Tx fees because of pool owner's intention. Hence,
they'll switch pool and pool owner will lose out. This is the same reason
why 51% attack will never happen, even if a pool gets more than 51% hash
power.


Next, I would like to propose a slightly modified technical solution to
this problem in algorithmic format...

If more than 50% of block's size, found in the first 2000 of the last
difficulty period, is more than 90% MaxBlockSize
         Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the last
difficulty period, is less than 50% MaxBlockSize
         Half MaxBlockSize
Else
         Keep the same MaxBlockSize

This is how, those who want to stop increase, need to have more than 50%
hash power. Those who want to stop decrease, need to have more than 10%
hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
this approach, not only miners, but also the end user have their say.
Because, end users will fill up the mempool, from where miners will take Tx
to fill up the blocks. Please note that, taking first 2000 of the last 2016
blocks is important to avoid data discrepancy among different nodes due to
orphan blocks. It is assumed that a chain can not be orphaned after having
16 confirmation.

Looking for comments.

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

^ permalink raw reply	[flat|nested] 33+ messages in thread
* [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
@ 2015-08-20 15:02 Upal Chakraborty
  0 siblings, 0 replies; 33+ messages in thread
From: Upal Chakraborty @ 2015-08-20 15:02 UTC (permalink / raw)
  To: bitcoin-dev

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

Regarding...
i.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010493.html
ii.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010499.html

Could we please keep the conversation specific to the proposal presented at
http://upalc.com/maxblocksize.php ? If you find any demerits to this,
please point them out. Otherwise, I'll ask for a BIP. The proposal in
algorithmic format is as follows...

If more than 50% of block's size, found in the first 2000 of the last
difficulty period, is more than 90% MaxBlockSize
         Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the
last difficulty period, is less than 50% MaxBlockSize
         Half MaxBlockSize
Else
         Keep the same MaxBlockSize

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

^ permalink raw reply	[flat|nested] 33+ messages in thread
* [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
@ 2015-08-21 21:45 Upal Chakraborty
  0 siblings, 0 replies; 33+ messages in thread
From: Upal Chakraborty @ 2015-08-21 21:45 UTC (permalink / raw)
  To: bitcoin-dev

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

I have tried to solve the maximum block size debate in two different
proposal.

i. Depending only on previous block size calculation.

ii. Depending on previous block size calculation and previous Tx fee
collected by miners.


Proposal 1: Depending only on previous block size calculation

If more than 50% of block's size, found in the first 2000 of the last
difficulty period, is more than 90% MaxBlockSize
    Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the last
difficulty period, is less than 50% MaxBlockSize
    Half MaxBlockSize
Else
    Keep the same MaxBlockSize
Proposal 2: Depending on previous block size calculation and previous Tx
fee collected by miners

TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks
in last 2 difficulty period
TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in
last 2 difficulty period (This actually includes 8 blocks from last but one
difficulty)

If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 >
50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty >
TotalTxFeeInLastButOneDifficulty) )
    MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize /
TotalTxFeeInLastButOneDifficulty
Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016
< 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty <
TotalTxFeeInLastButOneDifficulty) )
    MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize /
TotalTxFeeInLastButOneDifficulty
Else
    Keep the same MaxBlockSize
Details: http://upalc.com/maxblocksize.php

Requesting for comment.

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2015-08-24  2:27 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox