eduffield
Core Developer
Hello Everyone!
As many of you know January 18th is the birthday of Dash and makes the project two years old. During that time we’ve accomplished an amazing amount as a team and as a community. I would like to congratulate everyone involved and it’s been a very exciting year and we’re super excited to see what we all can accomplish in the coming months and years.
Happy Birthday Dash!
Trademark Resolution
We are also happy to announce the legal procedures have concluded and we and our service providers can safely use the brand Dash in everything that relates to virtual currencies. With this Dash becomes one of the few cryptocurrency projects with well-defined trademark rights.
This was the first big win for the Foundation, and we would like to thank them for their hard work over the past year on all of these legal matters.. Their work has been been invaluable to our currency and will undoubtedly continue to serve us well. Also, we need to thank the Foundation members for their financial support. Without their fees we would not have been able to afford the necessary legal work, since it began long before we had the blockchain governance system in place. As a side note, the resolution of the trademark issue means we can officially rename the foundation from the Darkcoin Foundation to the Dash Foundation.
Block Size Limitation Increase
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.
If you support this proposal, please vote yes for the following:
mnbudget vote 74e9003906b2ddba7b0115e9bc728367255122cf8da64b5bafec22b9d35683af yes
Thank you for your continued support,
Evan Duffield
As many of you know January 18th is the birthday of Dash and makes the project two years old. During that time we’ve accomplished an amazing amount as a team and as a community. I would like to congratulate everyone involved and it’s been a very exciting year and we’re super excited to see what we all can accomplish in the coming months and years.
Happy Birthday Dash!
Trademark Resolution
We are also happy to announce the legal procedures have concluded and we and our service providers can safely use the brand Dash in everything that relates to virtual currencies. With this Dash becomes one of the few cryptocurrency projects with well-defined trademark rights.
This was the first big win for the Foundation, and we would like to thank them for their hard work over the past year on all of these legal matters.. Their work has been been invaluable to our currency and will undoubtedly continue to serve us well. Also, we need to thank the Foundation members for their financial support. Without their fees we would not have been able to afford the necessary legal work, since it began long before we had the blockchain governance system in place. As a side note, the resolution of the trademark issue means we can officially rename the foundation from the Darkcoin Foundation to the Dash Foundation.
Block Size Limitation Increase
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.
If you support this proposal, please vote yes for the following:
mnbudget vote 74e9003906b2ddba7b0115e9bc728367255122cf8da64b5bafec22b9d35683af yes
Thank you for your continued support,
Evan Duffield