Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself.

Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself.
2017-03-12 14:44 ` David Vorick
  2017-03-12 18:00 ` Bram Cohen
  
From: ashish khandekar @ 2017-03-12  9:51 UTC (permalink / raw)
  To: bitcoin-dev

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

BLOCKCHAIN CONGESTION – A SOLUTION AND PRE-EMPTIVE MEASURES FOR THE FUTURE



This document is an idea for helping the bitcoin block chain get
uncongested, provide enough space for transactions to get included in
blocks easily, and give the bitcoin network the power to defend itself
against any stress tests or spam attacks in the future.



The current maximum size of a block in the bitcoin protocol is 1mb.This has
created a “fee market” allowing those who can send high transaction fees
only to use bitcoin easily, making those who use even a slight lower fee to
wait for transactions to get confirmed by miners, sometimes it take hours
but sometimes it can scale up to a few days, this creates a difficulty for
merchants who use bitcoin to operate with ease, new people who are adapting
to bitcoin, and those unaware of the developments in the bitcoin community
confused in why transactions aren’t getting confirmed as they used to.



Bitcoin is a highly versatile. From its price being directly influenced by
its demand and supply to the amount of work done to keep the network safe
a.k.a. mining. Over the years both have changed dramatically but one thing
which has stayed constant is the size of the block, which is 1mb. The limit
of 1mb creates only a finite number of transactions to get confirmed even
if used to the brim, leaving out other transactions and creating a backlog
of transaction to be carried forward indefinitely.



Bitcoin’s verification system, mining, has a dynamic difficulty calculation
rate, which means every 2016 blocks or 2 weeks the difficulty changes
making mining little bit easy or a bit difficult, but keeping the same
maximum output of 1mb per block, so this means every 2 weeks on 2016mb
worth of transactions can get verified assuming all blocks are filled to
the brim, any amount of excess transactions would not get verified due to
lack of space and would get carried over to the next cycle, over a period
of time this becomes a massive amount and has led to the current blockchain
congestion.



A unique solution is to let the bitcoin network change the maximum block
size as per the prevailing network conditions, this solution borrows some
aspects of both the demand and supply factor and dynamic change of network
difficulty (amount of work done to verify transactions).



This would be achieved by tracking the volume of the total size of
transactions done between 2 consecutive network difficulty changes and
dividing it by 2016, the number of blocks mined between 2 consecutive
network difficulty changes. The resulting answer would be rounded up to the
nearest kb and then compared to the previous block size, the higher between
the two would be taken as the new maximum block size. The extra space would
be helpful if a malicious attacker tries to create a lot of small dust
transactions and flood the network. Let us take a look at a  example of how
it would affect the bitcoin network in a real life scenario.



Dynamic block size calculation (B) = Total size of transactions from
previous network difficulty change(ST) / 2016

We compare this with the current block size and the higher is accepted as
new block size.



For example purposes the block numbers have been changed for easy
understanding.

If during cycle 1, block number 1 to block number 2016 the total size of
transactions is 1608mb,recalculating it with the dynamic block size
algorithm would give the following result:

Dynamic block size calculation (B) = ST/2016

1608/2016=0.79761905       which is 797kb

We compare this with the current block size which is 1mb (current block
size in real life) and the higher of the two becomes the block size for the
next cycle.

During cycle 2, block number 2017 to block number 4032 the total size of
transactions is 2260mb, recalculating it with the dynamic block size
algorithm would give the following result:

Dynamic block size calculation (B) = ST/2016

2260/2016=1.12103175       which is 1.2mb

We compare this with the current block size which is 1mb and the higher of
the two becomes the block size for the next cycle, in this case 1.2 mb
blocks would be new block size.



The above examples can be repeated indefinitely allowing the network to
adjust the block size automatically. The dynamic block size is to be
calculated at the same time as the network difficulty is changed.

To avoid orphaning of blocks and very small blocks a minimum block size
should also be taken into effect, the minimum size of the block should be
in the range of 30-60% of the maximum block size; this measure would also
stop the propagation of very small blocks which aren’t verifying
transactions and helping the network grow.



THE END

Any questions ?

Mail me at: contashk18@gmail•com

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

 permalink raw reply	[|nested]
2017-03-12  9:51 [bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself ashish khandekar

  2017-03-12 14:52   ` Dionysis Zindros
  2017-03-12 18:00 ` Bram Cohen
  
From: David Vorick @ 2017-03-12 14:44 UTC (permalink / raw)
  To: Bitcoin Dev, ashish khandekar

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

What, in your appraisal, is the purpose of the block size limit? I think we
will be more able to have a productive discussion around this proposal if
we clear that up first.

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

 permalink raw reply	[|nested]
2017-03-12 14:44 ` David Vorick

  
From: Dionysis Zindros @ 2017-03-12 14:52 UTC (permalink / raw)
  To: David Vorick, Bitcoin Protocol Discussion;  ashish khandekar

Are you aware of Washington Sanchez's BIP 107? It is a proposal
similar to yours:

https://github.com/bitcoin/bips/blob/master/bip-0107.mediawiki

On Sun, Mar 12, 2017 at 4:44 PM, David Vorick via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> What, in your appraisal, is the purpose of the block size limit? I think we
> will be more able to have a productive discussion around this proposal if we
> clear that up first.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


 permalink raw reply	[|nested]
2017-03-12  9:51 [bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself ashish khandekar
  2017-03-12 14:44 ` David Vorick

  2017-03-13 13:08   ` ashish khandekar
  
From: Bram Cohen @ 2017-03-12 18:00 UTC (permalink / raw)
  To: ashish khandekar, Bitcoin Protocol Discussion

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

Shouldn't there be a FAQ about this? All the blocksize increase proposals
going back to the Bitcoin Classic have the same problems and having
repeated proposals which move the details around a bit doesn't add anything
to the discussion.

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

 permalink raw reply	[|nested]
2017-03-12 18:00 ` Bram Cohen

  2017-03-14 23:20     ` Erik Aronesty
  
From: ashish khandekar @ 2017-03-13 13:08 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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

Should a BIP be submitted or are there any suggestions for the proposal ?

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

 permalink raw reply	[|nested]
2017-03-13 13:08   ` ashish khandekar

  
From: Erik Aronesty @ 2017-03-14 23:20 UTC (permalink / raw)
  To: ashish khandekar, Bitcoin Protocol Discussion

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

- no quadratic hashing solution
- no way to prevent spamming the network to blow up block sizes
- no mention of release schedule/consensus levels, etc.   should be
mentioned
- this is similar to other BIP already in place... see BIP107


On Mon, Mar 13, 2017 at 9:08 AM, ashish khandekar via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Should a BIP be submitted or are there any suggestions for the proposal ?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

 permalink raw reply	[|nested]