Btc Drak [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-17 📝 Original message:On Mon, Aug 17, 2015 at ...

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/9a6dca23/attachment.html>;