[ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency

[eduffield]

Dash Birthday / Trademark Resolution / Blocksize Limitation

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/

[aigeezer]

Dash Birthday / Trademark Resolution / Blocksize Limitation

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/

"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." Nice to see!

[Minotaur26]

Dash Birthday / Trademark Resolution / Blocksize Limitation

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/

Awesome work, congratz to the foundation on securing proper trademark rights. That is a great boost of confidence for the investors.

Also, lets raise that blocksize limit!  Go Dash always leading and pushing the limits! Literally this time. I vote Yes!


And most importantly Happy Birthday Dash!  What an amazing first 2 years!

[Otoh]

I'm voting Yes on this one too.

[volyova]

Another thing that I want to know is: Why is Eduardo Castro not yet in jail? Surely he must be facing some kind of lawsuit??

[Walter_S]

I'm voting Yes on this one too.

Just voted yes. No brainer.. as they say!  

Walter

[toknormal]

Dash Birthday / Trademark Resolution / Blocksize Limitation

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/

That is quite awesome getting the trademark stuff secured.

[Melech]

Dash Birthday / Trademark Resolution / Blocksize Limitation

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/

Awesome work, congratz to the foundation on securing proper trademark rights. That is a great boost of confidence for the investors.

Also, lets raise that blocksize limit!  Go Dash always leading and pushing the limits! Literally this time. I vote Yes!


And most importantly Happy Birthday Dash!  What an amazing first 2 years!

How about raising the block size dynamically?

Perhaps check the last 1000 blocks, and if the majority are 50%+ filled, double the size allowed? (or something along these lines)

[tungfa]

[Days]

Please ignore the haters, ArielBit lost 11,000 Monero's on Monerodice and he's here hating only.
While Icebreaker is a well known Hashfast scammer, please google Hashfast scam.

The level of hate and jealousy these people bring just WoW man...

No he didn't.

My bad I just saw Ariel's name on monero dice website as the 2nd most lost bet there. Maybe it's a totally different person and Ariel just happen to be a supporter who likes to spam dash?

[oblox]

Dash Birthday / Trademark Resolution / Blocksize Limitation

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/

Awesome work, congratz to the foundation on securing proper trademark rights. That is a great boost of confidence for the investors.

Also, lets raise that blocksize limit!  Go Dash always leading and pushing the limits! Literally this time. I vote Yes!


And most importantly Happy Birthday Dash!  What an amazing first 2 years!

How about raising the block size dynamically?

Perhaps check the last 1000 blocks, and if the majority are 50%+ filled, double the size allowed? (or something along these lines)

Yes, enough with hard-and-fast caps, dynamic blocks based on N-number of blocks to grow as needed determined by actual transactional needs.

[qwizzie]

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/

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:

** see official Dashtalksite for detailed vote instruction **  

Thank you for your continued support,

Evan Duffield

* i removed the specific vote instruction to avoid having it tempered with through reposts


Discussion about this block size limitation increase is best to be done on these two sites :

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/
https://www.dashwhale.org/p/2mb-blocksize#comments

(its more structured there and also its more easy to find comments back)

[spatula]

I voted YES on the blocksize increase. Geez that was too easy, perhaps we should take bitcoins lead and just fight and have some name calling and rage quitting for the next couple of years...

[110110101]

Congratulations Dash, impressive 2 years!

Also, I really like that we can vote on the blocksize unlike BTC where the question has been one hostile and infected issue indeed.

[AlexGR]

From what I understand, the quadratic explosion that occurs from 1mb to 2mb cannot be solved with fees. It will either need to limit the max transactions or the size of a transaction - to say 1mb.

Aside from that, do we have any maths on how x11 and 2mb blocks propagate and how that can affect mining and network operation?

I don't feel that people voting yes or no in such technical issues is appropriate.

I mean, yes, we all want bigger blocks, heck, why not 100mb? I mean duuuh? But there are tradeoffs involved and we have to see what they are.

If possible, I'd like to know these things:

1) With the proposed fee structure, how much would it cost me -as an attacker- to add 1gb of bloat to our blockchain? I want to know if its doable for one of our competitor coins to "sponsor" an attack and make our wallet unusable because noone will want to download a 500gb wallet and say "fuck dash, it's taking ages". This is not a theoretical attack, Monero had been on the receiving end of a bloat attack in the past - presumably by Bytecoin (?).

2) What's the propagation and verification speed data regarding 2mb blocks combined with 2.5m intervals - which, sometimes can get down to a few seconds and will it create problems in case of 2mb blocks? Is there any testnet simulation run or something with full blocks, or specially crafted attack blocks to see what will happen at full load?

3) Is there any reason in particular why we would like this change to occur now, instead of the future when we need >28tx/s? The only thing I can think of is ...marketing, in the sense of "hey bitcoin, look over here, we are doing it democratically" - and hitting the news with it, but, again, I'm not comfortable about the decision process when people don't have all the tradeoff data. Actually I don't feel good at all when it's left to anyone's decision process with a simple yes and no


Happy birthday people, the future is bright

[bigrcanada]

Dash Birthday / Trademark Resolution / Blocksize Limitation

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/

Evan... This is amazing! I am certainly voting "YES"  on this.  Happy birthday indeed.

[Taylor05]

Dash Birthday / Trademark Resolution / Blocksize Limitation

https://dashtalk.org/threads/dash-birthday-trademark-resolution-blocksize-limitation.7696/

Awesome work, congratz to the foundation on securing proper trademark rights. That is a great boost of confidence for the investors.

Also, lets raise that blocksize limit!  Go Dash always leading and pushing the limits! Literally this time. I vote Yes!


And most importantly Happy Birthday Dash!  What an amazing first 2 years!

How about raising the block size dynamically?

Perhaps check the last 1000 blocks, and if the majority are 50%+ filled, double the size allowed? (or something along these lines)

I disagree. That system could be manipulated easily to automate changes. I think this needs to remain a human-made decision.

[Minotaur26]

From what I understand, the quadratic explosion that occurs from 1mb to 2mb cannot be solved with fees. It will either need to limit the max transactions or the size of a transaction - to say 1mb.

Aside from that, do we have any maths on how x11 and 2mb blocks propagate and how that can affect mining and network operation?

I don't feel that people voting yes or no in such technical issues is appropriate.

I mean, yes, we all want bigger blocks, heck, why not 100mb? I mean duuuh? But there are tradeoffs involved and we have to see what they are.

If possible, I'd like to know these things:

1) With the proposed fee structure, how much would it cost me -as an attacker- to add 1gb of bloat to our blockchain? I want to know if its doable for one of our competitor coins to "sponsor" an attack and make our wallet unusable because noone will want to download a 500gb wallet and say "fuck dash, it's taking ages". This is not a theoretical attack, Monero had been on the receiving end of a bloat attack in the past - presumably by Bytecoin (?).

2) What's the propagation and verification speed data regarding 2mb blocks combined with 2.5m intervals - which, sometimes can get down to a few seconds and will it create problems in case of 2mb blocks? Is there any testnet simulation run or something with full blocks, or specially crafted attack blocks to see what will happen at full load?

3) Is there any reason in particular why we would like this change to occur now, instead of the future when we need >28tx/s? The only thing I can think of is ...marketing, in the sense of "hey bitcoin, look over here, we are doing it democratically" - and hitting the news with it, but, again, I'm not comfortable about the decision process when people don't have all the tradeoff data. Actually I don't feel good at all when it's left to anyone's decision process with a simple yes and no


Happy birthday people, the future is bright

Asking authorization of the network, represented by its stakeholders, to define its intention to raise the block size limit is just the first step, but a very important one so the community can move in this direction in a united front.

As the proposal already says:

"If approved, a proper development, testing and deployment process would start before it reaches production."

So all of these are relevant questions and we can try different things on test-net, if and when we all agree this is something we want to do.  I think the whole process starts in a much more positive way.

[AlexGR]

"If approved, a proper development, testing and deployment process would start before it reaches production."

So all of these are relevant questions and we can try different things on test-net, if and when we all agree this is something we want to do.  I think the whole process starts in a much more positive way.

Aha ok, that's better. I quickly read through it so I thought it had a more immediate effect. In any case, having the data before voting would actually be the best, otherwise the yes is a no-brainer. Everyone wants more tx capacity. The only issue is what problems start appearing due to the tradeoffs involved, usually near max-load circumstances or attack-vector deployments.

[eduffield]

From what I understand, the quadratic explosion that occurs from 1mb to 2mb cannot be solved with fees. It will either need to limit the max transactions or the size of a transaction - to say 1mb.

Aside from that, do we have any maths on how x11 and 2mb blocks propagate and how that can affect mining and network operation?

I don't feel that people voting yes or no in such technical issues is appropriate.

I mean, yes, we all want bigger blocks, heck, why not 100mb? I mean duuuh? But there are tradeoffs involved and we have to see what they are.

If possible, I'd like to know these things:

1) With the proposed fee structure, how much would it cost me -as an attacker- to add 1gb of bloat to our blockchain? I want to know if its doable for one of our competitor coins to "sponsor" an attack and make our wallet unusable because noone will want to download a 500gb wallet and say "fuck dash, it's taking ages". This is not a theoretical attack, Monero had been on the receiving end of a bloat attack in the past - presumably by Bytecoin (?).

2) What's the propagation and verification speed data regarding 2mb blocks combined with 2.5m intervals - which, sometimes can get down to a few seconds and will it create problems in case of 2mb blocks? Is there any testnet simulation run or something with full blocks, or specially crafted attack blocks to see what will happen at full load?

3) Is there any reason in particular why we would like this change to occur now, instead of the future when we need >28tx/s? The only thing I can think of is ...marketing, in the sense of "hey bitcoin, look over here, we are doing it democratically" - and hitting the news with it, but, again, I'm not comfortable about the decision process when people don't have all the tradeoff data. Actually I don't feel good at all when it's left to anyone's decision process with a simple yes and no


Happy birthday people, the future is bright

I believe the masternode network can solve all issues with scalability from the blocksize perspective.

1.) We didn't propose an exact fee structure yet, that will determined when the coding begins. It will be enough to stop a sybil/bloat attack and also enough to allow users a very low cost to transact on our network.

2.) The problems with propagation do not pass from the Bitcoin network to the Dash network, due to the high quality second tier infrastructure. We can require specific infrastructure from our masternodes, which will allow for very quick block propagation no matter the size. The miners simply will need to be connected to the masternode network from each of it's edges (which we will describe how to do this eventually, it's not very difficult). Imagine propagating a 20MB block through a network of 3500 computers with 10GB/s networking. It's not hard to see the advantage we have.  

As for the question, how will we require the masternodes have specific hardware? The next proof-of-service implementation is going to be as simple as a few of us testing the network's masternodes using open source tools to determine the quality of service. We will then provide evidence that can be double checked by other masternodes, then we will use a voting mechanism to flag their masternodes. They will see the flags and know what they have to do in order to remove them, until they do they won't get paid. Once they fix the issues, they can propagate a message asking for a re-evaluation.

Also, that's to say our market cap would be orders of magnitude higher as well. To even have 20MB blocks on average we would have hundreds of millions of users. At which point the masternodes will make plenty of money to be required to run on Xeons and have 10GB/s networking.

3.) We need to start preparing for mass user adoption now and make sure we can support this type of load. By doing this now, we'll have years to prepare and won't have to have huge debates about making changes to an already working system. If Bitcoin did this when they were 25% full, they wouldn't be having this issue, right?

Why wait?