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

v13.0 Testing

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.
 
Win 7 x64 - v0.13.0.0-rc8
PS Info is still untranslated.
PSinfo.png
 
Win 7 x64 - v0.13.0.0-rc8
PS Info is still untranslated.
View attachment 9178
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 good enough? Or did you guys take a break until January for RC9?
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.
 
Can anyone send me 1000 coins please? yf7kAvZXd49hnWaScRbbLP9LMKDvz1f1tp
 
Last edited:
Anyone need some tDASH @qwizzie or anyone else, please @ me here or in Discord and post your testnet address and the amount you need, I will provide.
 
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.
 
UPDATE: The DIP3 BIP9 deployment has been activated, bringing us to stage 3./4./5./6.
Please start upgrading your existing MNs to DIP3 (using the new protx commands)
 
Should I do something or just wait?

"state": "WAITING_FOR_PROTX",
"status": "Waiting for ProTx to appear on-chain"
 
Should I do something or just wait?

"state": "WAITING_FOR_PROTX",
"status": "Waiting for ProTx to appear on-chain"
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
Note that because Trezor does not yet support Dash special transactions...
When fix?
Only use the automatic method if you are connected to your own Dash RPC client, or if you trust the operator of the node
I haz sad of trustz
...are maintained by the author of DMT, who has kindly offered to cover the transaction fees for the DIP3 upgrade.
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:
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'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?
 
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=
 
Back
Top