Dash Core v19.0.0 Release Candidate and Testnet HardFork

[qwizzie]

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.

 

[qwizzie]

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

 

[qwizzie]

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

 

[xkcd]

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

 

[qwizzie]

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]

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]

~~

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

 

[pshenmic]

@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 =)

 

[qwizzie]

@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 :

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

 

[qwizzie]

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.

 

[xkcd]

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]

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.

 

[qwizzie]

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:

 

[xkcd]

It's a horrible user experience asking the user to calculate that NodeID, it should an RPC in the wallet.

 

[qwizzie]

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 ?

 

[qwizzie]

@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

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

I have not done that, as i am not sure if this new Platform version contains non-compatible changes.

 

[qwizzie]

@Pasta

Blockchain explorers seem .. stuck ? (waiting for blocks)

https://insight.testnet.networks.dash.org:3002/insight/

http://insight.testnet.networks.dash.org:3001/insight/

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.

 

[pshenmic]

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

* 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

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.

* 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? -)

 

[qwizzie]

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

 

[xkcd]

HI Team, another chain freeze, we are now waiting on rc8.

https://github.com/dashpay/dash/pull/5265