Dash Core v19.0.0 Release Candidate and Testnet HardFork

Pasta said:
You’re thinking about it wrong those are the number of transactions per block. High-performance masternode’s get paid four blocks in a row but they do not get paid four times in one block.
Click to expand...

Yep, makes sense now i think about it.
 
Looks like my online picture--> text OCR conversion gave me a wrongly converted address for both HPMN payout addresses, which explains why i did not find anything on the test block explorer (having the ability to just copy and paste from inside Masternodes --> Specific masternode --> Masternode fields, would be really really handy).

Correct HPMN payout addresses :


Those can also be imported in our own wallets as watch-only addresses, through importaddress command (nice that it automatically rescans).

Knipsel.JPG


Knipsel.JPG


Knipsel.JPG


Pretty cool to see how the wallet handles Watch-only addresses in the Balances.

HPMN 1 with payoutaddress yZXJSfikjYFuRXypjUJzRfFLxZjUMBGqGG received 4 MN rewards so far.
HPMN 2 with payout address yhz4PAcxNewHiEkfHNjqyupiKChBXMHjyp received 24 MN rewards so far.
 
Last edited:
qwizzie, the 2 HPMNs I created were dummy nodes to verify the process, there is no backend server for them, I was about to create a real HPMN when the network got choked. For now, I am not doing anything until RC6 is out and then I will pick up where I left off and also verify the payments of the HPMNs.
 
