Dash Core v19.0.0 Release Candidate and Testnet HardFork
- Thread starter Pasta
- Start date
Already deleted the post here and corrected on Dashpay Reddit. Thank you for finding not420guilty issue who was using v19.0.0-beta.6 instead of v19.0.0-rc.6 (which i overlooked).
Last edited:
I am starting to see this in a masternode that is downloading from scratch (deleted testnet3 folder) with v19.00 RC6
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.
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:
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 :
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)
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 :
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)
Last edited:
This is the same error I saw on my nodes with RC5 when testnet broke, are you certain you are on the correct binary?
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:
I found this in my old (and rather large) debug.log
InvalidChainFound errors around block 848500 and first popup of CheckForkWarningConditions
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
InvalidChainFound errors around block 848500 and first popup of CheckForkWarningConditions
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
The "BLS Malleable" thing may be a problem and we are investigating; but at this point we think it isn't an issue
Thanks for the feedback.
I kinda need access to my MN collateral on my Windows wallet (Dash Core v19.0.0 RC5). Is it correct that this wallet can not access Testnet (at least not passed block 848521), untill Windows Dash Core v19.0.0 RC6 is released ?
Edit : i see that the Windows Dash Core v19.0.0 RC6 is now also released, thanks.
Last edited:
Setup 1k masternode through Dashmate on Testnet :
Next step is to get gather 3000 more tdash and look for a way to change this 1K masternode to 4K masternode / HPMN, through Dashmate
(after v19.00 hard fork activates on Testnet).
RAM Usage : 13% of 16GB
SSD Storage Usage : 5.9% of 328.05GB
/var/lib/docker/volumes/
Dash Core Data Storage : 6,34 GB
Drive Data Storage : 6,79 MB
Tenderdash Data Storage : 143 KB
Docker storage numbers makes sense, as this is just a 1K masternode (on Testnet). It will be interesting to see how the Docker storage numbers change, after converting to a 4K masternode / HPMN (on Testnet).
Next step is to get gather 3000 more tdash and look for a way to change this 1K masternode to 4K masternode / HPMN, through Dashmate
(after v19.00 hard fork activates on Testnet).
RAM Usage : 13% of 16GB
SSD Storage Usage : 5.9% of 328.05GB
/var/lib/docker/volumes/
Dash Core Data Storage : 6,34 GB
Drive Data Storage : 6,79 MB
Tenderdash Data Storage : 143 KB
Docker storage numbers makes sense, as this is just a 1K masternode (on Testnet). It will be interesting to see how the Docker storage numbers change, after converting to a 4K masternode / HPMN (on Testnet).
Last edited:
I think Dash Core v19.0.0 just activated on Testnet (through block 850100)
Current block : 850114
Which should clear the way for 4K HPMN's...
@Pasta @xkcd
I tried to do a protx register_submit of a 4000 tdash transaction (after Dash Core v19 activation) that i got from the protx register_prepare command (transaction 1d00efe97eaa029b64d1dac6480523712adf8de2241ad8961ef64be920696ad4 with index 1 and with 15 transaction confirmations),
but i am getting a bad-protx-collateral (code 16) (code -1) error, after issuing that protx register_submit.
Additional info : 4000 tdash collateral was the result of a combining of multiple 1000 tdash inputs to a 4000 tdash transaction to a new address in my Windows wallet via 'payment to yourself'. I am doing the protx commands through an unlocked Windows Dash Core wallet v19.0.0 RC6
On a first glance the 4000 tdash collateral tx looks to be on output index 0 when looking at the transaction in my wallet, but when doing a masternode outputs in the debug console it becomes clear it actually has output index 1. So i used output index 1.
Windows wallet - Transactions
Windows wallet - debug console - masternode outputs
Does protx register_submit not acknowledge 4000 tdash as HPMN collateral, after this recent activation of Dash Core v19.0.0 on Testnet ?
Or do i need to do things differently now ?
Difference between my previous 1K masternode and this 4K masternode :
Different collateral transaction tx
Different BLS pair
Also created a DashPay Github issue for this : https://github.com/dashpay/dash/issues/5256
Edit 1 : has Testnet mining stalled ? Last block in my windows wallet was from two hours ago .. same as with the block explorers.
Source : https://insight.testnet.networks.dash.org:3002/insight/ & http://insight.testnet.networks.dash.org:3001/insight/
I will try a -reindex on my Windows wallet.
Edit 2 : looks like blocks are getting mined again.
Edit 3 : i decided after the -reindex of my Windows wallet to do a new 4K tdash collateral transaction to a new wallet, where i also created new addresses, new BLS pair and redo the whole protx register_prepare command. Created new transaction tx dd74c995433a62c71196d8ed66e7b6d0614160b082d4ba6fffe1539c93dda0f5 with index 1. Same problem during protx register_submit phase : bad-protx-collateral (code 16) (code -1).
Current block : 850114
Which should clear the way for 4K HPMN's...
@Pasta @xkcd
I tried to do a protx register_submit of a 4000 tdash transaction (after Dash Core v19 activation) that i got from the protx register_prepare command (transaction 1d00efe97eaa029b64d1dac6480523712adf8de2241ad8961ef64be920696ad4 with index 1 and with 15 transaction confirmations),
but i am getting a bad-protx-collateral (code 16) (code -1) error, after issuing that protx register_submit.
Additional info : 4000 tdash collateral was the result of a combining of multiple 1000 tdash inputs to a 4000 tdash transaction to a new address in my Windows wallet via 'payment to yourself'. I am doing the protx commands through an unlocked Windows Dash Core wallet v19.0.0 RC6
On a first glance the 4000 tdash collateral tx looks to be on output index 0 when looking at the transaction in my wallet, but when doing a masternode outputs in the debug console it becomes clear it actually has output index 1. So i used output index 1.
Windows wallet - Transactions
Windows wallet - debug console - masternode outputs
Does protx register_submit not acknowledge 4000 tdash as HPMN collateral, after this recent activation of Dash Core v19.0.0 on Testnet ?
Or do i need to do things differently now ?
Difference between my previous 1K masternode and this 4K masternode :
Different collateral transaction tx
Different BLS pair
Also created a DashPay Github issue for this : https://github.com/dashpay/dash/issues/5256
Edit 1 : has Testnet mining stalled ? Last block in my windows wallet was from two hours ago .. same as with the block explorers.
Source : https://insight.testnet.networks.dash.org:3002/insight/ & http://insight.testnet.networks.dash.org:3001/insight/
I will try a -reindex on my Windows wallet.
Edit 2 : looks like blocks are getting mined again.
Edit 3 : i decided after the -reindex of my Windows wallet to do a new 4K tdash collateral transaction to a new wallet, where i also created new addresses, new BLS pair and redo the whole protx register_prepare command. Created new transaction tx dd74c995433a62c71196d8ed66e7b6d0614160b082d4ba6fffe1539c93dda0f5 with index 1. Same problem during protx register_submit phase : bad-protx-collateral (code 16) (code -1).
Last edited:
Hopefully that explains my protx register_submit problem (bad-protx-collateral (code 16) (code -1) error and it was not related to something at my side.Hey guys, Testnet went out to lunchand is now suffering from Delhi belly.
Doctor's orders are bed rest with bucket beside and RC7
I believe that would be the case, it appears some validation was missing somewhere which allowed some bad data to creep in halting the chain.
Hi pshenmic,
I just found out that for registering a HPMN on Testnet through the Console of a Windows Dash Core v19.0.0 RC6 wallet, we need to use a different protx register_prepare command :
protx register_prepare_hpmn "collateralHash" collateralIndex "ipAndPort" "ownerAddress" "operatorPubKey_register" "votingAddress_register" "operatorReward" "payoutAddress_register" "platformNodeID" platformP2PPort platformHTTPPort ( "feeSourceAddress" )
Followed by a regular protx register_submit command.
With help of Strophy I found the platformP2PPort (26656) & platformHTTPPort (3000), but i have difficulty finding the platformNodeID inside my Dashmate's config.json file. I thought it was perhaps the reference to Nodekey --> id / the id in the node_key.json file, but that is throwing a 'platformNodeID must be hexadecimal string (code -8)' error in my Console.
Update 1 : Scrap that, i just discovered i placed the feeSourceAddress before the platformNodeID. So Console gave that error because it did not come across the platformNodeID, instead it came across the feeSourceAddress. It is all good now, i got a transaction and my masternode should be HPMN registered after one block. PlatformNodeID was indeed Nodekey --> id
Update 2 : I gave dashmate a start, but it looks like Drive Tenderdash keeps restarting ...
Status masternode looks okay for now. Not sure what to think about Drive Tenderdash constantly in status 'restarting'.
Even after :
dashmate stop
npm update -g dashmate
dashmate update
dashmate start
Still Drive Tenderdash in status restarting. Sometimes Drive Tenderdash is in status running, but later on it gets status restarting again.
I will try a dashmate reset --platform-only --hard
Update 3 : Both Drive ABCI & Drive Tenderdash in status restarting. It will be interesting to see if i get those 4x mn rewards from L1, despite Platform restarting constantly.
Update 4 : my HPMN get into PoSe banned status, will try to fix it. Platform in general is currently not working on v19.0.0
(strophy / DCG is also seeing status Platform restarting and has disabled Platform containers for his masternodes and is only running Core and Sentinel).
Last edited:
@qwizzie
I am waiting for all this stuff as well, because we need to make it work in the devnets first. From what I know, there were no successful runs of v19 platform in the devnet, only v18 that are currently running platform. The HPMN nodes in the v19 networks deployed by DCG will be using dashmate, and I have already prepared the changes in the deploy tool. But I have not been able to get it successfully running in the devnet yet, there are errors that I cannot resolve by changing the configuration, I have already reported it, guys are working hard to fix it. So, we gotta wait a little bit =)
I will ping you here If I will be able to deploy working v19 devnet =)
I know that you already found the way to change version, but strophy meant: "dashmate config set core.docker.image dashpay/dashd:19.0.0-rc.6"
As far as I know, HPMNs with Platform is not ready yet in the tesnet. Guys released v19 without HPMNs support, at least that what we are all agreed on. First roll out v19 without HPMNs, then finish the registration and deployment of HPMNs. Sorry, that I forgot to mention that.
I am waiting for all this stuff as well, because we need to make it work in the devnets first. From what I know, there were no successful runs of v19 platform in the devnet, only v18 that are currently running platform. The HPMN nodes in the v19 networks deployed by DCG will be using dashmate, and I have already prepared the changes in the deploy tool. But I have not been able to get it successfully running in the devnet yet, there are errors that I cannot resolve by changing the configuration, I have already reported it, guys are working hard to fix it. So, we gotta wait a little bit =)
I will ping you here If I will be able to deploy working v19 devnet =)
Dashmate has a (layout ?) bug sometimes, where the dashmate status core results are shown improperly in PuTTY :
First try gave improper layout result
Second try worked as intended.
I am on Windows 10, desktop screen resolution 3840x2160 with scale & layout at 225%
PuTTY is in above example in orginal small windowsize. Bug feels related to window size.
Dashmate also sometimes throw a DockerComposeError :
A second dashmate status core try usually works.
FYI
Last edited:
Just received 4x MN payments from my HPMN, so that indeed works as intended on L1 side.
There could be a weakness there, as my hpmn is not connected or in sync with Platform (L2). No hpmn currently is.
This means that hpmn owners could possibly exploit this on Mainnet when v19 gets released there, by choosing / modifying to run hpmn's only on L1,
untill Dash Core v20 activates and they get financially motivated to perform work on L2 as well or they miss out on 75% of their masternode rewards.
Could perhaps even lead to weaker hpmn's being used, untill Dash Core v20 activates.
There could be a weakness there, as my hpmn is not connected or in sync with Platform (L2). No hpmn currently is.
This means that hpmn owners could possibly exploit this on Mainnet when v19 gets released there, by choosing / modifying to run hpmn's only on L1,
untill Dash Core v20 activates and they get financially motivated to perform work on L2 as well or they miss out on 75% of their masternode rewards.
Could perhaps even lead to weaker hpmn's being used, untill Dash Core v20 activates.
Last edited:
Hi Qwizzie, so ideally the command to generate the NodeId pair, should be in the core wallet similar to bls generate, but the core team are not playing ball on that one, so I am working on creating an MNOwatch page that will generate the keys for us which will be ready in advance of launch.
There is also the reply of ogabrielides : https://github.com/dashpay/dash/issues/5256 who mentioned an upcoming HPMN DIP for Mainnet, with a section describing how to calculate the platformNodeID.
+ this one : to view a Tenderdash node key / platformNodeID, when it has already been generated through a Dashmate setup:
Last edited:
It's a horrible user experience asking the user to calculate that NodeID, it should an RPC in the wallet.
Looks like we are getting closer to testing v19.0.0 RC7 on Testnet.
See : https://github.com/dashpay/dash/pull/5261
Will this be The One ?
See : https://github.com/dashpay/dash/pull/5261
Will this be The One ?
Last edited:
@pshenmic
Updated my hpmn through dashmate (setup with dashpay/dashd:latest-rc) to v19.0.0 RC7 by issueing :
dashmate stop
npm update -g dashmate
dashmate update
dashmate start
According my debug.log that indeed updates my hpmn to v19.0.0 RC7 (dashmate status core just shows v19.0.0 which is a bit inconclusive feedback).
Some observations :
* Command dashmate status takes a long time to execute and is most likely in need of some refactoring, to make it as fast as the other dashmate status commands
* Commands dashmate status core & dashmate status need to show complete version number, so we don't need to verify through checking the debug.log
Also dashmate status core show v19.0.0 in red, while dashmate status shows v19.0.0 in white.
* dashmate status still shows Platform in status restarting (i assume you are still trying to fix this on devnet first, after which dashmate gets updated to include the fix)
* dashmate status host does not provide how much storage & memory is actually in use, it just shows diskfree 0 (bug ?) and some total memory numbers
I rather see this extended with more Docker-specific storage information (for example : du -sh /var/lib/docker/volumes*) and more specific memory usage based on dashd.pid per user and anything else pointing to Platform Services memory usage.
This is my current storage and memory usage from running a hpmn (not synced to Platform), which does not get reflected with a dashmate status host command :
* I noticed that Platform updated to v0.24 dev 14 yesterday (see https://github.com/dashpay/platform/commit/3f48ff600ac600369e6ca39495c4a03b5612e327)
and i am not sure if this means my hpmn possibly now needs a dashmate reset --platform-only --hard & setup command or not
Updated my hpmn through dashmate (setup with dashpay/dashd:latest-rc) to v19.0.0 RC7 by issueing :
dashmate stop
npm update -g dashmate
dashmate update
dashmate start
According my debug.log that indeed updates my hpmn to v19.0.0 RC7 (dashmate status core just shows v19.0.0 which is a bit inconclusive feedback).
Some observations :
* Command dashmate status takes a long time to execute and is most likely in need of some refactoring, to make it as fast as the other dashmate status commands
* Commands dashmate status core & dashmate status need to show complete version number, so we don't need to verify through checking the debug.log
Also dashmate status core show v19.0.0 in red, while dashmate status shows v19.0.0 in white.
* dashmate status still shows Platform in status restarting (i assume you are still trying to fix this on devnet first, after which dashmate gets updated to include the fix)
* dashmate status host does not provide how much storage & memory is actually in use, it just shows diskfree 0 (bug ?) and some total memory numbers
I rather see this extended with more Docker-specific storage information (for example : du -sh /var/lib/docker/volumes*) and more specific memory usage based on dashd.pid per user and anything else pointing to Platform Services memory usage.
This is my current storage and memory usage from running a hpmn (not synced to Platform), which does not get reflected with a dashmate status host command :
* I noticed that Platform updated to v0.24 dev 14 yesterday (see https://github.com/dashpay/platform/commit/3f48ff600ac600369e6ca39495c4a03b5612e327)
and i am not sure if this means my hpmn possibly now needs a dashmate reset --platform-only --hard & setup command or not
I have not done that, as i am not sure if this new Platform version contains non-compatible changes.
Last edited:
@Pasta
Blockchain explorers seem .. stuck ? (waiting for blocks)
The longer time interval between hpmn rewards that i also started to notice first confused me, but is likely due to hpmn getting its rewards from L1 which initially forked off a lot of normal masternodes after v19.0.0 activation (leading to a shorter time interval between rewards) and is now most likely having more normal masternodes operational again on L1 (leading to longer time interval between rewards).
Update : block explorers work again.
Blockchain explorers seem .. stuck ? (waiting for blocks)
The longer time interval between hpmn rewards that i also started to notice first confused me, but is likely due to hpmn getting its rewards from L1 which initially forked off a lot of normal masternodes after v19.0.0 activation (leading to a shorter time interval between rewards) and is now most likely having more normal masternodes operational again on L1 (leading to longer time interval between rewards).
Update : block explorers work again.
Last edited:
@qwizzie
Hey again =D. There are good and bad news.
The bad news is that testnet is currently sticked with v23, while platform guys are working with v24, so you will not be able to start HPMN in testnet until v24 branch is merged.
The good news is that today with the help of Ivan Shumkov and @odysseasg I were able to eventually spin up Platform on the top of v19 in the devnet, so expect at least working devnet soon. I guess after some testing guys are going to merge it ASAP.
Hey again =D. There are good and bad news.
The bad news is that testnet is currently sticked with v23, while platform guys are working with v24, so you will not be able to start HPMN in testnet until v24 branch is merged.
The good news is that today with the help of Ivan Shumkov and @odysseasg I were able to eventually spin up Platform on the top of v19 in the devnet, so expect at least working devnet soon. I guess after some testing guys are going to merge it ASAP.
Yeah, you are right, and fortunately I have already done that in the v24 branch. v24 contains a lot of fixes and improvements for the dashmate and much more ongoing=D.
Not sure what you meant here, could you point me an example? -)
Version only shows 19.0.0 and it shows it in red.
It does not show which release candidate this is and i am also not sure why it is in red.
dashmate status core and dashmate status should show Version 19.0.0 RC.7 and dashmate status core Version 19.0.0 (RC.7) should just be in white,
as it is the latest version on Testnet. In above screenshot v19.0.0 is Testnet and v18.2.2 is Mainnet (which could also be better specified).
Last edited:
HI Team, another chain freeze, we are now waiting on rc8.
github.com
fix: hpmn registration after revocation caused mining failure by PastaPastaPasta · Pull Request #5265 · dashpay/dash
Issue being fixed or feature implemented We reset operator info on revocation; but then on replacement via new register we try to "RemoveMN", which tries to remove platformNodeID but that's already...
github.com