- Feb 19, 2017
- Dash Address
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).Obviously, bro. The required version is rc6.
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.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.
This is the same error I saw on my nodes with RC5 when testnet broke, are you certain you are on the correct binary?@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
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)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
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 numCommitmentsRequired numCommitmentsInNewBlock
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
Thanks for the feedback.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
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.Hopefully that explains my protx register_submit problems (final phase for getting my HPMN up) and it was not related to something at my side.
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"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.
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.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
Dashmate has a (layout ?) bug sometimes, where the dashmate status core results are shown improperly in PuTTY :@qwizzie
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 =)
This is as intended, there won't be any platform release until v20.Just received 4x MN payments from my HPMN, so that indeed works as intended on L1 side.
View attachment 11710
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.
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.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.
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.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.
I have not done that, as i am not sure if this new Platform version contains non-compatible changes.In some cases, you must also additionally reset platform data:
- Upgrade contains non-compatible changes (f.e. switching between v22/v23)
- Command dashmate setup finished with errors or interrupted in the process
- Platform layer has been wiped in the network
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.* 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
Not sure what you meant here, could you point me an example? -)* 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.
Not sure what you meant here, could you point me an example? -)