v12.3 Testing

codablock · Jun 2, 2018

Hello everyone,

UPDATE: 0.12.3.0-rc5 has been uploaded to Github:
https://github.com/dashpay/dash/releases/tag/v0.12.3.0-rc5
I've also updated the links in this post.

Please upgrade to the new version and issue mn-start on your masternodes.

RC5 should fix the forking issues currently seen on testnet.

Detailed changes: https://github.com/dashpay/dash/compare/v0.12.3.0-rc4...v0.12.3.0-rc5

-------

After a lot of unfortunate things happening one after another and getting into our way of releasing 12.3, we are finally at a point were we can go to public testing on testnet. For this, we created a 12.3 release candidate (v0.12.3.0-rc2) which can now be downloaded from the Github release page.

Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.12.3.0-rc5
Release notes can be found here: https://github.com/dashpay/dash/blob/v0.12.3.0-rc5/doc/release-notes.md

One of the efforts we did in the last days was to fix and re-establish Gitian building and signing. This is not fully done yet, as there seems to be some non-determinism when the final windows setup.exe is built. We will investigate/fix this in the future. The actual binaries however (which are inside the setup.exe) match between Gitian builds and are signed as well. Gitian sigs can be found here: https://github.com/dashpay/gitian.sigs

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.

What/how to test:
- Check if normal transactions are still working, perform some automated load testing if you want
- There were improvements in the governance system, please create a few proposals and check if everything looks correct and that you get proper payouts (or no payouts when votes are missing). Make a note in this thread if you need votes for a proposal.
- There were improvements in PrivateSend, please test if mixing still works for you
- Check if InstantSend is still working (it might fail in the beginning as not enough MNs are available/upgraded atm)
- Run a masternode or two, make sure it is paid;
- Generally, this release does not include so many new things, but instead includes a large list of improvements, refactorings and bug fixes. So the testing should ensure that everything old still works as expected.

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/
NOTE: Most faucets were dry recently, but a few devs now started to automatically fund these faucets. At the moment, at least http://test.faucet.masternode.io/ should have enough tDASH for everyone.

MNOs:
Wiki: https://dashpay.atlassian.net/wiki/spaces/DOC/pages/118162190/Masternodes+under+testnet
Sentinel : https://github.com/dashpay/sentinel/tree/develop

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.

