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

v13.0 Testing

codablock

codablock

Active member
Release candidate v0.13.0.0-rc11 is ready for testnet! :)

Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.13.0.0-rc11
Release notes are not ready yet and will be prepared in the next few days. Post will be updated.
Gitian sigs can be found here: https://github.com/dashpay/gitian.sigs

DIP3 upgrade instructions: https://docs.dash.org/DIP3-masternode-upgrade

Before testing:
Make sure you made a backup of you mainnet datadir somewhere or at least a backup of wallet.dat/dash.conf/masternode.conf;
Or use the -datadir and -conf parameters to use completely different directories.

As this release deploys DIP2/3/4, we'll have to ensure all existing and new functionality works as expected in multiple stages of the deployment. The stages of the deployment are as follows:

0. Testnet is on the new 0.12.3.4 testnet. This is after the testnet reset to block 4000.
1. Full nodes, Masternodes and Miners upgrade their nodes to the latest release
2. Miners will start voting on the BIP9 deployment for DIP3, but only if they see enough MNs upgraded (this is automated)
3. After enough blocks with the proper BIP9 bits have been mined, DIP3 will activate but stay in "compatibility mode"
4. In this "compatibility mode", the existing non-deterministic masternodes should continue to work as expected
5. Now MNs can start registering their MNs as deterministic masternodes. Detailed instructions on how to do this will follow when the time arises.
6. Even the registered MNs will continue operating in the "compatibility mode" and will appear in "masternode list" as expected. InstantSend, PrivateSend, Governance, MN payment logic and so on should continue working as usual.
7. We will watch the progress of MNs upgrading to DIP3. When we see enough of these, we'll turn on spork15 (SPORK_15_DETERMINISTIC_MNS_ENABLED)
8. This is the point were all of us will be silent for a minute...as we say goodbye to all the non-deterministic masternodes. We'll see the output of "masternode list" immediately switch to the deterministic list (dropping all others). We'll also see the network go kind of silent, as all the bloat of masternode list synchronization disappears from the network...no more MNB, MNP, MNW, ... messages.

We are at stage 8. and I will update this line every time we move forward to the next stage.

We will have to perform full testing of all functionality in stages 1., 3. - 5. and 8. (so, 3 times in total). This includes:

What/how to test:
- Check if normal transactions are still working, perform some automated load testing if you want
- Check if creating and voting on proposals work. Also check if winning proposals get paid and other don't.
- There were improvements in PrivateSend, please test if mixing still works for you. It is very likely that mixing will not be working as expected in deployment stage 1. and 2.
- Check if InstantSend is still working (it might fail in the beginning as not enough MNs are available/upgraded atm)
- Starting with stage 3., test if automatic InstantSend locks for simple transactions are working as expected.
- Run a masternode or two, make sure it is paid. We're happy for everyone that also participates in the whole upgrade process from normal/old MNs to the deterministic MNs. Instructions on how to upgrade can be found here: https://docs.dash.org/DIP3-masternode-upgrade

What else you can do:
- Report serious issues (crashes/hangs/GUI glitches) : https://github.com/dashpay/dash/issues/new

Testnet tools (explorers, faucets, pools): https://www.dash.org/forum/threads/testnet-tools-resources.1768/

MNOs:
Wiki: https://docs.dash.org/en/stable/developers/testnet.html#masternodes
DIP3 upgrade instructions: https://docs.dash.org/DIP3-masternode-upgrade
Sentinel : https://github.com/dashpay/sentinel/tree/develop

DMT support for deterministic masternodes is currently still work-in-progress. Maybe @Bertrand256 can add some info/instructions when he is ready. Until then, users will have to manually sign the DIP3 messages with the collateral key on HW wallets. As said, detailed instructions will follow when we reach stage 5.

NOTE: Make sure you pulled Sentinel from `develop` branch and changed network to `testnet` in `sentinel.conf`. If you already have a mainnet masternode on the same server, do NOT run testnet masternode in the same datadir as your mainnet masternode (i.e. `.dashcore`). Create new folder specifically for testing (e.g. `.dashcore_test`) and make sure you use `-datadir=<yourtestnetdatadirhere>` cmd-line parameter for dashd and dash-cli. You'll also need a separate crontab line for testnet Sentinel. If you are not 100% sure what you are doing, I'd recommend setting up a new machine/instance for testing purposes only instead of reusing your mainnet server.
 
Last edited:
Do I understand correctly that there will be no support for masternodes using hardware wallets during this upgrade?

Meaning everyone who has a masternode running from a hardware wallet will need to switch back to the Dash Core wallet? Is hardware support for masternodes not covered by the Dash Core Group dev's? Seems like if bertrand isn't ready due to his schedule and you guys are that could force all MNO's to move back to a core wallet for securing their collateral?
 
coingun said:
Do I understand correctly that there will be no support for masternodes using hardware wallets during this upgrade?

Meaning everyone who has a masternode running from a hardware wallet will need to switch back to the Dash Core wallet? Is hardware support for masternodes not covered by the Dash Core Group dev's? Seems like if bertrand isn't ready due to his schedule and you guys are that could force all MNO's to move back to a core wallet for securing their collateral?
Click to expand...
To answer every your question specifically:

No.

No. No. No.

:D

In general, DIP3 was modified recently https://github.com/dashpay/dips/pull/21 and @codablock already implemented these changes in https://github.com/dashpay/dash/pull/2412 and https://github.com/dashpay/dash/pull/2427 exactly to keep HW wallets support and even allow reusing of existing collaterals. What @Bertrand256 can improve to make MNOs life a bit easier is he could add new fields in DMT to help MNOs generate commands to register their MNs as deterministic ones but this can be done manually too.
 
Yeah what I wrote about hardware wallet support was probably misleading, going to edit that. Also, please note that this is all for testnet where I assume most people don't use HW wallets (is that even supported on testnet?). For mainnet, we'll hopefully have the necessay DMT support to make life a bit easier.
 
Last edited:
What will the next version of Sentinel be? 1.3.0? I need to know for my test builds.
 
Thanks guys for your effort in supporting collaterals controlled by the hardware wallets in the DIP3 implementation.

codablock said:
DMT support for deterministic masternodes is currently still work-in-progress. Maybe @Bertrand256 can add some info/instructions when he is ready. Until then, users will have to manually sign the DIP3 messages with the collateral key on HW wallets. As said, detailed instructions will follow when we reach stage 5.
Click to expand...

I confirm that I am working on supporting the migration process of MNs to Deterministic MNs in Dash Masternode Tool, mainly to support less tech-savvy users. My goal is the simplest possible solution, but its final shape will be known after the tests in stage 4 and further.
 
t0dd said:
What will the next version of Sentinel be? 1.3.0? I need to know for my test builds.
Click to expand...

Likely, yes, but I'd recommend waiting for a release before you create a build. You should be able to use a mock version or you own for your test packages.
 
I usually put my dasd and dash-cli in usr/local/bin but it won't execute, and says no such file exists. I've changed permissions so it should execute, like I always do, but I keep getting the error that the file does not exist, though I can see it there?!

Can anyone think of why I can't execute this file? actual error:
dashd -daemon
-bash: /usr/local/bin/dashd: No such file or directory

So strange, I unzipped it again into my folder and tried executing it from the dashcore/bin folder, and it also shows as non-existant, though I see it. Ugh!

I'm on Ubuntu 64bit and am wondering if maybe the upload is problematic? I've downloaded twice..
 
Last edited:
TanteStefana said:
I usually put my dasd and dash-cli in usr/local/bin but it won't execute, and says no such file exists. I've changed permissions so it should execute, like I always do, but I keep getting the error that the file does not exist, though I can see it there?!

Can anyone think of why I can't execute this file? actual error:
dashd -daemon
-bash: /usr/local/bin/dashd: No such file or directory

So strange, I unzipped it again into my folder and tried executing it from the dashcore/bin folder, and it also shows as non-existant, though I see it. Ugh!

I'm on Ubuntu 64bit and am wondering if maybe the upload is problematic? I've downloaded twice..
Click to expand...
Maybe you're running a 32-bit binary on a 64-bit system.
https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found
 
