I could do this about as well as my dog could cook me dinner. There would be lots of broken dishes and probably a fire. I'm afraid the best I can offer here is moral support and gratitude. Buen provecho!Join in on the fun, @DAOMNI'm off to a dinner, but if you want to spin up a MN I'm sure we can all pitch in some t-dash
To start, first make sure you're not running your own full core wallet, if you are, wait for me
second, download the windows.zip file at the link on the first page and pull out dash-qt, put it somewhere easy to find.
You can start it up, then shut it down, and find your .dashcore folder in c:/Users/yourname/AppData/Roaming/DashCore and open dash.conf with notepad++ (right click and choose open with notepad++) This is a very useful tool, and based off windows notepad
Just add testnet=1 on the first line, then save, close, and restart the dash-qt wallet.
Now you have to wait an hour or three for it to sync, then we can have fun
v13.0 Testing
- Thread starter codablock
- Start date
Ah well, Dash is supposed to eventually make it easy enough for anyone to use, so you will be a perfect candidate when we get so far, to see if we did it right
RC8 has been published: https://github.com/dashpay/dash/releases/tag/v0.13.0.0-rc8
It contains a few crash fixes. Please upgrade ASAP. If you don't upgrade, your nodes will crash when we upgrade our miners.
It also contains changes to the "dummy DKG" which is used to test simple PoSe on testnet. If enough MNs have upgraded, you'll see more offline nodes getting punished.
It contains a few crash fixes. Please upgrade ASAP. If you don't upgrade, your nodes will crash when we upgrade our miners.
It also contains changes to the "dummy DKG" which is used to test simple PoSe on testnet. If enough MNs have upgraded, you'll see more offline nodes getting punished.
If it's any consolation, the testing work you are doing is greatly appreciated. Many people are counting on you!
They are probably doing it this way because of the intense pressure to get this release out the door ASAP. They are causing testers to bear more than is usual in an effort to conserve precious developer resources IMHO.
They are probably doing it this way because of the intense pressure to get this release out the door ASAP. They are causing testers to bear more than is usual in an effort to conserve precious developer resources IMHO.
@codablock
So now, the masternode status command gives this information:
[email protected]:~/dashcore-0.13.0/bin$ dash-cli masternode status
{
"outpoint": "e68611bb8bfa7ef3f65e8e3a880c5088b9766de0c892f9293bd808704fa75a3d-0",
"service": "64.193.62.206:19999",
"proTxHash": "ff2afab72cb68194cd0f01a136a9e061825b93fa4ddbb0d4edd0ee97ae7c96b7",
"collateralHash": "e68611bb8bfa7ef3f65e8e3a880c5088b9766de0c892f9293bd808704fa75a3d",
"collateralIndex": 0,
"dmnState": {
"registeredHeight": 270638,
"lastPaidHeight": 281245,
"PoSePenalty": 0,
"PoSeRevivedHeight": -1,
"PoSeBanHeight": -1,
"revocationReason": 0,
"keyIDOwner": "f1000b25efd4a04c55f4402d1f7a8383b416db56",
"pubKeyOperator": "086666b427134ccdbb43e1a14647f61c2047107498313558e378f6c440c4d752d213a6d0a52e4b3a17c5cc62ff5f539a",
"keyIDVoting": "f1000b25efd4a04c55f4402d1f7a8383b416db56",
"addr": "64.193.62.206:19999",
"payoutAddress": "yg8G647Sqg6xqh3z2XSv4ZFrXmueCTa8NV"
},
"state": "READY",
"status": "Ready"
So, does that mean enabled?
So now, the masternode status command gives this information:
[email protected]:~/dashcore-0.13.0/bin$ dash-cli masternode status
{
"outpoint": "e68611bb8bfa7ef3f65e8e3a880c5088b9766de0c892f9293bd808704fa75a3d-0",
"service": "64.193.62.206:19999",
"proTxHash": "ff2afab72cb68194cd0f01a136a9e061825b93fa4ddbb0d4edd0ee97ae7c96b7",
"collateralHash": "e68611bb8bfa7ef3f65e8e3a880c5088b9766de0c892f9293bd808704fa75a3d",
"collateralIndex": 0,
"dmnState": {
"registeredHeight": 270638,
"lastPaidHeight": 281245,
"PoSePenalty": 0,
"PoSeRevivedHeight": -1,
"PoSeBanHeight": -1,
"revocationReason": 0,
"keyIDOwner": "f1000b25efd4a04c55f4402d1f7a8383b416db56",
"pubKeyOperator": "086666b427134ccdbb43e1a14647f61c2047107498313558e378f6c440c4d752d213a6d0a52e4b3a17c5cc62ff5f539a",
"keyIDVoting": "f1000b25efd4a04c55f4402d1f7a8383b416db56",
"addr": "64.193.62.206:19999",
"payoutAddress": "yg8G647Sqg6xqh3z2XSv4ZFrXmueCTa8NV"
},
"state": "READY",
"status": "Ready"
So, does that mean enabled?
Ah, for a $5 VPS and a fistful of tDASH, you can screw up until you get it right. It's the cheapest education money can buy, and the more hard-headed you are, the better it works!
Service Guarantees Citizenship!
Check out @TaoOfSatoshi 's guides. Your head will spin at first, because it is all over the place and doesn't really explain much. It's just rote copycatting. But, the more you do it, the more it'll start to make sense. The more you screw up, the more you'll have to re-do it, the more you'll learn. And a few weeks later, you'll realize the whole guide can be compressed to one sentence... I was initially irritated with the guide, but it did lead people to learn. The very, very hard way, but I kinda like brutality...
Last edited:
Uh, that's the point... TESTnet.
This used to happen on mainnet, back in the day...
A complaining beta tester isn't a beta tester. Just beta...
The whole point is that it's currently busted.
I think the point was that the test releases should be labeled beta releases (e.g. beta 1, beta 2 etc) rather than release candidates (rc1, rc2 etc).
...they are release candidates, which are being tested, for release, maybe.
Anyway I'm not going any further off the rails with this, please follow suit.
The English version has some problems, too...
"...so they never know "who" you are."
Never use quotation marks for emphasis.
No emphasis needed.
I would go away from the word "anonymized" in favor of "privatized." It's more accurate, and we don't need to give the dirty guv ammo in our own words. Private and anonymous are not the same thing. Using them interchangeably and/or inaccurately yourself only invites others to continue the misuse.
RC8 is pretty stable atm. RC9 is in preparation and mostly contains fixes for miners. RC9 will also include a reset of testnet to block 4000+, which will allow us to re-test everything. We're currently preparing everything for this and will properly announce this later today, together with instructions.
UPDATE: We've reset testnet to block 4000 and have already spinned up about 60 MNs on the new testnet. The old testnet is still there and mining continues for some time to give integration partners more time to switch to the new testnet. However, the old testnet doesn't have enough MNs anymore, so features like InstantSend or governance are not working.
For everyone who wants to continue testing the v13 upgrade process, this is the new plan:
1. We downgrade all nodes (including MNs) to v0.12.3.4, which we released a few minutes ago. This version contains only changes for the testnet reset and is equivalent to v0.12.3.3 when used on mainnet. Upgrading on mainnet is not required! (DCG's MNs are already downgraded)
2. A few community members perform the same downgrade and spin up their MNs. Please note that these MNs have to be setup with the old way! This means, you have to use the old guides that currently apply for 0.12.3.x. As this is not a v13 release, none of the "protx" commands will work.
3. We test that everything is working as expected
4. We repeat the whole DIP3 deployment plan with all the stages described further below. This means that we start to upgrade nodes to v13 (RC9, which is not released yet)
Github release for v0.12.3.4: https://github.com/dashpay/dash/releases/tag/v0.12.3.4
To downgrade to this version, simply install the new version as usual and start it with "-reindex-chainstate", or alternatively start with a fresh datadir. You should also consider starting with a fresh wallet.dat as well, as all payments received so far will not be present in the new testnet. To connect to good nodes, invoke the RPC "addnode 18.202.52.170:19999", this should allow you to sync. When we update the dnsseeder, this step won't be required anymore.
Faucets are not updated yet, which leaves you with no funds for testing and running MNs. If you need 1000 tDash, please ping me in #testnet-lab or write a post with a tDash address here. Make sure to generate addresses with the new wallet which is on the correct chain.
Please ignore RCs for v13 until we give notice about RC9. This means, ignore the following lines until we release RC9. RC8 is incompatible to the new testnet and will be stuck when we stop mining for the old testnet.
For everyone who wants to continue testing the v13 upgrade process, this is the new plan:
1. We downgrade all nodes (including MNs) to v0.12.3.4, which we released a few minutes ago. This version contains only changes for the testnet reset and is equivalent to v0.12.3.3 when used on mainnet. Upgrading on mainnet is not required! (DCG's MNs are already downgraded)
2. A few community members perform the same downgrade and spin up their MNs. Please note that these MNs have to be setup with the old way! This means, you have to use the old guides that currently apply for 0.12.3.x. As this is not a v13 release, none of the "protx" commands will work.
3. We test that everything is working as expected
4. We repeat the whole DIP3 deployment plan with all the stages described further below. This means that we start to upgrade nodes to v13 (RC9, which is not released yet)
Github release for v0.12.3.4: https://github.com/dashpay/dash/releases/tag/v0.12.3.4
To downgrade to this version, simply install the new version as usual and start it with "-reindex-chainstate", or alternatively start with a fresh datadir. You should also consider starting with a fresh wallet.dat as well, as all payments received so far will not be present in the new testnet. To connect to good nodes, invoke the RPC "addnode 18.202.52.170:19999", this should allow you to sync. When we update the dnsseeder, this step won't be required anymore.
Faucets are not updated yet, which leaves you with no funds for testing and running MNs. If you need 1000 tDash, please ping me in #testnet-lab or write a post with a tDash address here. Make sure to generate addresses with the new wallet which is on the correct chain.
Please ignore RCs for v13 until we give notice about RC9. This means, ignore the following lines until we release RC9. RC8 is incompatible to the new testnet and will be stuck when we stop mining for the old testnet.
Crowdnode has some updated resources for the new 12.3.4 testnet
Explorer
http://insight.test.dash.crowdnode.io/
Faucet
http://faucet.test.dash.crowdnode.io/
Explorer
http://insight.test.dash.crowdnode.io/
Faucet
http://faucet.test.dash.crowdnode.io/
Testnet was succesfully downgraded to v0.12.3.4 and reset to block 4000 (we're already at 6582 now). All MN features have been tested and all looks good so far.
We have just published v0.13.0-RC9, which is also compatible to the new testnet. Please upgrade nodes to this RC and keep testing. This brings us to stage 1. and will eventually lead to stage 2. where miners start to signal DIP3 support.
It is NOT required to upgrade to protx MNs yet! Instead, perform an old-style upgrade to RC9 and issue the old-style "masternode start" commands.
We have just published v0.13.0-RC9, which is also compatible to the new testnet. Please upgrade nodes to this RC and keep testing. This brings us to stage 1. and will eventually lead to stage 2. where miners start to signal DIP3 support.
It is NOT required to upgrade to protx MNs yet! Instead, perform an old-style upgrade to RC9 and issue the old-style "masternode start" commands.
Check out the dash docs article https://docs.dash.org/en/latest/masternodes/dip3-upgrade.html?highlight=protx
Next, we will prepare an unsigned ProRegTx special transaction using the protx register_prepare command. This command has the following syntax:
protx register_prepare collateralHash collateralIndex ipAndPort ownerKeyAddr
operatorKeyAddr votingKeyAddr operatorReward payoutAddress
I updated my master nodes to the dip3 immediately after 13 RC9 was released. My masternode receive payments and is running fine since I upgraded to 13 rc9. am I correct in assuming that when we upgrade main at to 13 we can set it all up and let it go until sporks are activated?
https://docs.dash.org/en/latest/masternodes/dip3-upgrade.html#option-1-automatic-method
If not, could this be a feature-add? Seems like a quick copy-pasta from realm of sendtoaddress/true false true possible?
Failing this, MN Hosting Services cease to be private by means beyond their control. This forces unsafe use.
@moocowmoo
@UdjinM6
@Bertrand256
When fix?
I haz sad of trustz
OpSec point of interest: Can it be specified/forced that such fees are paid from PS balance of broadcasting daemon?
If not, could this be a feature-add? Seems like a quick copy-pasta from realm of sendtoaddress/true false true possible?
Failing this, MN Hosting Services cease to be private by means beyond their control. This forces unsafe use.
@moocowmoo
@UdjinM6
@Bertrand256
Last edited:
I've did that command before rc9 and MN was working just fine. But when update to rc9 I recive this message. Do I have to run proregtx again?
Well in that case you may need the protx hash and use protx update_service "proTxHash" "ipAndPort" "operatorKey" ("operatorPayoutAddress")
Make sure you edit dash.conf and add masternodeblsprivkey=