Dash Core v19.0.0 Release Candidate and Testnet HardFork

Pasta

Pasta

Active member
Dash Core Group
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
 
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.
 
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.
 
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!


1678096727844.png


So, let's get to testing this and see if we can't find any bugs.
 
  • Like
Reactions: kot
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


Knipsel.JPG


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.
 
Last edited:
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..
 
The -reindex attempt of mine got me stuck at block 848501
F.Y.I.

Knipsel.JPG


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
 
Last edited:
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.
 
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.
 
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


and this one is not fetching blocks at all :


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.

Knipsel.JPG
 
Last edited:
Pasta said:
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
Click to expand...

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 ?
 
Last edited:
Also, both HPMNs are PoSe banned atm, so neither should be getting rewards at this point; not sure when they got banned though
 
Pasta said:
Also, both HPMNs are PoSe banned atm, so neither should be getting rewards at this point; not sure when they got banned though
Click to expand...

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 ?
 
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!
 
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:23getblock 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
}
 
Regarding the HPMN payouts block 849413-849416 pay the HPMN, so all looks correct
 
Pasta said:
Regarding the HPMN payouts block 849413-849416 pay the HPMN, so all looks correct
Click to expand...

Knipsel.JPG


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 ?
 
Last edited:
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.
 
You must log in or register to reply here.
Back
Top