Proposal “2mb-blocksize“ (Completed)Back

Title:Block Size Limitation Increase
One-time payment: 5 DASH (145 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:

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 ( 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
5 points,8 years ago
Now this is how you try and get a consensus...Bitcoin could learn a thing or two in Miami.
0 points,8 years ago
I would like to see the community come up with a dynamic solution for this instead of hard-coding block size updates every year...

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
3 points,8 years ago
we could also do the following :

* 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
1 point,8 years ago
Given that Dash has an average of maybe 7 transactions per block, I don't think we need to be in a rush to increase the size, which could make it vulnerable to known and unknown attack vectors
0 points,8 years ago
at least someone makes sense here
0 points,8 years ago
"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."

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 ?
0 points,8 years ago
Hi qwizzie, normal yes vs no rules apply. But this is not a funding proposal, it pays out only a symbolic 5 DASH which is the cost of submitting the proposal. This is DASH using its governance system to determine direction.

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.
0 points,8 years ago
okay, got it now. thanks for the clarification.
0 points,8 years ago
looks like we have a month the time before the voting ends
0 points,8 years ago
This is a proposal submitted by Evan Duffield. Here is link: