Dash Core v19.0.0 Release Candidate and Testnet HardFork

[Pasta]

Attention all testnet operators and individuals which would like to test against Dash Core v19.0.0 before the final version is released.

We have released v19.0.0-rc.5. This will hard fork testnet at height 847000 (somewhere around March 4th). All nodes must upgrade to rc.5 by this height or they will fork off. Then on March 6th, the signaling for v19 hard fork will begin on testnet. In the days following March 6th, the v19 hf will activate. Again, to follow this chain nodes must be on rc.5 or above. The v19 hard fork will activate the new BLS version as well as HPMN (high performance master node) registration.

Please see 19.0.0-rc.5 here: https://github.com/dashpay/dash/releases/tag/v19.0.0-rc.5

Feel free to respond to this thread with any questions. For a list of breaking changes / WIP release notes, please see all the `release-notes*` files in this directory https://github.com/dashpay/dash/tree/v19.x/doc

 

[xkcd]

Did we go to RC too soon? My goodness, RC5 already? Was RC1 then really a Release Candidate? I really doubt it since the HF params were only added in RC4 and RC5. We should have stuck with the Beta labelling for longer.

 

[Pasta]

Wasn’t really that we tagged RC.1 too soon, we just forgot to include a couple of important things before tagging it.

the gist is as follows
We released RC.1. But we didn’t set the activation times for the v19 hard fork, so that needed fixing for the HF to activate.
In RC.2 we forgot to update the minimum masternode protocol version so masternode wouldnt get POSE banned when they should during the upgrade.
We released RC.3, but during our testing planning infra told us that in order to achieve our cost goals on testnet, we needed to use a different LLMQ. As such we introduced the new llmq, tied it to a block height activated HF and released rc.4. However we didn’t realize that this would introduce a problem where we both needed the miner to be upgraded and couldn’t allow the miner to be upgraded to do testing as we wanted. So then, RC.5 got released with the delayed testnet HF date for the v19 hard fork.

while it’s not really ideal to have all these RCs all ready, it was intentional to move fast and maybe break stuff with the first few RCs and so far we are successfully doing both. rc.3 was released two days ago rc.4 yesterday and rc.5 today. We do intend to have better documentation and processes to always minimize these kind of issues, but in the end, I’d rather have a lot of RCs than take forever for the final release. Hopefully it doesn’t end up being both.

 

[xkcd]

Dear Dash Enthusiasts!

The Testnet has just forked to the v19 HPMN consensus rules and we've just seen our first Hyper nodes form on testnet!

So, let's get to testing this and see if we can't find any bugs.

 

[qwizzie]

Is Testnet stuck on block 848520 ? I am using this explorer : http://insight.testnet.networks.dash.org:3001/insight/blocks

Both my test wallet and this explorer seem stuck at block 848520

