Proposal “2mb-blocksize“ (Completed)Back
| Title: | Block Size Limitation Increase |
| Owner: | eduffield |
| One-time payment: | 5 DASH (142 USD) |
| Completed payments: | 1 totaling in 5 DASH (0 month remaining) |
| Payment start/end: | 2016-02-06 / 2016-03-22 (added on 2016-01-18) |
| Final voting deadline: | in passed |
| Votes: | 2129 Yes / 18 No / 0 Abstain |
| External information: | www.dashwhale.org/p/2mb-blocksize |
Proposal description
We would also like to propose we raise the Dash block size limitation to 2MB to prepare for the future growth of the network. We want to know if the stakeholders support this idea. For this, we would like the nodes to vote using our decentralized governance system to make sure we have the community behind us.
With the current 1MB block size limit we have approximately 4x the capacity of the Bitcoin project in transactions per second capability, due to the 2.5 minute block spacing and a current 1MB blocksize. With our current limitations our network could theoretically allow nearly 28 transactions per second. We propose a change to a 2MB block size limitation, allowing up to 56 transactions per second. This will allow the currency to grow to approximately 8x the current transactional capacity of the Bitcoin project. It is important to plan for the long term success of the network and future adoption, by making this change we will be ready to scale and also give ourselves ample time to continue research and development to look for additional ways to improve efficiencies of the network.
The reason why raising the block size limit is not a centralization concern on our network is because of the full node incentive model. As the volume and usage rise on our network, the profits of the masternode network will also increase, creating excess funding to process the extra bandwidth without losing decentralization. This is in sharp contrast to projects without a full node incentive program, due to the inverse relationship between the full-node count and bandwidth requirements.
To implement 2mb blocks and prepare for Evolution, we must take care of some security concerns as well. There is a concern even with 1MB blocks that an attacker could add a transaction that takes 30 seconds to process, with 2MB blocks it’s actually possible to add a 10 minute script to process (https://www.reddit.com/r/Bitcoin/comments/3yulwv/any_examples_of_the_10_minute_script_thats_a/). To close these attack vectors there will be no more “ completely free” transactions in blocks, instead we will use a flat fee per kb when adding transactions to the blockchain that should be negligible for normal usage. This can be done via the spork code, which can set system-wide variables in the code. Once set, all blocks will be subject to this limitation, otherwise will be rejected by the network.
As far as determining if this proposal passes, we will consider more yes votes than no votes approval by the network as long as more than 33% of the network votes. If less than 33% of the network votes, we will consider the proposal denied and will not raise the blocksize limitation.
If approved, a proper development, testing and deployment process would start before it reaches production. Let’s give Dash room to grow.
With the current 1MB block size limit we have approximately 4x the capacity of the Bitcoin project in transactions per second capability, due to the 2.5 minute block spacing and a current 1MB blocksize. With our current limitations our network could theoretically allow nearly 28 transactions per second. We propose a change to a 2MB block size limitation, allowing up to 56 transactions per second. This will allow the currency to grow to approximately 8x the current transactional capacity of the Bitcoin project. It is important to plan for the long term success of the network and future adoption, by making this change we will be ready to scale and also give ourselves ample time to continue research and development to look for additional ways to improve efficiencies of the network.
The reason why raising the block size limit is not a centralization concern on our network is because of the full node incentive model. As the volume and usage rise on our network, the profits of the masternode network will also increase, creating excess funding to process the extra bandwidth without losing decentralization. This is in sharp contrast to projects without a full node incentive program, due to the inverse relationship between the full-node count and bandwidth requirements.
To implement 2mb blocks and prepare for Evolution, we must take care of some security concerns as well. There is a concern even with 1MB blocks that an attacker could add a transaction that takes 30 seconds to process, with 2MB blocks it’s actually possible to add a 10 minute script to process (https://www.reddit.com/r/Bitcoin/comments/3yulwv/any_examples_of_the_10_minute_script_thats_a/). To close these attack vectors there will be no more “ completely free” transactions in blocks, instead we will use a flat fee per kb when adding transactions to the blockchain that should be negligible for normal usage. This can be done via the spork code, which can set system-wide variables in the code. Once set, all blocks will be subject to this limitation, otherwise will be rejected by the network.
As far as determining if this proposal passes, we will consider more yes votes than no votes approval by the network as long as more than 33% of the network votes. If less than 33% of the network votes, we will consider the proposal denied and will not raise the blocksize limitation.
If approved, a proper development, testing and deployment process would start before it reaches production. Let’s give Dash room to grow.
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
|
No comments so far?
Be the first to start the discussion! |
How about check the last 1000 blocks, and if they are all 50%+ filled, double the block size allowed?
Perhaps the community could come up with something better, that is just my first idea
* proceed with this 2MB increase
* monitor and analyse its effects
* afterwards discuss if and how we can setup a possible dynamic solution where a distinction will have to be made between superblocks that are pretty much always filled and normal blocks
So our normal yes votes - no votes > 10% has now been raised to yes votes - no votes > 33% ? correct ? or am i interpreting it wrongly ?
The dev team will like to raise the block size limit to provide room for future growth. And it is better to do it now, than wait until it becomes a problem.
To do this, the dev team is asking the community for its approval. Since this is not a funding proposal, we would like for participation to be at least 33% of the network in this particular case. Once we reach that level of participation if the Yes votes are winning it would be official and Dash will prepare to raise its blocksize limit to 2MB.