v13.0 Testing

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
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:

coingun

Active Member
Masternode Owner/Operator
Jul 8, 2014
489
402
133
masternode.io
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?
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,638
3,538
1,183
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?
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.
 

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
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:

t0dd

Active Member
Mar 21, 2016
150
132
103
keybase.io
Dash Address
XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
What will the next version of Sentinel be? 1.3.0? I need to know for my test builds.
 

Bertrand256

Active Member
Feb 13, 2017
228
272
123
Dash Address
XwZzf7yqYoUBnDFqE7r3zuNmpwKo1CYLMC
Thanks guys for your effort in supporting collaterals controlled by the hardware wallets in the DIP3 implementation.

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.
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.
 

nmarley

Active Member
Jun 28, 2014
366
424
133
What will the next version of Sentinel be? 1.3.0? I need to know for my test builds.
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.
 

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,861
1,854
1,283
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:

pwjjrn

New Member
Jul 10, 2017
33
8
8
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..
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
 
Apr 23, 2017
66
26
58
34
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:

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,861
1,854
1,283
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:

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
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.
 

qwizzie

Well-known Member
Aug 6, 2014
1,557
729
183
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.
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:

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
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.
 

qwizzie

Well-known Member
Aug 6, 2014
1,557
729
183
v0.13.0.0-rc2 (Windows 10, 64 bit)

There are a few problems with the dutch translation in this version, both with the layout (not all text readable) and the translation into Dutch :

Tools --> Peers list / Hulpmiddelen --> Peers lijst



Peers (Tab)
$Peers --> Peers

Portemonnee Herstel (Tab)

Click buttons

Gerede portemonnee --> Herstel portemonnee
Herstelde transacties 1 --> Herstel transacties 1
Herstelde transacties 2 --> Herstel transacties 2
Upgrade portemonnee formaat --> Upgrade portemonnee
Herbouw de index --> Herbouw index

Click buttons description

-red portemonnee: Poging om geheime sleutels terug te halen uit het beschadigede portemonnee bestand (wallet.dat)
fix : -herstel portemonnee: Poging om geheime sleutels terug te halen uit het beschadigde portemonnee bestand (wallet.dat)

-zapwallettxes=1: Herstelde transacties van de blokketen (behoud metadata;bv.accounteigenaar)
fix : -zapwallettxes=1: Herstel transacties van de blokketen (behoud metadata;bv.accounteigenaar)

-zapwallettxed=2: Herstelde transacties van de blokketen (laat metadata vervallen)
fix : -zapwallettxes=2: Herstel transacties van de blokketen (laat metadata vervallen)

-upgrade portemonnee= Upgrade portemonnee naar het laatste formaat bij het starten: (Noot: dit is GEEN update van de portemonnee zelf)
fix : -upgrade portemonnee= Upgrade portemonnee naar het laatste formaat bij het starten: (Let op: dit is GEEN update van de portemonnee zelf)


