Dash Core v19.0.0 Release Candidate and Testnet HardFork

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
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:

xkcd

Well-known Member
Masternode Owner/Operator
Feb 19, 2017
548
514
163
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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.
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.
 
  • Like
Reactions: qwizzie

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
@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:

xkcd

Well-known Member
Masternode Owner/Operator
Feb 19, 2017
548
514
163
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
@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
This is the same error I saw on my nodes with RC5 when testnet broke, are you certain you are on the correct binary?
 

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
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:
  • Like
Reactions: xkcd

xkcd

Well-known Member
Masternode Owner/Operator
Feb 19, 2017
548
514
163
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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

I've asked the devs to come here and check this out.
 
  • Like
Reactions: qwizzie

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
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:

Pasta

Active Member
Dash Core Group
Apr 29, 2017
115
151
93
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
 
  • Like
Reactions: xkcd and qwizzie

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
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
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:

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
Setup 1k masternode through Dashmate on Testnet :

Knipsel.JPG


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:
  • Like
Reactions: xkcd

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
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
Knipsel.JPG


Windows wallet - debug console - masternode outputs

Knipsel.JPG


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.

Knipsel.JPG


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:

xkcd

Well-known Member
Masternode Owner/Operator
Feb 19, 2017
548
514
163
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
Hey guys, Testnet went out to lunch and is now suffering from Delhi belly. Doctor's orders are bed rest with bucket beside and RC7
 
  • Sad
Reactions: qwizzie

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
Hey guys, Testnet went out to lunch
and is now suffering from Delhi belly.
Doctor's orders are bed rest with bucket beside and RC7
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.
 

xkcd

Well-known Member
Masternode Owner/Operator
Feb 19, 2017
548
514
163
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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 believe that would be the case, it appears some validation was missing somewhere which allowed some bad data to creep in halting the chain.
 

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
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 ...

Knipsel.JPG



Knipsel.JPG


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:

pshenmic

New Member
Dash Support Group
Mar 11, 2023
5
2
3
27
@qwizzie

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.
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"

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
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 =)
 
  • Like
Reactions: qwizzie

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
@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 =)
Dashmate has a (layout ?) bug sometimes, where the dashmate status core results are shown improperly in PuTTY :

Knipsel.JPG


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 :

Knipsel.JPG


A second dashmate status core try usually works.

FYI
 
Last edited:
  • Like
Reactions: pshenmic

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
Just received 4x MN payments from my HPMN, so that indeed works as intended on L1 side.

Knipsel.JPG


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:

xkcd

Well-known Member
Masternode Owner/Operator
Feb 19, 2017
548
514
163
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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.
This is as intended, there won't be any platform release until v20.
 

xkcd

Well-known Member
Masternode Owner/Operator
Feb 19, 2017
548
514
163
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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.
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.
 
  • Like
Reactions: qwizzie

qwizzie

Grizzled Member
Aug 6, 2014
2,101
1,288
1,183
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.

1679304610930.png


+ this one : to view a Tenderdash node key / platformNodeID, when it has already been generated through a Dashmate setup:

1679304772045.png
 
Last edited: