• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Dash Core v0.13.3 Released

Status
Not open for further replies.

tungfa

Well-known member
Foundation Member
Masternode Owner/Operator
Dash Community,

The team has released the Dash Core v0.13.3 update to fix some issues identified on SPV clients causing them to disconnect from nodes running Dash Core v0.13.2. Nodes running v0.13.2 were supplying invalid block information to SPV clients, causing the nodes to be banned. This update will resolve this issue.

We encourage all network operators to update to Dash Core v0.13.3. Upgrading a masternode now only involves replacing binaries and restarting the node — there is no need to use the “masternode start” command.

Please review the release notes for more details and additional features of this update.

https://github.com/dashpay/dash/releases/tag/v0.13.3.0
(dash.org is process of update)

QsR9X7W.png
 
Last edited by a moderator:
Is there a particular reason why the block mentioned in the "Next Payment" field in the windows Dash Core wallet (dip3 masternodes tab) changes with a few blocks over time and is not fixed on a specific block ?
It seems to decline with a few blocks over time. Is it because other dip3 masternodes get in PoSe banned status, so we move up a bit ? Or is it just part of how the deterministic selection process works ?
(keeping the next payment block fluid apparently, instead of fixed)

Also i created a new address today to function as my new voting address for Dash Central and got it registered on the blockchain using the ProUpRegTx command :

kUxV5GI.jpg


The "" that we can set so it uses the last on-chain value does not actually seems to work for all addresses in the ProUpregTx command (i get errors about incorrect address or something and need to provide full info).
In all cases (operatorkeyaddress / votingkeyaddress / payout address ) the "" seems to only point to the last on-chain operator key (see printscreen). Is that even correct ?
Why would we want to use the last on-chain operator key on our votingkey and payoutaddress ? :confused:
Cant we use the "" specifically for last on-chain voting key or last on-chain payout address ?

I tried to use "" on both operatorkeyaddress & payoutaddress, so it only updates my voting address and got the error it does not regnonice my payout address.
Frankly at this point i'm not even sure "" works as last on-chain operator key

Edit : I updated to v0.13.3 by the way, thank you for the update.
 
Last edited:
One of my masternodes (v0.13.3) just stopped working and i only found out due to me randomly checking Dashninja and finding a closed port on that masternode.
Putty indeed showed a not active server when i typed ./dash-cli getinfo

Now it gets weird, i could still login through WinSCP and find there a still active dashd PID.
Also i never received any push notification from Dash Central about this masternode misbehaving (no error, no warning, no nothing, status OK).
I'm running Monit on my masternode and it never got triggered into restarting that dashd.
PoSe Penalty of this masternode : 0
In the end i just did a ./dashd to get it running again and put Monit on the dash PID again, but i still find it weird.
This should not be related to a RAM issue (i'm running at 18% RAM usage + i also have a large backup memory / Vswap in place)

Debug Log :

2019-05-21 14:19:10 CGovernanceManager::SyncSingleObjAndItsVotes -- sent 1 object and 0 votes to peer=152263
2019-05-21 14:19:16 CInstantSend::CreateTxLockCandidate -- new, txid=6e2efe49bb691a713e84fc7b990070fe43da4425fd6508e8af863556b2f8e9d7
2019-05-21 14:19:16 CInstantSend::processTxLockRequest -- accepted, txid=6e2efe49bb691a713e84fc7b990070fe43da4425fd6508e8af863556b2f8e9d7
2019-05-21 14:19:16 TXLOCKREQUEST -- Transaction Lock Request accepted, txid=6e2efe49bb691a713e84fc7b990070fe43da4425fd6508e8af863556b2f8e9d7, peer=218278
2019-05-21 21:27:29
2019-05-21 21:27:29 Dash Core version v0.13.3.0
2019-05-21 21:27:29 InitParameterInteraction: parameter interaction: -masternode=1 -> setting -listen=1

This does not to me indicate a crashing dashd, just that Dash apparently stopped at 14:19:16 and restarted again due to my manual dashd restart command at 21:27:29
This does make it more difficult to monitor my masternodes, if they can crash without Dash Central giving any error or warning message.
I'm checking with Rango if his Dash Central warning system is working okay.

Positive thing about this all is that my masternode after 7 hours of not working (correctly), is still in payment que after having restarted it and the PoSe Penalty did not kick in yet and is still at 0.
(by the way, is that PoSe penalty working as intended ?)
 
Last edited:
Status
Not open for further replies.
Back
Top