We're very sorry for the delay, and we'll try to change a few things so this doesn't happen again. For example, we'll now distribute knowledge/experience about the release process a little bit more. This is one of the reasons you see me instead of @UdjinM6 doing this post now (another reason is that his internet connection is horribly limited since a few days/weeks). Another thing we did now is to remove the dependency on Bamboo for doing releases. It has gone down a few weeks ago and left us in a state were we could not do a proper Gitian release anymore...add this together with missing time of multiple team members, missing experience in the release process, bad internet connections, ASICs on testnet (which shouldn't be a problem anymore after a few fixes we did) and you get the perfect mix of circumstances to get to the delay we got. We learned a few things about our weak spots here, let's try to fix them.

TanteStefana · Jun 3, 2018

Can you give us an IP address? My wallet isn't finding a chain

` no peers to connect to? should we put devnet=??? in the dash.conf file?

OK, for some reason my wallet just wouldn't find a peer. If you're having this problem, thephez just had me put the following in the console and it started to sync:

addnode 108.61.192.47 add

And suddenly I have 8 peers

I started from scratch, and just in case this helps locate an issue, here is a snippet from the debug log:

2018-06-03 02:06:32 CMasternodeSync:: processTick -- nTick 1 nRequestedMasternodeAssets 0 nRequestedMasternodeAttempt 0 nSyncProgress -0.250000 2018-06-03 02:06:36 38 addresses found from DNS seeds 2018-06-03 02:06:36 dnsseed thread exit

drkrooster · Jun 3, 2018

finally!
don't worry, appreciate you and the team sharing and hard work.
those challenges and difficulties experience will turn into our strength going forward!
well done! team

akhavr · Jun 3, 2018

Trying to sync testnet blockchain. Seems to work this time.

AjM · Jun 3, 2018

codablock said:
Hello everyone,

After a lot of unfortunate things happening one after another and getting into our way of releasing 12.3, we are finally at a point were we can go to public testing on testnet. For this, we created a 12.3 release candidate (v0.12.3.0-rc2) which can now be downloaded from the Github release page.

Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.12.3.0-rc2
Release notes can be found here: https://github.com/dashpay/dash/blob/v0.12.3.0-rc2/doc/release-notes.md

One of the efforts we did in the last days was to fix and re-establish Gitian building and signing. This is not fully done yet, as there seems to be some non-determinism when the final windows setup.exe is built. We will investigate/fix this in the future. The actual binaries however (which are inside the setup.exe) match between Gitian builds and are signed as well. Gitian sigs can be found here: https://github.com/dashpay/gitian.sigs

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.

What/how to test:
- Check if normal transactions are still working, perform some automated load testing if you want
- There were improvements in the governance system, please create a few proposals and check if everything looks correct and that you get proper payouts (or no payouts when votes are missing). Make a note in this thread if you need votes for a proposal.
- There were improvements in PrivateSend, please test if mixing still works for you
- Check if InstantSend is still working (it might fail in the beginning as not enough MNs are available/upgraded atm)
- Run a masternode or two, make sure it is paid;
- Generally, this release does not include so many new things, but instead includes a large list of improvements, refactorings and bug fixes. So the testing should ensure that everything old still works as expected.

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/
NOTE: Most faucets were dry recently, but a few devs now started to automatically fund these faucets. At the moment, at least http://test.faucet.masternode.io/ should have enough tDASH for everyone.

MNOs:
Wiki: https://dashpay.atlassian.net/wiki/spaces/DOC/pages/118162190/Masternodes+under+testnet
Sentinel : https://github.com/dashpay/sentinel/tree/develop

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.

We're very sorry for the delay, and we'll try to change a few things so this doesn't happen again. For example, we'll now distribute knowledge/experience about the release process a little bit more. This is one of the reasons you see me instead of @UdjinM6 doing this post now (another reason is that his internet connection is horribly limited since a few days/weeks). Another thing we did now is to remove the dependency on Bamboo for doing releases. It has gone down a few weeks ago and left us in a state were we could not do a proper Gitian release anymore...add this together with missing time of multiple team members, missing experience in the release process, bad internet connections, ASICs on testnet (which shouldn't be a problem anymore after a few fixes we did) and you get the perfect mix of circumstances to get to the delay we got. We learned a few things about our weak spots here, let's try to fix them.

Win7 64bit - Dash Core v0.12.3.0-rc2

@codablock what is that 3 seconds count down in the sending dialog OK button?
It does not do anything, seems.

And command-line options blockreconstructionextratxn info is not translated.

-blockreconstructionextratxn=<n>
Extra transactions to keep in memory for compact block reconstructions (default: 100)

GNULinuxGuy · Jun 3, 2018

Updated my dedicated tMN. Looking good so far! Very exciting! Will continue to bring more testnet nodes online and do additional tests as I have time.

codablock · Jun 4, 2018

TanteStefana said:
Can you give us an IP address? My wallet isn't finding a chain ` no peers to connect to? should we put devnet=??? in the dash.conf file?

OK, for some reason my wallet just wouldn't find a peer. If you're having this problem, thephez just had me put the following in the console and it started to sync:

addnode 108.61.192.47 add

And suddenly I have 8 peers

Do I understand you correct that everything is ok now?

AjM said:
And command-line options blockreconstructionextratxn info is not translated.

This is most likely because translations were already done and imported/merged before these features were merged. I would consider this a minor problem and assume that we're going to fix it with one of the future translation imports.

AjM · Jun 4, 2018

codablock said:
This is most likely because translations were already done and imported/merged before these features were merged. I would consider this a minor problem and assume that we're going to fix it with one of the future translation imports.

@codablock Ok, and that OK button 3 sec count down?

codablock · Jun 4, 2018

AjM said:
@codablock Ok, and that OK button 3 sec count down?

That's from the Bitcoin backports and acts as a protection against trigger fingers. It kind of forces you to double check your TX or at least think 3 more seconds. I personally find it ok this way...never forget, in Crypto there is no "reverse my erroneous transaction"

AjM · Jun 4, 2018

codablock said:
That's from the Bitcoin backports and acts as a protection against trigger fingers. It kind of forces you to double check your TX or at least think 3 more seconds. I personally find it ok this way...never forget, in Crypto there is no "reverse my erroneous transaction"

So, ok button does not work on first 3 seconds, thats ok.

lxklyga · Jun 4, 2018

Please help! 12.3 linux ver doesn't synchronous the block! Have you ever been in such siuation!

lxklyga · Jun 4, 2018

12.3 windows ver everthing is ok!! synchrnousing the block,transactions,receives!!all of it are ok

akhavr · Jun 4, 2018

Testnet synchronization stuck again:

Code:

  "blocks": 99743,

What I'm doing wrong?

codablock · Jun 4, 2018

Sync issue might happen if you got unlucky and your first connection was to a node which has forked away. These are most likely non-upgraded nodes which still run 12.2.x, which does not include the fixes we did after the ASICs were turned on on testnet.
To fix it, disconnect the first node you see in the peers list in the debug window. To get to it, click on the "connections" icon on the bottom right.

akhavr · Jun 4, 2018

Well, I've banned all non-/Dash Core:0.12.3/ nodes connections. Still stuck at block 99743. (Linux, command line)

codablock · Jun 4, 2018

akhavr said:
Well, I've banned all non-/Dash Core:0.12.3/ nodes connections. Still stuck at block 99743. (Linux, command line)

What does "Starting Block" of the first node that you're connected to say? And maybe the nodes after the first one?

InhumanPerfection · Jun 4, 2018

I'm running 3 nodes
1) On all 3 nodes mixing of 10.0001 denomination doesn't work. Message in log "CPrivateSendClient::JoinExistingQueue -- Couldn't match 0 denominations 0 1 (10.0001)". And as I can see nobody can mix 10.0001. Other denominations - ok.

2) This appears in log on all 3 nodes (on 1 rarely, on other 2 very common):

2018-06-04 16:43:59 ProcessMessages(dsq, 115 bytes): Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
2018-06-04 16:43:59 ProcessMessages(dsq, 115 bytes) FAILED peer=37

Caught nodes who send these dsq (all 12.3): 108.61.199.31:19999, 104.207.147.135:19999, 217.61.221.9:19999 (I caught these 3 nodes at the moment of writing - can be more, idk...)

3) This appears in log on 2 nodes:

2018-06-04 16:44:19 DSQUEUE -- nDenom=1, nInputCount=0, nTime=1528130658, fReady=false, fTried=false, masternode=fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec16e4dd3f-0 new
2018-06-04 16:44:19 DSQUEUE -- nLastDsq: 5020 threshold: 5049 nDsqCount: 5066
2018-06-04 16:44:19 DSQUEUE -- new PrivateSend queue (nDenom=1, nInputCount=0, nTime=1528130658, fReady=false, fTried=false, masternode=fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec16e4dd3f-0) from masternode 18.237.240.73:19029
2018-06-04 16:44:19 DSQUEUE -- nDenom=1, nInputCount=384097599, nTime=-4027553973496971264, fReady=true, fTried=false, masternode=00000000fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec-1528130658 new
2018-06-04 16:44:19 DSQUEUE -- nDenom=1, nInputCount=384097599, nTime=-4027553973496971264, fReady=true, fTried=false, masternode=00000000fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec-1528130658 new
2018-06-04 16:44:19 DSQUEUE -- nDenom=1, nInputCount=384097599, nTime=-4027553973496971264, fReady=true, fTried=false, masternode=00000000fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec-1528130658 new

2018-06-04 16:49:57 DSQUEUE -- nDenom=1, nInputCount=0, nTime=1528130997, fReady=false, fTried=false, masternode=46d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a35452292-0 new
2018-06-04 16:49:57 DSQUEUE -- nLastDsq: 4829 threshold: 4858 nDsqCount: 5085
2018-06-04 16:49:57 DSQUEUE -- new PrivateSend queue (nDenom=1, nInputCount=0, nTime=1528130997, fReady=false, fTried=false, masternode=46d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a35452292-0) from masternode 18.237.240.73:19057
2018-06-04 16:49:57 DSQUEUE -- nDenom=1, nInputCount=893723282, nTime=1304707985309696000, fReady=true, fTried=false, masternode=0000000046d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a-1528130997 new
2018-06-04 16:49:57 DSQUEUE -- nDenom=1, nInputCount=893723282, nTime=1304707985309696000, fReady=true, fTried=false, masternode=0000000046d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a-1528130997 new
2018-06-04 16:49:57 DSQUEUE -- nDenom=1, nInputCount=893723282, nTime=1304707985309696000, fReady=true, fTried=false, masternode=0000000046d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a-1528130997 new