Mempool in my test wallet shows 139 transactions, waiting to be processed into a block.
v19.0.0-rc.5 (since two days with a fresh install, so before today's hard fork signaling and activation)
Windows 10

Blockhash 848520 : 0000001398bd963f38df73632ed3850ac17b488bfef6f278618d749249c24bce


17:52:15
reconsiderblock 0000001398bd963f38df73632ed3850ac17b488bfef6f278618d749249c24bce

17:52:15
null

Note : the two High Performance masternodes do not seem to be receiving any PoSe scores, at least not yet.
Interesting to keep an eye on, if Testnet is indeed stuck at block 848520.
(see also : https://www.dash.org/forum/threads/hpmn-faq-page.53444/#post-233839)

Edit : closing the test wallet and restarting it puts the test wallet in an endless syncing headers (100%) loop.
I will try a -reindex just in case the problem is at my side.

 

[Pasta]

We are also seeing this issue; we have identified a root cause that will be fixed in rc.6 and we are attempting to revive the network in the meantime. I'm currently mining blocks up to 848553 with a hash of 0000037dceaf3b6fbefb8f08b7587125a752d72b546e993b12f5da43b0fc345b, but it seems that either this isn't being propagated or the non-reindexed nodes are not trying to download it for some reason. I'll try and respond with more info as I have it..

 

[qwizzie]

The -reindex attempt of mine got me stuck at block 848501
F.Y.I.

debug.log shows the following :

2023-03-06T20:38:04Z UpdateTip: new best=0000002f4a074380a56a247c44f43d1568c70fa661cc8219afafdafe38100978 height=848518 version=0x20000000 log2_work=57.504916 tx=5790496 date='2023-03-06T10:30:00Z' progress=0.999980 cache=71.3MiB(518462txo) evodb_cache=55.4MiB
2023-03-06T20:38:04Z [ProcessBlock] h[848519] numCommitmentsRequired[0] numCommitmentsInNewBlock[0]
2023-03-06T20:38:04Z CDeterministicMNManager::BuildNewListFromBlock -- MN 1d0adeaf787ed8f6f73fa936c6313ddfa2dd33ea693a2de22bc346c1b73a4a02, nConsecutivePayments=0
2023-03-06T20:38:05Z UpdateTip: new best=000001f8c5b5ed6920b3162893f966c30dfc53312ada9f4e5dad2809a428b2f1 height=848519 version=0x20000000 log2_work=57.504916 tx=5790497 date='2023-03-06T10:31:53Z' progress=0.999980 cache=71.3MiB(518464txo) evodb_cache=55.4MiB
2023-03-06T20:38:05Z [ProcessBlock] h[848520] numCommitmentsRequired[0] numCommitmentsInNewBlock[0]
2023-03-06T20:38:05Z CDeterministicMNManager::BuildNewListFromBlock -- MN 610f8f8dd4cae7aec25116ce7104742254ec559baa67b27ab471ece2a2aa7803, nConsecutivePayments=0
2023-03-06T20:38:05Z UpdateTip: new best=0000001398bd963f38df73632ed3850ac17b488bfef6f278618d749249c24bce height=848520 version=0x20000000 log2_work=57.504916 tx=5790498 date='2023-03-06T10:32:17Z' progress=0.999980 cache=71.3MiB(518467txo) evodb_cache=55.4MiB
2023-03-06T20:38:05Z Filling coin cache with masternode UTXOs...
2023-03-06T20:38:05Z Filling coin cache with masternode UTXOs: done in 0ms
2023-03-06T20:38:05Z Imported mempool transactions from disk: 139 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
2023-03-06T20:38:05Z loadblk thread exit
2023-03-06T20:46:48Z Potential stale tip detected, will try using extra outbound peer (last tip update: 523 seconds ago)
2023-03-06T20:46:55Z New outbound peer connected: version: 70227, blocks=848520, peer=22 (full-relay)
2023-03-06T20:47:33Z ThreadSocketHandler -- removing node: peer=22 nRefCount=1 fInbound=0 m_masternode_connection=0 m_masternode_iqr_connection=0
2023-03-06T20:49:48Z Potential stale tip detected, will try using extra outbound peer (last tip update: 703 seconds ago)
2023-03-06T20:49:50Z New outbound peer connected: version: 70227, blocks=848520, peer=23 (full-relay)
2023-03-06T20:50:34Z ThreadSocketHandler -- removing node: peer=23 nRefCount=1 fInbound=0 m_masternode_connection=0 m_masternode_iqr_connection=0
2023-03-06T20:52:48Z Potential stale tip detected, will try using extra outbound peer (last tip update: 883 seconds ago)
2023-03-06T20:52:49Z New outbound peer connected: version: 70227, blocks=842808, peer=24 (full-relay)
2023-03-06T20:53:05Z Timeout downloading headers from peer=0, disconnecting
2023-03-06T20:53:05Z ThreadSocketHandler -- removing node: peer=0 nRefCount=1 fInbound=0 m_masternode_connection=0 m_masternode_iqr_connection=0
2023-03-06T20:53:05Z New outbound peer connected: version: 70227, blocks=848520, peer=25 (full-relay)
2023-03-06T20:54:19Z ThreadSocketHandler -- removing node: peer=25 nRefCount=1 fInbound=0 m_masternode_connection=0 m_masternode_iqr_connection=0
2023-03-06T20:55:48Z Potential stale tip detected, will try using extra outbound peer (last tip update: 1063 seconds ago)
2023-03-06T20:55:49Z New outbound peer connected: version: 70227, blocks=848520, peer=26 (full-relay)
2023-03-06T20:56:34Z ThreadSocketHandler -- removing node: peer=26 nRefCount=1 fInbound=0 m_masternode_connection=0 m_masternode_iqr_connection=0

 

[xkcd]

Yeah, best to wait for RC6 than struggle on, the network choked on one particular TX and will now require unchoking to get through it.

 

[Pasta]

Un-choking seems to me to be complete; at least on DCG nodes. The network is now at height 849787 and 000001ca43a8a84fbc3c988688dae364e02694398f13846e1a6675cd1d5a673f; CLSigs are also sporadicly happening; it appears that only a few of the quorums are operation atm, but that's expected to resolve itself as new quorums form.

It seems to me that people shouldn't need to do anything special to get synced up to this tip, at least so long as your node didn't stall with the rest of the network a day or two ago. If that was the case, then you may need a restart. I'd like some feedback if others here are able to sync up to tip with rc.5.

 

[qwizzie]

After my previous -reindex that got me stuck at block 848501 i can now fully sync to latest block (849799).
The test block explorers may need a push though, as those are still stuck at block 848521

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

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

and this one is not fetching blocks at all :

Insight

Dash Insight. View detailed information on all Dash transactions and block.

testnet-insight.dashevo.org

All three test block explorers are mentioned here : https://docs.dash.org/en/stable/docs/user/developers/testnet.html

Interesting to see that High Performance masternodes can get PoSe banned as well on L1, that solves that question.

 

[Pasta]

Both explorers should be up to date now @qwizzie

Well... not sure about https://testnet-insight.dashevo.org/insight/, but the other one is good

 

[qwizzie]

Both explorers should be up to date now @qwizzie

Well... not sure about https://testnet-insight.dashevo.org/insight/, but the other one is good

Did those two High Performance masternodes indeed get paid 4x at block 849416 & 849423 ? I have difficulty
getting anything from the payout adressess of these two High Performance masternodes :

yhz4PAcxNewHiEkiHNjqyupiKChBXMHjyp
yZXJSfikjYFuRXypjUJzRIFLxZjUMBGqGG

The test block explorers don't seem to fetch any transactions on those two test addresses (endless searching on one, and no match found on the other).
This is what i found so far with regards to the blocks :

19:24:03
getblock 000000df6adf9225702a43312e9369435a1b51013559a20d98eb14ba0884f21a

19:24:03
{
"hash": "000000df6adf9225702a43312e9369435a1b51013559a20d98eb14ba0884f21a",
"confirmations": 393,
"size": 1309,
"height": 849423,
"version": 536870912,
"versionHex": "20000000",
"merkleroot": "26d62d6df38f600b6af60169bbb722f532f69e52c5646d6ab7c2a6f197b2f588",
"tx": [
"5f769d7a92683cb9f419a5d8b280a19e8d7b523806ad97bd0fa684c42106733c",
"7a1e2b08572fab2e53740f145aa11a0f23f96e8d3d18ae36c197e9674190f5a8",
"f430cec2dd7b7a944b01115f4863d9de5d8e1956e6f8741f4681f136e032890c",
"d5a520bf4922c45e957a2341eabefa90f2edf16d5ec6cb68985a17b1baddbec1"
],
"cbTx": {
"version": 2,
"height": 849423,
"merkleRootMNList": "26c90ccbf89e5f06c6721cdb9237445163f2f31502330ab276ddd5ef32672abf",
"merkleRootQuorums": "351bf5256ccffaacb24eef9038a0fc50834d9795cb65a61243e04c03e50b6401"
},
"time": 1678244862,
"mediantime": 1678244178,
"nonce": 511019,
"bits": "1e01b481",
"difficulty": 0.002290895286142557,
"chainwork": "00000000000000000000000000000000000000000000000002d68c885a0a3557",
"nTx": 4,
"previousblockhash": "00000195773c326e9f2b5976e739c3ca69f62ce8955f246a567fa763ed4f9d5d",
"nextblockhash": "000001409a5608ca9f54bdf4af5e76de6a5b65761a280f773d11a2156433fb10",
"chainlock": true
}


19:25:24
getblock 00000113bfa54bd55d128e28a2d33ebebdabbec26b37cc280f5afb6dca383e45

19:25:24
{
"hash": "00000113bfa54bd55d128e28a2d33ebebdabbec26b37cc280f5afb6dca383e45",
"confirmations": 401,
"size": 277,
"height": 849416,
"version": 536870912,
"versionHex": "20000000",
"merkleroot": "ac96e3bb802206d194e3cd4d26a2d02db8499a09725e3e35c7089fa9b093f2e7",
"tx": [
"ac96e3bb802206d194e3cd4d26a2d02db8499a09725e3e35c7089fa9b093f2e7"
],
"cbTx": {
"version": 2,
"height": 849416,
"merkleRootMNList": "26c90ccbf89e5f06c6721cdb9237445163f2f31502330ab276ddd5ef32672abf",
"merkleRootQuorums": "351bf5256ccffaacb24eef9038a0fc50834d9795cb65a61243e04c03e50b6401"
},
"time": 1678244067,
"mediantime": 1678243100,
"nonce": 122633,
"bits": "1e0199f5",
"difficulty": 0.002439242810793814,
"chainwork": "00000000000000000000000000000000000000000000000002d68c8855ff2401",
"nTx": 1,
"previousblockhash": "0000001df53e40b7df15949ed74a5d9335ef9905c0388cdfdf606b1115eb7a67",
"nextblockhash": "00000172e8fcfa765b0703894de2fffd8b3ad4536f4b89b4e170a02aae391569",
"chainlock": true
}

Did one High Performance masternode (121.1.2.3:19999) only get paid 1x ?

 

[Pasta]

Well, you're using that RPC wrong. See https://docs.dash.org/projects/core...edure-calls-wallet.html#listreceivedbyaddress

 

[Pasta]

Also, both HPMNs are PoSe banned atm, so neither should be getting rewards at this point; not sure when they got banned though

 

[qwizzie]

Also, both HPMNs are PoSe banned atm, so neither should be getting rewards at this point; not sure when they got banned though

but if they indeed do get rewarded (see previous edited comment of mine, as i later looked at the blocks directly) should they both not be rewarded 4x ?

 

[Pasta]

I am indeed seeing some weirdness about MN Payments. Some recent examples

https://insight.testnet.networks.da...fa85e9fb603c149962bb87cbd3a791fd1d4dee425656e pays miner + mn
https://insight.testnet.networks.da...15f241739add038b8e8871af1880067b63d8002927205 miner
https://insight.testnet.networks.da...85e7b6958da3dcc0f4a4f5affb59bdf4307e94775b5a4 miner
https://insight.testnet.networks.da...e0cf7c3f2f89df888e4dd5161defa6de20bb949ba8ab7 miner + proposal
https://insight.testnet.networks.da...e53f719088693bf83e8a79339da2603bc8528142c7087 miner
https://insight.testnet.networks.da...11ab87fa7ac7af61fed458134d3a88db1d2ec799aaae9 miner
https://insight.testnet.networks.da...6e1773cd9a66206e884ccfc1e30946699a4e8eb63d287 miner + mn


There's no reason why 5 blocks in a row should have no MN payments from what I can tell. We are investigating this now.. Thanks for bringing it to our attention at this point!

 

[Pasta]

Actually, after further review it appears that insight is messing up here! if you run the following you'll see proper payouts; but insight is improperly combining them as they both go to the same address

13:03:23 getblock 0000013b1f97515a04611ab87fa7ac7af61fed458134d3a88db1d2ec799aaae9 2 13:03:23 { "hash": "0000013b1f97515a04611ab87fa7ac7af61fed458134d3a88db1d2ec799aaae9", "confirmations": 17, "size": 277, "height": 849818, "version": 536870912, "versionHex": "20000000", "merkleroot": "d7127a9d6b34026b2d6c845743396498bb3e21f4955e4fbdc4fd32ddfbcd6135", "tx": [ { "txid": "d7127a9d6b34026b2d6c845743396498bb3e21f4955e4fbdc4fd32ddfbcd6135", "version": 3, "type": 5, "size": 196, "locktime": 0, "vin": [ { "coinbase": "039af70c0101", "sequence": 4294967295 } ], "vout": [ { "value": 6.69119639, "valueSat": 669119639, "n": 0, "scriptPubKey": { "asm": "OP_DUP OP_HASH160 64f2b2b84f62d68a2cd7f7f5fb2b5aa75ef716d7 OP_EQUALVERIFY OP_CHECKSIG", "hex": "76a91464f2b2b84f62d68a2cd7f7f5fb2b5aa75ef716d788ac", "reqSigs": 1, "type": "pubkeyhash", "addresses": [ "yVXDAM73Tg6A44Bm3qduXsMCYxzuqBCT48" ] } }, { "value": 10.03679457, "valueSat": 1003679457, "n": 1, "scriptPubKey": { "asm": "OP_DUP OP_HASH160 64f2b2b84f62d68a2cd7f7f5fb2b5aa75ef716d7 OP_EQUALVERIFY OP_CHECKSIG", "hex": "76a91464f2b2b84f62d68a2cd7f7f5fb2b5aa75ef716d788ac", "reqSigs": 1, "type": "pubkeyhash", "addresses": [ "yVXDAM73Tg6A44Bm3qduXsMCYxzuqBCT48" ] } } ], "extraPayloadSize": 70, "extraPayload": "02009af70c000c3e99e8842eadc293c0eea12ea6d1b72f805466c8512dc20c909a3e25163fc4374d4d73da98d3e83795562bfee10876f84a4085137f406bae07f529074f2b12", "cbTx": { "version": 2, "height": 849818, "merkleRootMNList": "c43f16253e9a900cc22d51c86654802fb7d1a62ea1eec093c2ad2e84e8993e0c", "merkleRootQuorums": "122b4f0729f507ae6b407f1385404af87608e1fe2b569537e8d398da734d4d37" }, "hex": "03000500010000000000000000000000000000000000000000000000000000000000000000ffffffff06039af70c0101ffffffff0297f4e127000000001976a91464f2b2b84f62d68a2cd7f7f5fb2b5aa75ef716d788ace1eed23b000000001976a91464f2b2b84f62d68a2cd7f7f5fb2b5aa75ef716d788ac000000004602009af70c000c3e99e8842eadc293c0eea12ea6d1b72f805466c8512dc20c909a3e25163fc4374d4d73da98d3e83795562bfee10876f84a4085137f406bae07f529074f2b12", "instantlock": true, "instantlock_internal": false } ], "cbTx": { "version": 2, "height": 849818, "merkleRootMNList": "c43f16253e9a900cc22d51c86654802fb7d1a62ea1eec093c2ad2e84e8993e0c", "merkleRootQuorums": "122b4f0729f507ae6b407f1385404af87608e1fe2b569537e8d398da734d4d37" }, "time": 1678300341, "mediantime": 1678299598, "nonce": 401114, "bits": "1e015641", "difficulty": 0.002921762828560668, "chainwork": "00000000000000000000000000000000000000000000000002d68c891bfce971", "nTx": 1, "previousblockhash": "000000779a216d43f48e53f719088693bf83e8a79339da2603bc8528142c7087", "nextblockhash": "00000029399d11f6d1b6e1773cd9a66206e884ccfc1e30946699a4e8eb63d287", "chainlock": true }

 

[Pasta]

Regarding the HPMN payouts block 849413-849416 pay the HPMN, so all looks correct

 

[qwizzie]

Regarding the HPMN payouts block 849413-849416 pay the HPMN, so all looks correct

Block 849416 : 1x rewards

getblock 00000113bfa54bd55d128e28a2d33ebebdabbec26b37cc280f5afb6dca383e45

"tx": [
"ac96e3bb802206d194e3cd4d26a2d02db8499a09725e3e35c7089fa9b093f2e7"
],

Block 849423 : 4x rewards

getblock 000000df6adf9225702a43312e9369435a1b51013559a20d98eb14ba0884f21a

"tx": [
"5f769d7a92683cb9f419a5d8b280a19e8d7b523806ad97bd0fa684c42106733c",
"7a1e2b08572fab2e53740f145aa11a0f23f96e8d3d18ae36c197e9674190f5a8",
"f430cec2dd7b7a944b01115f4863d9de5d8e1956e6f8741f4681f136e032890c",
"d5a520bf4922c45e957a2341eabefa90f2edf16d5ec6cb68985a17b1baddbec1"
],

Why does HPMN 121-1-2-3:1999 only receive 1x reward on block 849416 ?

 

[Pasta]

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.

 

[qwizzie]

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.

Yep, makes sense now i think about it.

 

[qwizzie]

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 :

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

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

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

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.

 

[xkcd]

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.

 

[qwizzie]

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)

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 :

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.

 

[Pasta]

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.

 

[pshenmic]

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?

 

[strophy]

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.

 

[qwizzie]

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

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.

 

[qwizzie]

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.

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 ?

 

[qwizzie]

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 :

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.

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.