In an older version of the road the following was said (https://github.com/dashpay/dash-roadmap/blob/master/README.md) :

Masternodes will scale and be tested using a system called ”state transitions.” This system will provide a mathematically predictable way of determining the quality of service that masternodes provide. Full access to the blockchain will be required to perform proper state transitions of user objects, which will reference governance objects and blockchain transactions to perform quorum operations. Masternodes which fall under a threshold of activity will automatically be removed from the masternode list using a new system called “masternode blocks.”

Do these new DIPS in any shape or form help towards that ? or are the counterproductive ?
I think this is an especially interesting topic seeing that during the live test quit a few MN's where running at 100% CPU just to keep up, meaning that the overall performance of things like block propagation, are not performed at (current) optimal efficiency, it will only get worst with larger blocks, and right now we are just talking about 2mb blocks. These MN's right now allowed to still get there rewards even do that have delivered sup par rewards.

My personal opinion is that we should not allowed this to happen, and we need to start differentiate from a coin like BCH as soon as possible, because testing of bigger and bigger blocks are just around the corner, sure let BCH drop there full nodes of in drones when it comes down to testing 32mb blocks, and the higher orphan-rate that will likely follow suit. Dash it's network should proof that we are indeed superior to altruistic nodes, this will certainly increase Dash it market proposition compared to our next competitor called BCH

Question
How is Dash progressing towards the goal that Masternodes, will need certain resource both in terms of hardware and bandwidth and if they fail to meet does requirements, they get completely kicked of the network or get a temp ban, and are pushed back in the line to receive part of the block-rewards.
 
Last edited:
Thank you @pwjjrn . It may be that my server is running Ubuntu 14.04 which is pretty old. I started to upgrade it today, but I just don't have the time to sit at the computer anymore. Life is getting in the way. I might just wipe it and reinstall fresh, then everything should work if it's working for others. I'm going to be late to this party unfortunately, but hopefully I will be able to see how to upgrade my nodes and avert issues when we go live! Thanks again

RE: what you said @The philosofers coin I'm not so worried about the masternodes being under powered, because they're likely to fall off the network and lose out on payments. I'm far more upset with mining pools not including any transactions in their blocks for the edge it gives them to find the next block. That is a real issue. I think we should have a way for MNs to tag miners who build empty blocks, using some kind of ratio. This would show malicious intent to not do their jobs. You can't get all the transactions floating around when building a block, but you should get something like 80% of them! This is an issue that must be addressed since fees are irrelevant, we've strayed from Satoshi's economic model there. If miners only have the block reward to look forward to, then there is no reason to include transactions in the block, and every reason not to (speed). Plus, if the miners are taking a month and a half or more to update to new versions, then I see them as hostile entities. If they don't want to do the job, we should just cut them off, and have a new adjustment algorithm that re-sets the difficulty based on the number of miners dropped from the network. It could be a secondary difficulty adjustment.

It isn't a matter of miners disagreeing with the code, and how things are being implemented, it's purely that we have given the system an incentive to cheat. We have created this situation because we want very low fees. That's fine, but then you have to bring enforcement into the system.
 
Last edited:
For your information, we reached stage 4. yesterday, which means we are in compatibility mode. There is already one DIP3 MN registered (I'm the first one, yeah :D)

Testnet was in a pretty bad state yesterday as the BIP9 deployment activated earlier then we hoped. One large miner was still mining on an old pool version and kept submitting blocks with invalid/missing MN payments. This caused a lot of trouble as the chain which was created by that miner still had a valid header chain, so all nodes tried to constantly reorg to that chain and failed doing so. This should be fixed now as the valid chain recently reached enough accumulated work. If your nodes still have issues, try to resync them.

Docs for upgrading to DIP3 MNs are in progress and we'll post a link when these are done.
 
TanteStefana said:
Thank you @pwjjrn . It may be that my server is running Ubuntu 14.04 which is pretty old. I started to upgrade it today, but I just don't have the time to sit at the computer anymore. Life is getting in the way. I might just wipe it and reinstall fresh, then everything should work if it's working for others. I'm going to be late to this party unfortunately, but hopefully I will be able to see how to upgrade my nodes and avert issues when we go live! Thanks again

RE: what you said @The philosofers coin I'm not so worried about the masternodes being under powered, because they're likely to fall off the network and lose out on payments. I'm far more upset with mining pools not including any transactions in their blocks for the edge it gives them to find the next block. That is a real issue. I think we should have a way for MNs to tag miners who build empty blocks, using some kind of ratio. This would show malicious intent to not do their jobs. You can't get all the transactions floating around when building a block, but you should get something like 80% of them! This is an issue that must be addressed since fees are irrelevant, we've strayed from Satoshi's economic model there. If miners only have the block reward to look forward to, then there is no reason to include transactions in the block, and every reason not to (speed). Plus, if the miners are taking a month and a half or more to update to new versions, then I see them as hostile entities. If they don't want to do the job, we should just cut them off, and have a new adjustment algorithm that re-sets the difficulty based on the number of miners dropped from the network. It could be a secondary difficulty adjustment.

It isn't a matter of miners disagreeing with the code, and how things are being implemented, it's purely that we have given the system an incentive to cheat. We have created this situation because we want very low fees. That's fine, but then you have to bring enforcement into the system.
Click to expand...

I'm also worried about malicious miners / pools only mining empty blocks, possibly causing a disruption in processing transactions (depending how much hashrate that miner / pool has). If you look at what is happening at Bitcoin Cash / SharkPool, i think Dash should take steps to make sure hash wars can not threaten
the Dash network like that in the future. I also agree with you that we should have a more strict policy with (lazy) miners that update their software version very late.
 
Last edited:
Can we reduce discussion in this thread to v13/testnet related stuff? If you want answers for your questions, I'd suggest to ask in Discord or make a fresh forum post (ping me as I'm not watching new threads)

Back to v13 :)
@strophy and @thephez just finished the first version of the DIP3 upgrade instructions: https://docs.dash.org/en/latest/masternodes/maintenance.html#dash-0-13-upgrade-procedure
You can now start registering your MNs.

When enough MNs are registered and all functionality has been confirmed to work in this stage, we'll activate spork15.
 
You must log in or register to reply here.
Back
Top