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

Dash Core v18.0.1 Released

During intital Reindex, you need 6GB(+) RAM and/or swap space, after that requirements drop. Most folks are just using 8 GB RAM to
get thru the upgrade process.
VULTR does not permit to downgrade. So if we upgrade from 4GB to 8 GB there is no going back, and the cost remains high.
 
VULTR does not permit to downgrade. So if we upgrade from 4GB to 8 GB there is no going back, and the cost remains high.

4GBs is enough, dashd doesn't require a super computer. $18/mo cloud compute instance on vultr is ample for a masternode.
 
Knipsel (1).JPG


Looks like DIP24 (Quorum Rotation) locked-in, despite below drop in percentage of Dash v18.0 blocks found by miners (currently below trigger of 80%).

1662467592851.png


DIP24 should be fully activated at block 1737792 / 13 Sep 2022.

Please someone correct me, if i am wrong....
 
View attachment 11360

Looks like DIP24 (Quorum Rotation) locked-in, despite below drop in percentage of Dash v18.0 blocks found by miners (currently below trigger of 80%).

View attachment 11358

DIP24 should be fully activated at block 1737792 / 13 Sep 2022.

Please someone correct me, if i am wrong....

The agents lost the masternodes battle (the masternodes that updated to 18.1 are now more than 80%) so they are trying to attack through the miners.
I hope their attack will not succeed.
 
Last edited:
Looks like DIP24 (Quorum Rotation) locked-in, despite below drop in percentage of Dash v18.0 blocks found by miners (currently below trigger of 80%).



DIP24 should be fully activated at block 1737792 / 13 Sep 2022.

Please someone correct me, if i am wrong....


You are correct! We locked in with a staggering 95% of miners signalling for the hard fork! I think that might be a record.

1662468840544.png


We now wait for 4032 blocks, about 7.35 days for the hard fork to activate on block 1737792, which is about 13th of September depending on your TZ.


1662469145815.png


And we have 88.5% of the Masternode upgraded, the rest will either upgrade in time or simply be forked off the block following the fork.
 
You are correct! We locked in with a staggering 95% of miners signalling for the hard fork! I think that might be a record.

View attachment 11361

We now wait for 4032 blocks, about 7.35 days for the hard fork to activate on block 1737792, which is about 13th of September depending on your TZ.

And how do you explain the drop in the percentage of the miners?
Is there any other reasonable explanation, apart from the "agents conspiracy theory"?

View attachment 11362

And we have 88.5% of the Masternode upgraded, the rest will either upgrade in time or simply be forked off the block following the fork.

Is it just a coincidence that the percentage of the miners started falling below 80%, when the masternodes reached 80%?
 
Last edited:
And how do you explain the drop in the percentage of the miners?
Is there any other reasonable explanation, apart from the "agents conspiracy theory"?

The charts Qwizzie posts are inferior, that is why I always delete them, I only trust mnowatch as the source, there was no drop in miner signalling, it was a strong finish, perfect actually. I am surprised we locked in so soon, I was expecting it to take at least another month.
 
The charts Qwizzie posts are inferior, that is why I always delete them, I only trust mnowatch as the source, there was no drop in miner signalling, it was a strong finish, perfect actually. I am surprised we locked in so soon, I was expecting it to take at least another month.

In what chart of mnowatch.org can we see that there was no drop in miner signalling?
 
In what chart of mnowatch.org can we see that there was no drop in miner signalling?

It isn't published, last time I tried to install the Phez' fork explorer, but faced some issue, this time I did not bother, instead I had two simple scripts running on loop to monitor it.

Code:
unset oldblockcount;while : ;do blockcount=$(dash-cli getblockcount)&&fork=$(dash-cli getblockchaininfo)&& count=$(jq -r '.bip9_softforks.dip0024.statistics.count' <<<"$fork");if((blockcount!=oldblockcount));then echo -e "Block: $blockcount\tcount: $count";oldblockcount=$blockcount;fi;sleep 1;done

and

1662469998924.png


Next time we can look at adding fork explorer to the site.
 
Next time we can look at adding fork explorer to the site.

Yes...with v18 the proposal fee fell to 1 dash, so more governance proposals will be posed, and thus more forks will occur.
Lets add a fork explorer in mnowatch.org
 
Looks like the latest update to dashd (v18) reintroduced the locale issues, causing the process to terminate with:


Code:
std::terminate() called due to unhandled exception
Exception: type=std::runtime_error, what="locale::facet::_S_create_c_locale name not valid"

unless the locale is automatically set through an env variable on our machines (LC_ALL="C" && export LC_ALL)
 
Looks like the latest update to dashd (v18) reintroduced the locale issues, causing the process to terminate with:


Code:
std::terminate() called due to unhandled exception
Exception: type=std::runtime_error, what="locale::facet::_S_create_c_locale name not valid"

unless the locale is automatically set through an env variable on our machines (LC_ALL="C" && export LC_ALL)

Can you elaborate on this? Is this to start the QT wallet, or a headless node? What is your current locale?
 
In what chart of mnowatch.org can we see that there was no drop in miner signalling?

The actual data is in the blockchain so it can be reviewed directly there. But this is my snapshot from every 15 minutes showing the number of blocks signaling in the window ("Count" column): https://keybase.pub/thephez/dash-18.0.1/dash-18-miner-update-progress.csv. You can see it charted here: https://docs.google.com/spreadsheet...03vCw2r9h5KyXR7FTyyIgmoVRg/edit#gid=452706455.

I don't see any substantial change in signaling near lock-in. In fact, all the miners could have stopped signaling the last day and it still would have locked-in because the threshold had already been achieved. The Dash_info chart can be a little misleading because it doesn't factor in the signaling windows.
 
Can you elaborate on this? Is this to start the QT wallet, or a headless node? What is your current locale?

Sorry, I was talking about dashd and dash-cli being used headless as masternodes on Linux.
All images use en_US.UTF-8 as their locale and I have to override it to C by setting the LC_ALL env var.
Using Debian LTS (currently 10).
Related issue in bitcoin

After about when dash/darkcoin stopped linking its deps dynamically, the issue was gone. Now it has returned.
 
Last edited:
Nothing seems to be working. I bought a 4 core VCPU with 16gb of ram. It is 2 days now and the blockchain has not been fully synced and the CPU usage is still consuming 150%. Is there something I am doing wrong?
After updating MN to 18.0.1 it got PoSe Banned. Checking the logs showed "possible database corruption". So I wiped it out and began resyncing. After two days it still wasn't resynced so I started checking deeper. What I found eventually out is that the CPU usage is not really an issue but.... apparently 4GiB of physical plus 8GiB of swap is not enough for it to complete the full sync. `dashd` keeps gradually allocating all available memory until it gets killed. This could also explain the "possible database corruption" in the first place I guess. A memory leak somewhere in the new version?
 
After updating MN to 18.0.1 it got PoSe Banned. Checking the logs showed "possible database corruption". So I wiped it out and began resyncing. After two days it still wasn't resynced so I started checking deeper. What I found eventually out is that the CPU usage is not really an issue but.... apparently 4GiB of physical plus 8GiB of swap is not enough for it to complete the full sync. `dashd` keeps gradually allocating all available memory until it gets killed. This could also explain the "possible database corruption" in the first place I guess. A memory leak somewhere in the new version?

I also noticed that. On the first launch when building the block index, dashd would show around 5GB resident size, allocating around 10GB in total. Restarting dashd after the initial rebuild would let it return to normal levels and stop my monitoring from sending me SMS every 15 minutes x).

Also keep in mind, that Sentinel must be updated and now requires python3. You might need to rebuild your python venv!
Also note that configuring sentinel by referencing and parsing your dashd.conf is now deprecated and you're encouraged to set up environment variables instead.
 
After updating MN to 18.0.1 it got PoSe Banned. Checking the logs showed "possible database corruption". So I wiped it out and began resyncing. After two days it still wasn't resynced so I started checking deeper. What I found eventually out is that the CPU usage is not really an issue but.... apparently 4GiB of physical plus 8GiB of swap is not enough for it to complete the full sync. `dashd` keeps gradually allocating all available memory until it gets killed. This could also explain the "possible database corruption" in the first place I guess. A memory leak somewhere in the new version?
Yep, you guessed it! A new version is coming soon, v18.0.2 which will address that issue. If you need to get around the issue for now, then just restart the dashd several times during syncing to reclaim that RAM before it crashes.
 
Back
Top