2018-06-04 16:53:48 DSQUEUE -- nDenom=4, nInputCount=0, nTime=1528131228, fReady=false, fTried=false, masternode=d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6761c99ab-1 new
2018-06-04 16:53:48 DSQUEUE -- nLastDsq: 5052 threshold: 5081 nDsqCount: 5099
2018-06-04 16:53:48 DSQUEUE -- new PrivateSend queue (nDenom=4, nInputCount=0, nTime=1528131228, fReady=false, fTried=false, masternode=d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6761c99ab-1) from masternode 145.239.235.24:39999
2018-06-04 16:53:48 DSQUEUE -- nDenom=4, nInputCount=1981585835, nTime=-8711016110985576448, fReady=true, fTried=false, masternode=00000001d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6-1528131228 new
2018-06-04 16:53:48 DSQUEUE -- nDenom=4, nInputCount=1981585835, nTime=-8711016110985576448, fReady=true, fTried=false, masternode=00000001d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6-1528131228 new
2018-06-04 16:53:48 DSQUEUE -- nDenom=4, nInputCount=1981585835, nTime=-8711016110985576448, fReady=true, fTried=false, masternode=00000001d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6-1528131228 new

In corrupted messages:
- in nInputCount - last 32bits of masternode txid
- in masternode index - last 32bits of nTime
and so on.
Clearly there is no nInputCount field in the dsq message and other fields are moved

UdjinM6 · Jun 4, 2018

InhumanPerfection said:
I'm running 3 nodes
1) On all 3 nodes mixing of 10.0001 denomination doesn't work. Message in log "CPrivateSendClient::JoinExistingQueue -- Couldn't match 0 denominations 0 1 (10.0001)". And as I can see nobody can mix 10.0001. Other denominations - ok.

2) This appears in log on all 3 nodes (on 1 rarely, on other 2 very common):

Caught nodes who send these dsq (all 12.3): 108.61.199.31:19999, 104.207.147.135:19999, 217.61.221.9:19999 (I caught these 3 nodes at the moment of writing - can be more, idk...)

3) This appears in log on 2 nodes:

In corrupted messages:
- in nInputCount - last 32bits of masternode txid
- in masternode index - last 32bits of nTime
and so on.
Clearly there is no nInputCount field in the dsq message and other fields are moved

That is most likely related to the fact that we are having slightly different 12.3/70209 nodes on the testnet, should fix itself once more people/nodes are upgraded.

akhavr · Jun 5, 2018

codablock said:
What does "Starting Block" of the first node that you're connected to say? And maybe the nodes after the first one?

So far, the only 0.12.3 node, I'm connected to, has just 46229 blocks:

Code:

'version', 'subver', 'startingheight'
[(70208, u'/Dash Core:0.12.2.3/', 135647),
 (70208, u'/Dash Core:0.12.2/', 101855),
 (70208, u'/Dash Core:0.12.2.3/', 135647),
 (70209, u'/Dash Core:0.12.3/', 46229),
 (70208, u'/Dash Core:0.12.2.2/', 102503),
 (70208, u'/Dash Core:0.12.2.3/', 136235)]

AjM · Jun 5, 2018

akhavr said:

So far, the only 0.12.3 node, I'm connected to, has just 46229 blocks:

Code:

'version', 'subver', 'startingheight'
[(70208, u'/Dash Core:0.12.2.3/', 135647),
 (70208, u'/Dash Core:0.12.2/', 101855),
 (70208, u'/Dash Core:0.12.2.3/', 135647),
 (70209, u'/Dash Core:0.12.3/', 46229),
 (70208, u'/Dash Core:0.12.2.2/', 102503),
 (70208, u'/Dash Core:0.12.2.3/', 136235)]

Doesnt that startingheight mean that the blocks start from there?

v12.3 Testing

Active member

Well-known member

Member

Well-known member

Well-known member

Active member

Active member

Well-known member

Active member

Well-known member

New member

New member

Well-known member

Active member

Well-known member

Active member

Member

Official Dash Dev

Well-known member

Well-known member