Edit 1: is there a specific reason why we disabled/overruled listen=0 as commandline option for dash-qt.exe on Testnet ? (i can understand disabling it for Mainnet but for Testnet it can be handy running several dash-qt.exe at the same time .. specially for testing mixing and instantsend.

Edit 2 : only http://faucet.test.dash.crowdnode.io/ seems to work at the moment, providing a small test amount (51.5 tDash). The rest is either dry or we cant connect to it.

Edit 3 : PrivateSend messages during mixing look a bit crowded and get cut off :



Edit 4 : PrivateSend transactions dont seem to get confirmed in order of age for now, it seems more irregular :

 
Last edited:

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,335
571
283
Finland
v0.13.0.0-rc2 (Windows 10, 64 bit)

Some Finnish strings untranslated (missing dash_en.ts string or other glitch).
I think these are also untranslated with other languages.

-----------------------------

- Transactions tab -> Transaction details -> Transaction total size: -> bytes

- Settings -> Options -> Wallet -> Show popups for privatesend transactions

- Settings -> Encrypt Wallet -> Cancel and next window -> Yes and Cancel

- Settings -> Change passphrase - Cancel

- Settings -> Unlock wallet -> Cancel

- Receive tab -> Request payment -> Close

- Help -> Commandline options -> -minsporkkeys=<n> ->
Overrides minimum spork signers to change spork value. Only useful for regtest and devnet. Using this on mainnet or testnet will ban you.

- Help -> Commandline options -> -privatesendsessions=<n> ->
Use N separate masternodes in parallel to mix funds (1-10, default: 4)

- Help -> Privatesend information -> ALL

- Help -> About QT -> ALL

-----------------------------
 

Technologov

Member
Mar 5, 2017
160
36
88
36
Israel
Hello, while working on v13 "Evolution", can you please revisit my idea of new address type for Dash Insta-Send, as described here ?
https://github.com/dashpay/dash/issues/1559

"Assume a retail merchant wants to accept ONLY InstantSend transactions.
Today there is no way to make it happen. A retailer accepting Dash may get a normal transaction, and get double-spend attacked. This technique will improve zero-confirmation security from the retailer point of view.
I would like to propose a new Dash address type (starting with "IX..." or "D..."), which will only accept InstantSend transaction types. (but allow to spend/outgoing to any address)"
 

qwizzie

Well-known Member
Aug 6, 2014
1,557
729
183
Which explorer is actually working correctly and is up to date ? I tested them all and none matches my current block 264575 (which seems stuck)

Is this one correct ? https://testnet-insight.dashevo.org/insight/

Edit 1 : i'm doing a reindex, see if that helps.
Edit 2: my wallet is now synced to https://testnet-insight.dashevo.org/insight/ but i have still transactions not getting confirmed, even after having zapwallettxes them from within the wallet
(recover transactions 1 & recover transactions 2). These transactions get republished with a new date to the blockchain, but they are not getting confirmed.
They seem to be stuck in mempool or something.

Update : after 1 hour my transactions started to get confirmed. I think i will hold off with further mixing untill mining gets more fluid.
 
Last edited:

strophy

Administrator
Dash Core Team
Moderator
Dash Support Group
Feb 13, 2016
710
408
133
v0.13.0.0-rc2 (Windows 10, 64 bit)
There are a few problems with the dutch translation in this version, both with the layout (not all text readable) and the translation into Dutch :

Edit 3 : PrivateSend messages during mixing look a bit crowded and get cut off :
Hi @qwizzie - thanks for your language improvement suggestions, I have submitted these for review to our maintainer for Dutch.

The issues with cut off text you are seeing are due to improper scaling on a High-DPI ("retina") screen when using Windows. Unfortunately some widgets still use absolute pixel sizes, while Windows is attempting to scale your fonts 200%. You can correct this by closing Dash, then right-clicking on dash-qt.exe and selecting Properties > Compatibility > Change high DPI settings > Override high DPI scaling performed by > System. The scaling behaviour should be corrected when you restart Dash.

v0.13.0.0-rc2 (Windows 10, 64 bit)
Some Finnish strings untranslated (missing dash_en.ts string or other glitch).
I think these are also untranslated with other languages.
Hi @AjM - thanks for the Finnish translations you contributed last week. I can confirm that many of the strings you have reported are indeed not present in the version of dash_en.ts currently on Transifex. I'll let @UdjinM6 reply about the status of that file and the strings it contains. The "PrivateSend information" dialog seems to be fully translated in Finnish on Transifex, so either this was done after the translation was pulled from Transifex, or there was a syntax error that is causing it not to build. The "About Qt" dialog is probably built from language in the Qt library itself and cannot be translated by us.
 
  • Like
Reactions: qwizzie

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,335
571
283
Finland
Hi @AjM - thanks for the Finnish translations you contributed last week. I can confirm that many of the strings you have reported are indeed not present in the version of dash_en.ts currently on Transifex. I'll let @UdjinM6 reply about the status of that file and the strings it contains. The "PrivateSend information" dialog seems to be fully translated in Finnish on Transifex, so either this was done after the translation was pulled from Transifex, or there was a syntax error that is causing it not to build. The "About Qt" dialog is probably built from language in the Qt library itself and cannot be translated by us.
Hi @strophy , "PrivateSend information" is translated from the beginning, i checked my translation and there was little 'glitch', but this is working ok v.0.12.3.3.
@UdjinM6 reported last year that "About QT" translation was working in his local build. https://github.com/dashpay/dash/issues/1661

EDIT: "About QT" is working ok in the linux (Mint 18.3), maybe this problem is somehow related that my windows is in virtualbox and language is english.

EDIT 2: v0.13.0.0-rc3 "PrivateSend information" glitch pic attached.
psinfo.png
 
Last edited:

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
v0.13.0.0-rc3 has just been released. Please upgrade. To see if you're on the correct chain, call "getblockhash 264978" and verify that it returns "
00000000100625f33be83bc1cebe4087ebf521c5ddd860c3304ea73967473e2c". If it doesn't, try "reconsiderblock 00000000100625f33be83bc1cebe4087ebf521c5ddd860c3304ea73967473e2c"
 

qwizzie

Well-known Member
Aug 6, 2014
1,557
729
183
v0.13.0.0-rc2

I had a problem using UdjinM6's bootstrap to sync to block 264784, the syncing would not complete.

https://github.com/UdjinM6/dash-bootstrap#for-testnet

For testnet:
Block 264784: Thu Nov 15 00:16:41 UTC 2018 zip (1.9G) SHA256

I suspect this bootstrap snapshot is not useable for current testnet.
I went back to deleting blockchain and syncing from scratch.

Problem : Dash hangs during syncing (syncing headers 93.1% and then stops)

2018-11-15 08:02:53 CMasternodeSync:processTick -- nTick 191 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:02:59 CMasternodeSync:processTick -- nTick 192 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:05 CMasternodeSync:processTick -- nTick 193 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:11 CMasternodeSync:processTick -- nTick 194 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:17 CMasternodeSync:processTick -- nTick 195 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:23 CMasternodeSync:processTick -- nTick 196 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:29 CMasternodeSync:processTick -- nTick 197 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:35 CMasternodeSync:processTick -- nTick 198 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:41 CMasternodeSync:processTick -- nTick 199 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:47 CMasternodeSync:processTick -- nTick 200 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:53 CMasternodeSync:processTick -- nTick 201 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:53 CMasternodeSync:processTick -- nTick 201 nCurrentAsset 0 -- requesting sporks from peer=0
2018-11-15 08:03:53 CMasternodeSync:processTick -- nTick 201 nCurrentAsset 0 -- requesting sporks from peer=2
2018-11-15 08:03:53 CMasternodeSync:processTick -- nTick 201 nCurrentAsset 0 -- requesting sporks from peer=3
2018-11-15 08:03:53 CMasternodeSync:processTick -- nTick 201 nCurrentAsset 0 -- requesting sporks from peer=4
2018-11-15 08:03:59 CMasternodeSync:processTick -- nTick 202 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:03:59 CMasternodeSync:processTick -- nTick 202 nCurrentAsset 0 -- requesting sporks from peer=6
2018-11-15 08:03:59 CMasternodeSync:processTick -- nTick 202 nCurrentAsset 0 -- requesting sporks from peer=7
2018-11-15 08:04:05 CMasternodeSync:processTick -- nTick 203 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:04:11 CMasternodeSync:processTick -- nTick 204 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 08:04:11 CMasternodeSync:processTick -- nTick 204 nCurrentAsset 0 -- requesting sporks from peer=8
2018-11-15 08:04:17 CMasternodeSync:processTick -- nTick 205 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000

I will update to new version 0.13.0.0-rc3 and see if that helps with syncing.

v0.13.0.0-rc3

Update 1: that seems to have helped, i'm fully syncing now.

Update 2 : stuck at block 263798 (nov 13 2018), 46 hours behind. Syncing headers 99.6%

2018-11-15 09:02:14 CMasternodeSync::processTick -- nTick 499 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:02:20 CMasternodeSync::processTick -- nTick 500 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:02:26 CMasternodeSync::processTick -- nTick 501 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:02:26 CMasternodeSync::processTick -- nTick 501 nCurrentAsset 0 -- requesting sporks from peer=2
2018-11-15 09:02:26 CMasternodeSync::processTick -- nTick 501 nCurrentAsset 0 -- requesting sporks from peer=10
2018-11-15 09:02:32 CMasternodeSync::processTick -- nTick 502 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:02:32 CMasternodeSync::processTick -- nTick 502 nCurrentAsset 0 -- requesting sporks from peer=3
2018-11-15 09:02:32 CMasternodeSync::processTick -- nTick 502 nCurrentAsset 0 -- requesting sporks from peer=4
2018-11-15 09:02:38 CMasternodeSync::processTick -- nTick 503 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:02:38 CMasternodeSync::processTick -- nTick 503 nCurrentAsset 0 -- requesting sporks from peer=5
2018-11-15 09:02:38 CMasternodeSync::processTick -- nTick 503 nCurrentAsset 0 -- requesting sporks from peer=6
2018-11-15 09:02:44 CMasternodeSync::processTick -- nTick 504 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:02:44 CMasternodeSync::processTick -- nTick 504 nCurrentAsset 0 -- requesting sporks from peer=7
2018-11-15 09:02:50 CMasternodeSync::processTick -- nTick 505 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:02:56 CMasternodeSync::processTick -- nTick 506 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:03:02 CMasternodeSync::processTick -- nTick 507 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:03:08 CMasternodeSync::processTick -- nTick 508 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:03:14 CMasternodeSync::processTick -- nTick 509 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 09:03:20 CMasternodeSync::processTick -- nTick 510 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000

Update 3 : closing and restarting wallet jumps block to 263813 (13 nov 2018), 45 hours behind
and then hangs again. Using the bootstrap on this version (v0.13.0.0-rc3) hangs at block 263812.

Which means i cant verify block 264978 or have it reconsidered.

Update 4 : After giving it another try today, my two windows wallets (i had this problem with two wallets) finally started to further sync from two days ago to current date.
I have no idea why it took 20 minutes / 150 nTicks to find next UpdateTip, so it could continue the sync .. but it finally synced completely.

2018-11-15 19:36:31 CMasternodeSync::processTick -- nTick 148 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 19:36:37 CMasternodeSync::processTick -- nTick 149 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 19:36:43 CMasternodeSync::processTick -- nTick 150 nCurrentAsset 0 nTriedPeerCount 0 nSyncProgress -0.250000
2018-11-15 19:36:45 Timeout downloading headers from peer=0, disconnecting
2018-11-15 19:36:45 ThreadSocketHandler -- removing node: peer=0 addr=18.136.12.8:19999 nRefCount=1 fInbound=0 fMasternode=0
2018-11-15 19:36:46 UpdateTip: new best=0000000004e059b7661d55e6a5e96b474b1eb04894581f6b0289a3eac37a2636 height=263814 version=0x20000008 log2_work=54.79437054 tx=6337413 date='2018-11-13 11:20:07' progress=0.999680 cache=0.0MiB(6txo)
 
Last edited:

qwizzie

Well-known Member
Aug 6, 2014
1,557
729
183
Translations should be fixed by https://github.com/dashpay/dash/pull/2451

Re sync issues: there are a lot of different versions on testnet, things will get better once we rebuild our testnet mn cluster.
Thank you UdjinM6.

I'm doing some PrivateSend mixing and i'm noticing a real improvement in speed with the "enable PrivateSend multi-session" option, which we can now activate in the Settings / Options / Wallet (this is new in v0.13 correct ?). Well done.

-privatesendmultisession=<n> Enable multiple PrivateSend mixing sessions per block, experimental (0-1, default: 0)

Seeing its off by default, you may consider (if it pass the testing) to setting it on as default.

Edit : also i'm starting to see a few (2 so far) conflicted transactions during my mixing, FYI.
Most (99.9%) of my mixing transactions though are getting confirmed fast and pretty much in the right order now.
 
Last edited: