• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Dash Core v20.0.0 Release Announcement

Pasta

Active member
Dash Core Group
Dash Core v20.0 is Officially Released!

Please see the release announcement for information about the release here: https://www.dash.org/blog/dashcore-v20-0-product-brief/

Reminder that all v20 hard fork activated features are not enabled until the hard fork activates. This will occur no sooner than November 30th.

Masternode Operators should ensure they remove sentinel when they upgrade to 20.0.0 as it is no longer used or needed.

Please see the GitHub release with binaries here: https://github.com/dashpay/dash/releases/tag/v20.0.0
Feel free to ask questions here and report all issues to https://github.com/dashpay/dash/issues.
 
Following the approval of the EXPEDITE-60-20-20-REALLOCATION proposal, some features that support the release of Platform will not be activated as part of v20.0. Instead, Platform activation will align with the v21.0 release.

This v20 update feels a bit like 1 stap forward and 2 steps backward to me, as important Platform features that were suppose to activate through v20 are now delayed and put into v21. While the main feature of v21 : Trustless Masternode Shares has been postponed (feels like postponed indefinetely) to a later major release.

Two reasons are provided on Github for this : https://github.com/dashpay/dash/pull/5642

- Having a hard fork and a spork is supposedly confusing for Dash users, so the idea emerged to just spread this out over two hard forks through two major releases (v20 & v21). This is strange to read for me as DCG did plenty of hard fork & spork activation in the past through one single major release. Dash users & MNO's are used to hard fork activation (modified bip9 hard fork requiring miner support) in combination with spork activation (needing masternodes support).

- Testing of certain Platform features in v20 (Asset Unlock transactions for example) were not started, eventhough devs reserved full two months for testing v20 on Testnet. Why devs could not start the testing of the Asset Unlock transactions on Testnet i do not know, i suspect having a v20 update so full of features (many not essential to a Platform release on Mainnet) may have caused devs to run simply out of time here.

By the way, the above was just discussed between devs on Github, it was never discussed in the Expedite-60-20-20-Reallocation thread with MNO's on Dash Central.

What this means for MNO & Evonode owners :

This will delay Evonodes from getting access to both L1 and L2 and delay Evonodes from receiving both a portion of the block rewards (L1) & Credits (L2). The distribution of a portion of the masternode blockrewards towards Credits in a Creditpool is also getting delayed to v21.
This most likely means less incentivize for masternode owners to convert their Masternodes to Evonodes right now. They may as well wait for v21 (or later versions .. who knows), before setting up an Evonode. Number of Evonodes on Mainnet are still very low (85), i do not expect this to change now v20 has been split in two parts (v20 and v21).

Dash users / Masternode owners / Evonode owners will first have to wait for the hard fork process to finalize with v20, and then wait for another hard fork process to finalize with v21, before having any chance of seeing Platform released on Mainnet. Both updates will need miner support due to the hard forks. I reckon this could take 6 months (2 months to finalize the hard fork in v20 and 4 months to release & finalize the hard fork in v21). Could even be longer.

At least this v20 update is out on Mainnet now, but i can't say i am that thrilled about witnessing yet another delay with regards to a Platform release to Mainnet (which will now need a Dash Core v21 first). Also i do not understand why devs are so much deviating from using hard fork + spork to now using several hard forks, spread over multiple major releases. This is bound to delay the Platform release and other major releases in the future and when something goes wrong, there is no reset to a previous safe state possible (which sporks do offer). I hope devs will keep the features in v21 to a bare minimum, so that v21 can be released soon. But to be honest, i have little faith that they will.
 
Last edited:
Soo; this is a good discussion to have.

v20 DOES include mn_rr and those features still (the "second hard fork"), however, due to the relatively high potential of platform requiring changes to these features, we do not want to activate these features until platform is ready to be released and current implementation is guaranteed to be correct. As such, v20 includes support for all mn_rr features (credit pool, asset unlocks, reward reallocation to platform) but v20.0 masternodes will never vote to activate mn_rr. Instead when the time is come for platform mainnet release we will need to release a v20.1 which will allow masternodes to vote for and activate mn_rr. However, nodes running v20.0 will not need to upgrade and will successfully follow this chain.

If however, in our final testing of platform, we find that there are changes needed to core features in a breaking way, then the mn_rr hard fork will be scrapped and a new hard fork tied to a release of v21 would be needed.

I hope this makes sense. A mandatory v21 release is not needed for platform to be released, instead only an optional v20.1 (would require basically all masternodes to upgrade).

Please ask follow up questions if you have them.

Edit: I see now product brief specifically says that platform will be aligned with v21; this is not strictly needed but depends on if platform needs breaking changes in core.
 
Dash Core v20.0 is Officially Released!

Please see the release announcement for information about the release here: https://www.dash.org/blog/dashcore-v20-0-product-brief/

Reminder that all v20 hard fork activated features are not enabled until the hard fork activates. This will occur no sooner than November 30th.

Masternode Operators should ensure they remove sentinel when they upgrade to 20.0.0 as it is no longer used or needed.

Please see the GitHub release with binaries here: https://github.com/dashpay/dash/releases/tag/v20.0.0
Feel free to ask questions here and report all issues to https://github.com/dashpay/dash/issues.
Dash.org still has Dashcore v 19.3.0 listed for download.
 
*** To all MNO's & Evonode owners using Dashmate ***

Do not update Dashmate to v0.25.15 !!!

Looks like Dashmate v0.25.15 is causing errors with dashmate status and dashmate stop commands, which i only found out today, after updating my Dashmate from v0.25.13 to v0.25.15. I also suspect Masternodes / Evonodes on Dashmate v0.25.15 have a high risk of getting PoSe scored !!

See :

https://github.com/dashpay/platform/issues/1583
https://www.dash.org/forum/index.php?threads/dashmate-discussion.53951/page-3#post-236933

Error with Dashmate v0.25.15 :

CompileError: WebAssembly.Module(): Compiling function #331:"memchr::arch::wasm32::simd128:: packedpair::Find..." failed: Wasm SIMD unsupported @+1956688

I managed to revert both of my Evonodes back to Dashmate v0.25.13, after both of them already got hit with PoSe scores (2200+).
They are now both running Core v20 through Dashmate v0.25.13 (+ 'dashmate config set core.docker.image dashpay/dashd:20.0.0')
and hopefully avoid a PoSe ban.

To devs : Please pay more attention to Dashmate and test Dashmate better, so this can be avoided in the future. I hate getting hit with PoSe scores because of a faulty Dashmate version (v0.25.15), that is supposedly the most recent and stable version.
 
Last edited:
Evonodes that got PoSe banned these last few days : filtered on PoSe ban time

Knipsel.JPG

Source : Dash Masternode Tool

Evonodes that got poSe penalty scored (i assume recently) : filtered on PoSe penalty

Knipsel1.JPG

Source : Dash Masternode Tool

This should not occur on such low number of Evonodes (88) and it does seem related to the release of Dash Core v20 / use of Dashmate.
 
Last edited:
That sucks that an evonode PoSe stops all your payments, whereas, if you had 4 separate nodes you would have more financial resilience.
 
Yep. PoSe bans have currently a much bigger financial impact (and do i dare say more stress) on Evonode owners, then on Masternode owners with 4 seperate masternodes. At least untill either v20.1 activation or v21 activation. After which Evonode payment logic changes and Evonodes are less depending on MN payments from L1, as they will receive a portion of their MN rewards in Credits from L2 (which has no PoSe scoring).
 
Last edited:
*** To all MNO's & Evonode owners using Dashmate ***

Do not update Dashmate to v0.25.15 !!!

Looks like Dashmate v0.25.15 is causing errors with dashmate status and dashmate stop commands, which i only found out today, after updating my Dashmate from v0.25.13 to v0.25.15. I also suspect Masternodes / Evonodes on Dashmate v0.25.15 have a high risk of getting PoSe scored !!

See :

https://github.com/dashpay/platform/issues/1583
https://www.dash.org/forum/index.php?threads/dashmate-discussion.53951/page-3#post-236933

Error with Dashmate v0.25.15 :



I managed to revert both of my Evonodes back to Dashmate v0.25.13, after both of them already got hit with PoSe scores (2200+).
They are now both running Core v20 through Dashmate v0.25.13 (+ 'dashmate config set core.docker.image dashpay/dashd:20.0.0')
and hopefully avoid a PoSe ban.

To devs : Please pay more attention to Dashmate and test Dashmate better, so this can be avoided in the future. I hate getting hit with PoSe scores because of a faulty Dashmate version (v0.25.15), that is supposedly the most recent and stable version.
It's not quite correct, the release is Dashmate v0.25.15 is working. You forgot to mention that you have also updated your Node.js from 18 to 21, which broke the dashmate, not the dashmate release itself. There are no dashmate or network changes between v0.25.13 and v0.25.15, it just adds a new RS-SDK project introduced in the platform.

If you want to update your Node.js version, please wait for a next release that should happen as soon as DCG will merge my changes in.
There is also an option to use .deb package that comes bundled with the Node.js, so you don't have to hassle switching different versions.


PS: Next Node 20 should last for about a year https://endoflife.date/nodejs
 
Actually i updated Node.JS from v16 to v20 previously (See https://www.dash.org/forum/index.php?threads/dashmate-discussion.53951/page-2#post-236680), as you mentioned that Node.JS v18 was the bare minimum for Dashmate v0.25.x
If i knew then that Node.JS should not be be updated beyond v18, i would have looked for ways to limit the update of my Node.JS to v18.

Sorry, I forgot to mention that Node v16 has reached end of life maintenance support, and we dropped its support in the v25. Although it could possibly work on Node 16, dashmate may behave differently and unstable, because there are breaking changes in the interface of library, that issuing http requests (fetch). Platform code now expects at least Node.js v18 sdk api.

Many npm modules now fails to work and install until you make an upgrade, and the npm is too.
Platform code now expects at least Node.js v18 sdk api.

Basically i was under the impression that Node.JS v18 or higher was needed for for Dashmate v0.25.x, not that a limitation was in place to Node.JS v18 only.
 
Last edited:
Actually i updated Node.JS from v16 to v20 previously (See https://www.dash.org/forum/index.php?threads/dashmate-discussion.53951/page-2#post-236680), as you mentioned that Node.JS v18 was the bare minimum for Dashmate v0.25.x
Interesting, didn't know that. Platform project was not building with Node 20 but dashmate probably could work.
Basically i was under the impression that Node.JS v18 or higher was needed for for Dashmate v0.25.x, not that a limitation was in place to Node.JS v18 only.
Yeah... that makes sense. I forgot that newer Node.JS usually breaks applications. Maybe better to stick with only one exact major Node version supported, because this happens not first and not last time


Anyway, sorry for all inconvenience happened
 
And as usual, the tester who discovered the bug and reported it, got nothing.
Neither the developer who caused that bug was punished.

Right?

Non accountable developers are causing Dash to crash and the Dash masternodes are tolerating them.
No wonder why Dash will soon reach the bottom of coinmarketcap.
 
Last edited:
Should someone of DCG not announce the release of v20.0.1 ? i know it is a small optional update, but if nobody push this release onto the official Dash forums, then few Dash users / MNO's will know of its existence (appearently v20.0.1 was released 2 days ago on Mainnet).


Knipsel.JPG


For future updates i hope at some point an official Dash announcement on the Dash forums can be released the same day, as an update gets released to Mainnet.

This has always been a bit of a weakness for DCG (even during bull markets), but there should be ways to improve on this. It just requires better communication & planning between the devs releasing the update on Github and the person in charge of releasing that information to the Dash forums. Weekends should not have to interfere with this, not if people plan ahead for these kind of events.
 
Last edited:
Actually, this has never worked. I remember trying years ago, but it just hung up. I'm afraid it simply is too many addresses for a desktop to handle. Or something. You can't do it in bitcoin core either. I don't think it's a bug, but a limitation on technology.
 
And as usual, the tester who discovered the bug and reported it, got nothing.
Neither the developer who caused that bug was punished.

Right?

Non accountable developers are causing Dash to crash and the Dash masternodes are tolerating them.
No wonder why Dash will soon reach the bottom of coinmarketcap.
it's not a bug, can't do it in bitcoin core either. Too big.
 
it's not a bug, can't do it in bitcoin core either. Too big.
So what? A bug for both bitcoin and Dash, it is still a bug.

And by the way, if you switch to dashd19.3 there is no such bug.

So if it is a bug of bitcoin as you claim (without providing any link that proves your claim) it should be a very recent one.
 
Knipsel.JPG

Source : https://www.dashninja.pl/blocks.html

@Pasta

Where do we focus on again with regards to miners signaling support for Dash Core v20 ? Paid blocks (Correct ratio) 30% or on that 58.2% and latest protocol/block version ?

Update : that 58.2% looks to be related to the masternode portion of the blockrewards

Knipsel.JPG


Maybe someone (Crowning / DCG) can update the following site to show V20 adoption, instead of V19 adoption --> http://178.254.23.111/~pub/Dash/Dash_Info.html as that site is a bit more easy to track miners support and the cycle we are currently in / required miner support percentage per cycle.

Note to readers : Miners first need to signal 80% support, but over time (there will be 10 cycles of 4032 blocks / 10 weeks) this lowers automatically to 60%. I think i read the 1st cycle of 4032 blocks / 1 week start later this month. This is just a bit of pre-signaling i think. Or maybe that 1st cycle already started, not sure.
 
Last edited:
I wish Masternode owners / Evonode owners could optionally set a short time window (10-15 minutes) once a day, where they could be exempt from PoSe scoring to initiate a Dash Core update. So there is less risk of getting hit with a high PoSe score for failing to participate in a DKG session, when they are trying to update their node. A new command that could set a Masternode / Evonode in such a temporary exempt status and reverts it automatically afterwards.

I feel like Masternodes and Evonodes are getting hit with PoSe scores a bit too much, during these update moments when they need to stop their dashd.pid.
 
Last edited:
Back
Top