Any chance Dashmate will be updated to fetch Dash Core v19.0.0 release candidate 6, once that is released to Testnet ?
Dashmate currently only seem to fetch v18.2.0 and only detects new version 18.2.1 (which it won't seem willing to upgrade to)

Knipsel.JPG


I will wait on v19.0.0 RC 6 release on Testnet and hope Dashmate can fetch it by that time. I was kinda expecting Dashmate would at least fetch v19.0.0 RC 5

Also i plan to use Dashmate to setup a HPMN on Testnet to get familiar with Dashmate (rented a VPS for this purpose), but that does not seem possible untill pull request 794 (https://github.com/dashpay/platform/pull/794) has been merged. It would have been nice to have this merged already, when v19.0.0 RC 5 got released to Testnet.

I guess the manual methode is now the only way to setup HPMN's on Testnet.
Link : https://docs.dash.org/en/stable/doc....html#testnet-masternode-setup-install-manual

Quick question about Dashmate : when i run dashmate setup -p 4000 (or dashmate setup -p 1000) on Testnet, i get the following message :

Knipsel.JPG


How do i disable 'wallet mode on' ? And should Dashmate not disable this on its own in this specific process ?

Also in the dash.conf (.dashmate/testnet/core/) the rpcuser & rpcpassword i assume need to be changed afterwards to an unique rpc user
and an unique rpc password ? I do hope this becomes clear to users further in this HPMN / Normal masternode setup process, through Dashmate.
Because it does not become clear, when just doing a dashmate setup -p command.
 
Last edited:
Be aware our current plan will be to reorganize testnet with rc.6 so that we can re-experience the c19 hard fork hopefully with less issues this time! I’ll ask strophy to respond here about dashmate.
 
Looks like setup with funding private key is definetly broken, thank you very much for spotting it. I have created a github issue in platform repo (cannot post link due to restrictions), going to make it fixed in the next dashmate release.
But also wanted to ask what do you mean by `-p 4000`, because -p expect a funding private key to pass

Regading versions, core image for mainnet and testinet is currently hardcoded in the config and thus is not possible to change version with out making a new npm release. I would suggest switch to docker image tag instead, so we could easily pull new images via `dashmate update` without upgrading the software. Looks like we need this, because sometimes we need to just update the node (like we have now with testnet). @strophy What do you think?
 
Last edited:
I'm not sure how platform guys intend to set versions, but I agree requiring a platform release just to bump the core version is not optimal. It might be an idea to be able to fetch a good config from a remote server, but this would require a bit of setup and maintenance. We could also use latest and latest-dev tags, but this broke things before as well due to version incompatibilities I think.

Until we have a solution for this, please use the `dashmate config set` command to adjust versions as necessary.
 
pshenmic said:
Looks like setup with funding private key is definetly broken, thank you very much for spotting it. I have created a github issue in platform repo (cannot post link due to restrictions), going to make it fixed in the next dashmate release.
But also wanted to ask what do you mean by `-p 4000`, because -p expect a funding private key to pass
Click to expand...

I was under the impression that -p 4000 would add 4000 tdash to that masternode during dashmate setup (which would have been handy),
but reading your reply it looks like it checks if a MN collateral amount exists (by verifying the private key of a MN collateral address) before proceeding further.

I will use the test faucet to aquire 4000 tdash, obtain the privatekey and try -p privatekeyofmncollateral later again, once the bug has been squashed.

It would have been nice though : miners on Testnet could have some of their blockrewards automatically put into some combined tdash pool, where Dashmate can directly fetch either 1000 tdash or 4000 tdash, so the process does not get interrupted with people having to gather tdash first, when using Dashmate to setup either a masternode or a HPMN on Testnet. It would involve storing tdash directly in the wallet of a masternode / HPMN on Testnet, which i don't think is possible these days. So that would need changes. But from a testing point of view having this done in the background during Dashmate setup, would simplify things for users and makes setting up masternodes / HPMN's faster on Testnet.
 
Last edited:
strophy said:
I'm not sure how platform guys intend to set versions, but I agree requiring a platform release just to bump the core version is not optimal. It might be an idea to be able to fetch a good config from a remote server, but this would require a bit of setup and maintenance. We could also use latest and latest-dev tags, but this broke things before as well due to version incompatibilities I think.

Until we have a solution for this, please use the `dashmate config set` command to adjust versions as necessary.
Click to expand...

Knipsel.JPG


Assuming strophy's comment at the end was directed towards me : I could use some help here, how would i set dashmate config set command exactly ?
I am not sure what the option path or option value is, with regards to fetching latest Dash Core version 19.0.0 on Testnet.

Also there is the problem that Dashmate is currently not ready to setup HPMN's on Testnet, untill pull request 794 (https://github.com/dashpay/platform/pull/794) is merged. Are we waiting to merge this pull request, untill v19 activates (in this case for the second time) on Testnet and new RPC commands become available ?
 
Last edited:
Found a way to have Dashmate fetch Dash Core v19.0.0 RC5 by directly adjusting the config.json
which is located in home/user/.dashmate/

There is a testnet part in there, which needs to be corrected from :

"testnet": {
"description": "node with testnet configuration",
"group": null,
"docker": {
"network": {
"subnet": "172.25.24.0/24"
}
},
"core": {
"docker": {
"image": "dashpay/dashd:18.2.0"
},

to

"testnet": {
"description": "node with testnet configuration",
"group": null,
"docker": {
"network": {
"subnet": "172.25.24.0/24"
}
},
"core": {
"docker": {
"image": "dashpay/dashd:19.0.0-rc.5"
},

Same can be done for RC 6 (i hope), once it becomes available.

Debug.log shows Dashmate indeeds fetch 19.0.0 RC5 on Testnet through this (does not sync though, because of no DNS seed or because of problems related to RC5).
Location debug.log : /var/lib/docker/volumes/dash_masternode_testnet_core_data/_data/.dashcore/testnet3/

Dashmate status core :

Knipsel.JPG


Now the waiting is on v19.0.0 release candidate 6 in Docker Hub, so i can see if this indeed works as i hope it does (and also starts syncing).

The Docker Hub and related dashpay/dashd tags can be found here : https://hub.docker.com/r/dashpay/dashd/tags
I guess using 'latest-rc' instead of a very specific release tag could work too, but Strophy mentioned some problems with that in the past.

Knipsel.JPG


You can even edit the config.json (testnet part !) to refer to a different BLS privkey, in case people have some difficulty with the BLS keys, when going through a dashmate setup and ending up with a different (older) BLS privkey in the dash.conf then generated during a more recent dashmate setup (happened to me a few times).

Update : Docker image / tag dashpay/dashd:19.0.0-rc.6 now available on the Docker Hub. I will wait for official announcement from Pasta though.
 
Last edited:
I am starting to see this in a masternode that is downloading from scratch (deleted testnet3 folder) with v19.00 RC6

1678789452188.png


Anyone else noticing these errors in their debug.log ?
Blocks and Revs have stopped increasing after blk00018.dat & rev00018.dat

@xkcd Do we need to do a reindex, even when downloading from scratch ? I will try that, to see if i can get going again.
 
Last edited:
qwizzie said:
I am starting to see this in a masternode that is downloading from scratch (deleted testnet3 folder) with v19.00 RC6

View attachment 11683

Anyone else noticing these errors in their debug.log ?
Blocks and Revs have stopped increasing after blk00018.dat & rev00018.dat

@xkcd Did Testnet just forked or something ? Do we need to do a reindex even when downloading from scratch ? Will try that to see if i can get going again.
Click to expand...

That log actually looks fine to me. You are right you need to reindex if using existing data, but if downloading from fresh, then no. My tip is currently 849520 and hash is 00000126b69304e5a01f35fa8600d58aea80f78e5b36f19730f2cd812244b8c2 if you can verify that block and hash when you are caught up, then you know you are on the right chain.
 
@Pasta

Downloaded from scratch (by deleting testnet3 folder) with v19.0.0 RC6
Noticed some 'forked chain older then last checkpoint height 794922' messages, stopped dashd and did a -reindex, i am now (after the reindex) seeing the following :


1678792693509.png


FYI (because latest release candidate also involved a malleable BLS fix merge, if i remember correctly --> https://github.com/dashpay/dash/commit/5f26a7b85c33e7d77c363a0bdcdc93681168fc64).
Hopefully this works as intended.

dashd is still busy syncing by the way, its not all invalids (just a lot)

Knipsel.JPG
 
Last edited:
qwizzie said:
@Pasta

Downloaded from scratch (by deleting testnet3 folder) with v19.0.0 RC6
Noticed some 'forked chain older then last checkpoint height 794922' messages, stopped dashd and did a -reindex, i am now (after the reindex) seeing the following :


View attachment 11684

FYI (because latest release candidate also involved a malleable BLS fix merge, if i remember correctly --> https://github.com/dashpay/dash/commit/5f26a7b85c33e7d77c363a0bdcdc93681168fc64).
Hopefully this works as intended.

dashd is still busy syncing by the way, its not all invalids (just a lot)

View attachment 11685
Click to expand...

This is the same error I saw on my nodes with RC5 when testnet broke, are you certain you are on the correct binary?
 
xkcd said:
This is the same error I saw on my nodes with RC5 when testnet broke, are you certain you are on the correct binary?
Click to expand...

Just did a stop, and restart of dashd and with a new debug.log (saved old 378 MB debug.log in case devs needs it)

2023-03-14T12:07:24Z Dash Core version v19.0.0-rc.6 (release build)
2023-03-14T12:07:24Z InitParameterInteraction: parameter interaction: -externalip set -> setting -discover=0
2023-03-14T12:07:24Z InitParameterInteraction: parameter interaction: additional indexes -> setting -checklevel=4
2023-03-14T12:07:24Z Assuming ancestors of block 00000104cb60a2b5e00a8a4259582756e5bf0dca201c0993c63f0e54971ea91a have valid signatures.
2023-03-14T12:07:24Z Setting nMinimumChainWork=00000000000000000000000000000000000000000000000002d68c04d48c0c9c
2023-03-14T12:07:24Z fDisableGovernance 0

So yes, definetely on the right binary.

2023-03-14T12:10:26Z [ProcessBlock] h[849560] numCommitmentsRequired[0] numCommitmentsInNewBlock[0]
2023-03-14T12:10:26Z CDeterministicMNManager::BuildNewListFromBlock -- MN 0e7917403b2d5cd849bfae417decce7c7c3f05d9322d81ed4ef3a4a753e1f612, nConsecutivePayments=0
2023-03-14T12:10:26Z UpdateTip: new best=0000011304fbdd9fa1496063ce967e92eeb09b33bdf4fb3618ef64061106ff71 height=849560 version=0x20000000 log2_work=57.504916 tx=5795394 date='2023-03-14T12:10:14Z' progress=1.000000 cache=0.1MiB(526txo) evodb_cache=0.0MiB
2023-03-14T12:10:26Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2023-03-14T12:10:26Z ProcessNewBlock : ACCEPTED

Will do another -reindex
 
Last edited:
qwizzie said:
Just did a stop, and restart of dashd and with a new debug.log

2023-03-14T12:07:24Z Dash Core version v19.0.0-rc.6 (release build)
2023-03-14T12:07:24Z InitParameterInteraction: parameter interaction: -externalip set -> setting -discover=0
2023-03-14T12:07:24Z InitParameterInteraction: parameter interaction: additional indexes -> setting -checklevel=4
2023-03-14T12:07:24Z Assuming ancestors of block 00000104cb60a2b5e00a8a4259582756e5bf0dca201c0993c63f0e54971ea91a have valid signatures.
2023-03-14T12:07:24Z Setting nMinimumChainWork=00000000000000000000000000000000000000000000000002d68c04d48c0c9c
2023-03-14T12:07:24Z fDisableGovernance 0

So yes, definetely on the right binary.

2023-03-14T12:10:26Z [ProcessBlock] h[849560] numCommitmentsRequired[0] numCommitmentsInNewBlock[0]
2023-03-14T12:10:26Z CDeterministicMNManager::BuildNewListFromBlock -- MN 0e7917403b2d5cd849bfae417decce7c7c3f05d9322d81ed4ef3a4a753e1f612, nConsecutivePayments=0
2023-03-14T12:10:26Z UpdateTip: new best=0000011304fbdd9fa1496063ce967e92eeb09b33bdf4fb3618ef64061106ff71 height=849560 version=0x20000000 log2_work=57.504916 tx=5795394 date='2023-03-14T12:10:14Z' progress=1.000000 cache=0.1MiB(526txo) evodb_cache=0.0MiB
2023-03-14T12:10:26Z CheckForkWarningConditions: Warning: Found invalid chain at least ~6 blocks longer than our best chain.
Chain state database corruption likely.
2023-03-14T12:10:26Z ProcessNewBlock : ACCEPTED

Will do another -reindex
Click to expand...


I've asked the devs to come here and check this out.
 
I found this in my old (and rather large) debug.log
InvalidChainFound errors around block 848500 and first popup of CheckForkWarningConditions

1678797534739.png
1678797534739.png


I am currently doing a reindex and i am again finding malleable BLS object: iostream error messages and errors about forked chain older than last checkpoint (height 794922), in my new debug.log

So a reindex does not seem to help much. I will try another complete delete of testnet3 folder, restart of dashd and download from scratch.
Edit 1 : Looks good so far, currently on block 849610
Edit 2 : Completely synced up through manual installation methode (through using the binary and just focusing on Core & Sentinel) . I will now test Dashmate setup with v19.0.0 RC6
 
Last edited:
The "invalid chain at least ~6 blocks longer" isn't concerning as we reorganized the chain. The can be safely ignored.

The "BLS Malleable" thing may be a problem and we are investigating; but at this point we think it isn't an issue
 
You must log in or register to reply here.
Back
Top