v0.16 Testing

[Pasta]

Release candidate v0.16.0.0-rc1 is ready for testnet!

Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.16.0.0-rc2
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

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

Please see https://blog.dash.org/product-brief-dash-core-release-v0-16-0-now-on-testnet-55c7ac5ff768 for a briefing on what's in the update.

We expect this upgrade to be quite seamless as there are no on-chain consensus related changes involved. Effort for integration partners should be minimal, as only a few RPC parameters and return codes changed. See https://blog.dash.org/updated-product-brief-dash-core-release-v0-16-0-d3debdb6242e

The usual testing should be performed to make sure everything works as expected:
- Check if normal transactions are still working, perform some automated load testing if you want. All transactions should get InstantSend locked
- Check if ChainLocks are happening on new blocks
- Check if creating and voting on proposals work. Also check if winning proposals get paid and other don't.
- Test if PrivateSend is working. Make sure to use the recently added ability to mix in many sessions in parallel (note that this feature requires you to also enable multi session support which is off by default).
- Run a masternode or two, make sure it is paid. Instructions can be found here: https://docs.dash.org/en/stable/masternodes/setup.html

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/
For now, only the faucet at http://faucet.test.dash.crowdnode.io/ is known to be well funded. It should have enough for everyone.

MNOs:
Wiki: https://docs.dash.org/en/stable/developers/testnet.html#masternodes
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.

 

[xkcd]

Refer to these two posts for how you can safely run a testnet desktop wallet and have it completely separate from your mainnet wallet.

https://www.dash.org/forum/threads/v15-0-testing.49140/#post-218589
https://www.dash.org/forum/threads/v14-0-testing.44047/#post-208638

 

[xkcd]

Change to dash.conf in this release, if you define any of these parameters for testnet, you will have to put them in a section at the end of your file with [test] otherwise your masternode will not start.

  "-addnode", "-connect",
      "-port", "-bind",
      "-rpcport", "-rpcbind",
      "-wallet",

Example

[test]
rpcport=4567

 

[AjM]

Release candidate v0.16.0.0-rc1 is ready for testnet!

Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.16.0.0-rc1

That link goes to old version Dash Core v0.15.0.0 RC4, please fix it.

EDIT: Here is the correct link: https://github.com/dashpay/dash/releases/tag/v0.16.0.0-rc1

 

[forro]

Privatesend mixing multisession run on 1.36 tdash. The following denoms were created:
38 of .001
22 of .01
11 of .1
Looks fine.
Received another ~1.7 tdash. While mixing was enabled, it remained idle. All attempts to get it to begin mixing again were fruitless. Stopped and started mixing again, even closed and reopened the wallet, but it remained idle. I then assumed since I already had enough small denominations it did not need to continue. It seems it would make sense for it to attempt to make more of the largest available denoms, in this case a 1 and 6-7 .1s.

I then sent the entire privatesend balance to myself, clearing out all mixed coins. At that point there were two inputs: 1.7 and 1.35. It would not mix. Privatesend remained idle. Again stopping/starting/closing/opening/starting, still idle.

Then I sent all remaining funds to myself, now one input of ~3 tdash. Mixing still will not start, privatesend is idle. Not sure what to do here. There are over 1065 keys left, and rounds are set to 2, with a target PS balance of 1000 dash. Nothing is happening.

 

[qwizzie]

Privatesend mixing multisession run on 1.36 tdash. The following denoms were created:
38 of .001
22 of .01
11 of .1
Looks fine.
Received another ~1.7 tdash. While mixing was enabled, it remained idle. All attempts to get it to begin mixing again were fruitless. Stopped and started mixing again, even closed and reopened the wallet, but it remained idle. I then assumed since I already had enough small denominations it did not need to continue. It seems it would make sense for it to attempt to make more of the largest available denoms, in this case a 1 and 6-7 .1s.

I then sent the entire privatesend balance to myself, clearing out all mixed coins. At that point there were two inputs: 1.7 and 1.35. It would not mix. Privatesend remained idle. Again stopping/starting/closing/opening/starting, still idle.

Then I sent all remaining funds to myself, now one input of ~3 tdash. Mixing still will not start, privatesend is idle. Not sure what to do here. There are over 1065 keys left, and rounds are set to 2, with a target PS balance of 1000 dash. Nothing is happening.

Due to the first post (still) containing an incorrect link to v0.15 can you please confirm you are mixing on v0.16 ?

 

[forro]

Its 16 rc1. It would be interesting if this was a bug on 15, too.

 

[AjM]

Its 16 rc1. It would be interesting if this was a bug on 15, too.

Lets call to @UdjinM6

 

[qwizzie]

Is this normal ?

Is it a testnet specific warning ? I also come across this warning while testing v0.15 on testnet, so it is not specific to v0.16

I like how Dash is shifting away in this v0.16 release from using 6 confirmations before a transaction is visually (gui-wise) fully processed, to using just 1 confirmation.
Having the unconfirmed (0 conformations) transactions shown with an hourglass is a nice touch too.

Also an interesting distinction now between Send and PrivateSend with the addition of the PrivateSend tab.
ChainLocks seems to be working well in v0.16 rc 1, i will do some mixing to see if i come across the problem that has been described by forro.

 

[Pasta]

Privatesend mixing multisession run on 1.36 tdash. The following denoms were created:
38 of .001
22 of .01
11 of .1
Looks fine.
Received another ~1.7 tdash. While mixing was enabled, it remained idle. All attempts to get it to begin mixing again were fruitless. Stopped and started mixing again, even closed and reopened the wallet, but it remained idle. I then assumed since I already had enough small denominations it did not need to continue. It seems it would make sense for it to attempt to make more of the largest available denoms, in this case a 1 and 6-7 .1s.

I then sent the entire privatesend balance to myself, clearing out all mixed coins. At that point there were two inputs: 1.7 and 1.35. It would not mix. Privatesend remained idle. Again stopping/starting/closing/opening/starting, still idle.

Then I sent all remaining funds to myself, now one input of ~3 tdash. Mixing still will not start, privatesend is idle. Not sure what to do here. There are over 1065 keys left, and rounds are set to 2, with a target PS balance of 1000 dash. Nothing is happening.

~I haven't experienced this before, can you turn on `debug privatesend`? you can do this by just opening console in dash-qt and typing `debug privatesend`~

Nevermind, I think I've reproduced it. Will investigate tomorrow

 

[qwizzie]

Do payments to yourself that have been automatically created during PrivateSend mixing, need to show up in 'Recent transactions' ? Or should we hide those there ?

 

[Pasta]

Do payments to yourself that have been automatically created during PrivateSend mixing, need to show up in 'Recent transactions' ? Or should we hide those there ?

Good question, no, mixing related transactions should not appear under recent txes

 

[qwizzie]

~I haven't experienced this before, can you turn on `debug privatesend`? you can do this by just opening console in dash-qt and typing `debug privatesend`~

Nevermind, I think I've reproduced it. Will investigate tomorrow

Yeah, i have noticed it too. After having mixed to 100% and then arranged for extra faucet payment the mixing will indeed not commence any further.
I also noticed the amount to mix can not be adjusted higher, it got stuck on the original amount to mix (even after closing and restarting wallet).

Amount to mix / Target PrivateSend balance has a problem forcing a higher amount to mix through in the wallet.

 

[qwizzie]

I PrivateSend my tDash that i did manage to mix 4 rounds (31.25 tDASH) to a new address in a new wallet.dat and gave this new wallet the command to mix 16 rounds.
It created a bunch of PrivateSend Make Collateral Inputs (5x) and is now idling away.

I am not sure if this is due to nobody mixing on Testnet or due to our current PrivateSend bug.
Last lines in debug.log :

2020-06-18 08:41:12 keypool return 144
2020-06-18 08:41:12 keypool return 145
2020-06-18 08:41:12 keypool return 146
2020-06-18 08:41:12 keypool return 147
2020-06-18 08:41:12 CKeyHolderStorage::ReturnAll -- 133 keys returned
2020-06-18 08:41:14 CGovernanceManager::UpdateCachesAndClean -- Governance Objects: 0 (Proposals: 0, Triggers: 0, Other: 0; Erased: 0), Votes: 0

 

[xkcd]

Hi Qwizzie, I am constantly mixing on testnet. Send your dash to the crowdnode faucet and delete every file in the testnet3 folder, leave the directories, start the wallet and load it from crowdnode and mix. you are facing the bug now. i get it too sometimes.

you should be able to mix the dash completely in a few hours. see all the mixing going on right now? https://testnet-insight.dashevo.org/insight/

 

[qwizzie]

The Dash faucets are either dry or returning very low tDASH (1 tDASH per hour)
Can someone please send me 5x 32 tDASH, so i can do some multi-wallet mixing :

Please send to :

TestDash1 : yiS7aejgikA6yejSAgGYU7hcCyUpU9NKjM
TestDash2 : yamCEYdFboNBAGLWByRbBdLgUbTok4FYgC
TestDash3 : ygpKs774eFB3PndNL5ZV2bwE98PqeUXMZK
TestDash4 : yWAkYyCyGdG3Fec1YZqgeD5KtSNJFb242N
TestDash5 : yPjiyMV1YX2urcWeLxXfRRoSQUbJ94wDMV

Thanks

Edit : Thank you for the tDash, i have got them mixing now.

 

[qwizzie]

So i PrivateSend 31.3 tDash to a tDash address of mine and came across this (by now infamous) red inputs warning :

I was hoping we changed this red PrivateSend inputs warning in this 0.16.0.0 version, as it is confusing for users trying to PrivateSend something.
Should they proceed ? Should they cancel ? How does it affect their privacy, if they continue ? In the end i just clicked on yes to get this PrivateSend
transaction out, but it leaves me with the question on what we want users to do with this red inputs alert exactly.
Also i am wondering why this red inputs alert is not described in our official Dash Docs or in our PrivateSend information within the wallet ? (under 'Help')

Anyways, what action do we want users to take, when they come across this alert ?

 

[Pasta]

I PrivateSend my tDash that i did manage to mix 4 rounds (31.25 tDASH) to a new address in a new wallet.dat and gave this new wallet the command to mix 16 rounds.
It created a bunch of PrivateSend Make Collateral Inputs (5x) and is now idling away.

I am not sure if this is due to nobody mixing on Testnet or due to our current PrivateSend bug.
Last lines in debug.log :

2020-06-18 08:41:12 keypool return 144
2020-06-18 08:41:12 keypool return 145
2020-06-18 08:41:12 keypool return 146
2020-06-18 08:41:12 keypool return 147
2020-06-18 08:41:12 CKeyHolderStorage::ReturnAll -- 133 keys returned
2020-06-18 08:41:14 CGovernanceManager::UpdateCachesAndClean -- Governance Objects: 0 (Proposals: 0, Triggers: 0, Other: 0; Erased: 0), Votes: 0

That's a bug we're investigating. Should be fixed in rc2 / before release

 

[codablock]

Just released RC2: https://github.com/dashpay/dash/releases/tag/v0.16.0.0-rc2. @Pasta can you update the link in your post?

We are still working on / investigating the mixing issues and plan to include a potential fix for RC3. We'd like to have RC2 rolled out on testnet as fast as possible so that we can enable spork21 (which will re-enable min-proto-version and open-port checks for MNs).

 

[forro]

I started up the RC1 wallet to see if it still refused to mix. To my surprise, it is working. The single input was redenominated into many inputs, and is attempting to mix. It can't seem to find any partners however, as it has been able to mix only one input one round in about 90 minutes.

For RC2, I started the wallet with --testnet --litemode --txindex=0 --prune=945. It ended up with 1.4gb of blockchain, rather than 1.9. Was that the correct command?


EDIT:
I didn't give good data. That 1.4 gb was the size of the entire /home folder, although it was a fresh vm. To be more accurate, the size of .dashcore/testnet3/blocks/ is 971mb, so, close enough.

Taking a look at the dash docs for pruning, should the command be run with 945 or 946?

https://docs.dash.org/en/stable/wallets/dashcore/cmd-rpc.html:
"Reduce storage requirements by enabling pruning (deleting) of old blocks. This allows the pruneblockchain RPC to be called to delete specific blocks, and enables automatic pruning of old blocks if a target size in MiB is provided. This mode is incompatible with -txindex and -rescan. Warning: Reverting this setting requires re-downloading the entire blockchain. (default: 0 = disable pruning blocks, 1 = allow manual pruning via RPC, >945 = automatically prune block files to stay under the specified target size in MiB)

Curious why the it would be as high as 946 mb to enable automatic pruning, how did they come to that number?

 

[forro]

Some notes from rc2:

Ran rc2 with --litemode --txindex=0 --prune=945 --enableprivatesend
Hopefully PS will be enabled by default in the future.

When sending to an address from the addressbook, the label displays correctly.

Transactions details don't say "(verified via LLMQ based InstantSend)", displays the confirmation counter starburst until 6 confirmations.

The PS related transactions labeled as 'payment to yourself' show up in recent transactions on the overview tab.

PS redenominated the single input of 3.07 tdash to the following:
1 - 1
0.1 - 18
0.01 - 23
0.001 - 32

With it fully mixed to two rounds, PS was idle. Just for the record, with another input, PS still remained idle, would not redenominate the new input, could not get it to start again. Understood that a fix is coming in another release. I'll close the wallet and see if it works again in a few hours.

Looking forward to rc3!

 

[qwizzie]

Some notes from rc2:

Ran rc2 with --litemode --txindex=0 --prune=945 --enableprivatesend
Hopefully PS will be enabled by default in the future.

When sending to an address from the addressbook, the label displays correctly.

Transactions details don't say "(verified via LLMQ based InstantSend)", displays the confirmation counter starburst until 6 confirmations.

The PS related transactions labeled as 'payment to yourself' show up in recent transactions on the overview tab.

PS redenominated the single input of 3.07 tdash to the following:
1 - 1
0.1 - 18
0.01 - 23
0.001 - 32

With it fully mixed to two rounds, PS was idle. Just for the record, with another input, PS still remained idle, would not redenominate the new input, could not get it to start again. Understood that a fix is coming in another release. I'll close the wallet and see if it works again in a few hours.

Looking forward to rc3!

Do 'payment to yourself' transactions created during mixing still show up in your 'recent transactions' or has that been fixed ? Never mind, i see that it has not been fixed yet (i overlooked that part in your post).

This means two open bugs :

Mixing
'Payment to yourself' transaction created during mixing show up in 'recent transactions'

And the question on what to do with the 'more then 10 input amounts' warning (which i assume is still there, will test it in RC2). Update : that warning is indeed still unchanged in RC2

 

[qwizzie]

I am receiving 'Error opening block database', 'Do you want to rebuild the database now ?' OK --> 'Error opening block database' when trying to start RC2.
I have 4 wallets that won't start RC2 because of this. Could something in RC2 be causing a corruption of the block database ?

2020-07-04 09:49:21 Dash Core version v0.16.0.0-rc2
2020-07-04 09:49:21 InitParameterInteraction: parameter interaction: -listen=0 -> setting -upnp=0
2020-07-04 09:49:21 InitParameterInteraction: parameter interaction: -listen=0 -> setting -discover=0
2020-07-04 09:49:21 InitParameterInteraction: parameter interaction: -listen=0 -> setting -listenonion=0
2020-07-04 09:49:21 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2020-07-04 09:49:21 GUI: setGeometry: Unable to set geometry 5x13+640+280 on QWidgetWindow/'QLabelClassWindow'. Resulting geometry:  120x13+640+280 (frame: 8, 31, 8, 8, custom margin: 0, 0, 0, 0, minimum size: 0x0, maximum size: 16777215x16777215).
2020-07-04 09:49:21 Assuming ancestors of block 000002bbe0f404f22f0aff8032e2a87cef6a32f0840e9199aa0b79ba3870b33c have valid signatures.
2020-07-04 09:49:21 Setting nMinimumChainWork=00000000000000000000000000000000000000000000000000ac720e0b2ed13d
2020-07-04 09:49:21 Using the 'shani(1way,2way)' SHA256 implementation
2020-07-04 09:49:21 Using RdRand as an additional entropy source
2020-07-04 09:49:26 Default data directory C:\Users\Admin\AppData\Roaming\DashCore
2020-07-04 09:49:26 Using data directory D:\DashTest1\Data\testnet3
2020-07-04 09:49:26 GUI: "registerShutdownBlockReason: Successfully registered: Dash Core didn't yet exit safely..."
2020-07-04 09:49:26 Using config file D:\DashTest1\Data\dash.conf
2020-07-04 09:49:26 Using at most 125 automatic connections (2048 file descriptors available)
2020-07-04 09:49:26 Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2020-07-04 09:49:26 Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2020-07-04 09:49:26 Using 8 threads for script verification
2020-07-04 09:49:26 RenameThread: thread new name dash-scriptch
2020-07-04 09:49:26 RenameThread: thread new name dash-scriptch
2020-07-04 09:49:26 RenameThread: thread new name dash-scriptch
2020-07-04 09:49:26 RenameThread: thread new name dash-scriptch
2020-07-04 09:49:26 RenameThread: thread new name dash-scriptch
2020-07-04 09:49:26 RenameThread: thread new name dash-scriptch
2020-07-04 09:49:26 RenameThread: thread new name dash-scriptch
2020-07-04 09:49:26 RenameThread: thread new name dash-scheduler
2020-07-04 09:49:26 scheduler thread start
2020-07-04 09:49:26 libevent: getaddrinfo: nodename nor servname provided, or not known
2020-07-04 09:49:26 Binding RPC on address ::1 port 19998 failed.
2020-07-04 09:49:26 HTTP: creating work queue of depth 16
2020-07-04 09:49:26 No rpcpassword set - using random cookie authentication
2020-07-04 09:49:26 Generated RPC authentication cookie D:\DashTest1\Data\testnet3\.cookie
2020-07-04 09:49:26 HTTP: starting 4 worker threads
2020-07-04 09:49:26 RenameThread: thread new name dash-http
2020-07-04 09:49:26 RenameThread: thread new name dash-httpworker
2020-07-04 09:49:26 RenameThread: thread new name dash-httpworker
2020-07-04 09:49:26 RenameThread: thread new name dash-httpworker
2020-07-04 09:49:26 RenameThread: thread new name dash-httpworker
2020-07-04 09:49:26 Using wallet directory D:\DashTest1\Data\testnet3
2020-07-04 09:49:26 init message: Verifying wallet(s)...
2020-07-04 09:49:26 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2020-07-04 09:49:26 Using wallet wallet.dat
2020-07-04 09:49:26 BerkeleyEnvironment::Open: LogDir=D:\DashTest1\Data\testnet3\database ErrorFile=D:\DashTest1\Data\testnet3\db.log
2020-07-04 09:49:26 Creating backup of D:\DashTest1\Data\testnet3\wallet.dat -> D:\DashTest1\Data\testnet3\backups\wallet.dat.2020-07-04-09-49
2020-07-04 09:49:26 fLiteMode 0
2020-07-04 09:49:26 init message: Loading sporks cache...
2020-07-04 09:49:26 Reading info from sporks.dat...
2020-07-04 09:49:26 Loaded info from sporks.dat  0ms
2020-07-04 09:49:26      Sporks: 19
2020-07-04 09:49:26 Read: Cleaning....
2020-07-04 09:49:26      Sporks: 19
2020-07-04 09:49:26 Cache configuration:
2020-07-04 09:49:26 * Using 37.5MiB for block index database
2020-07-04 09:49:26 * Using 8.0MiB for chain state database
2020-07-04 09:49:26 * Using 254.5MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2020-07-04 09:49:26 init message: Loading block index...
2020-07-04 09:49:26 Opening LevelDB in D:\DashTest1\Data\testnet3\blocks\index
2020-07-04 09:49:26 IO error: D:\DashTest1\Data\testnet3\blocks\index\LOCK: Could not lock file.
2020-07-04 09:49:26 Database I/O error
2020-07-04 09:49:46 Aborted block database rebuild. Exiting.
2020-07-04 09:49:46 PrepareShutdown: In progress...
2020-07-04 09:49:46 RenameThread: thread new name dash-shutoff
2020-07-04 09:49:46 scheduler thread interrupt
2020-07-04 09:49:46 Shutdown: done
2020-07-04 09:55:59

I guess i will need to delete whole blockchain for each wallet.
Update : yep, that fixed it.

 

[forro]

Yesterday on rc2, I was able to mix an input. Consistent with the known bug, it would not continue when a new input was received. Several hours later in the evening yesterday it still would not.
Today, more or less 24 hours later, I started the wallet, started mixing, and it successfully redenominated that input. So it seems the bug is a time-related issue.
However it has not mixed anything in an hour or so, I suspect a lack of partners. @xkcd are you actively mixing on testnet? If not, could you? Also to other thread participants @qwizzie @Pasta @codablock @AjM and anyone else reading this.
I'll keep it running for the rest of the day as I want to verify that it will indeed complete the rounds (just 2 in this case).

 

[qwizzie]

Yesterday on rc2, I was able to mix an input. Consistent with the known bug, it would not continue when a new input was received. Several hours later in the evening yesterday it still would not.
Today, more or less 24 hours later, I started the wallet, started mixing, and it successfully redenominated that input. So it seems the bug is a time-related issue.
However it has not mixed anything in an hour or so, I suspect a lack of partners. @xkcd are you actively mixing on testnet? If not, could you? Also to other thread participants @qwizzie @Pasta @codablock @AjM and anyone else reading this.
I'll keep it running for the rest of the day as I want to verify that it will indeed complete the rounds (just 2 in this case).

Weird, i did not receive a notification of your post by dash.org/forum through your reference link to me.
I will do some mixing for the next two hours.

 

[forro]

Weird, i did not receive a notification of your post by dash.org/forum through your reference link to me.
I will do some mixing for the next two hours.

Thank you @qwizzie (and possibly others), PS mixed to 100%. Afterward, I took another input from a faucet. This time, the input was immediately redenominated and is being mixed. I expected that PS will remain idle. Just another data point.

 

[qwizzie]

I am noticing no problems with mixing when i bundled all my inputs of already mixed funds and sent those to myself in a new address and gave the mixing order.
What i do notice is a slowing in mixing when reaching roughly 90% completion, the last 10% seems to take a long time to complete and the
PrivateSend balance also takes a long time to increase from around that 90% completion.
This is while doing 16 rounds of mixing on small Dash amounts (below 60 Dash)

 

[forro]

I am noticing no problems with mixing when i bundled all my inputs of already mixed funds and sent those to myself in a new address and gave the mixing order.
What i do notice is a slowing in mixing when reaching roughly 90% completion, the last 10% seems to take a long time to complete and the
PrivateSend balance also takes a long time to increase from around that 90% completion.
This is while doing 16 rounds of mixing on small Dash amounts (below 60 Dash)

I think that is due to the fact that the percentage is based on amount of dash, rather than the percentage of inputs which have been mixed.
For example, lets say you have 2 dash, and you want to mix it to 2 rounds. Lets say its broken down to 1 dash and ten .1 dash. That is 11 inputs. 22 rounds of mixing is required to complete the job to 100%. If that 1 dash is mixed to completion and the rest are not mixed at all, it will say 50%. But that 50% is really 2/22 which is close to 10%.
I'm sure there was some debate when it was being defined and dveloped, and they decided to base completion based on amount, which is understandable. It seems like an endlessely debatable thing. You have to choose one or the other eventually. It only annoys those of us who are compelled to watch a pot boil. Half of your dash is indeed useable at that point, so I think they made the right choice.

 

[forro]

Also you are mixing successfully, simultanelously I am mixing successfully. Was the root cause a lack of partners?

 

[qwizzie]

Also you are mixing successfully, simultanelously I am mixing successfully. Was the root cause a lack of partners?

Not in my case, i am usually mixing with multiple wallets (4 wallets or more) at the same time. So they mostly mix against each other or with those users who are also mixing (you for example).
I just had to stop mixing after two hours, because it was getting late. But then i started to notice (before stopping the mixing) that the PrivateSend balance was increasing very slowly (sometimes not at all) and with very small amounts, even though it was still mixing successfully (creating denominate transactions). A possible explanation could be that the mixing at start focus on the larger denomination types, thereby making quick progress in the completion bar and in the PrivateSend balance and in a later stage focus on smaller denomination types, thereby slowing the completion bar and slowing the PrivateSend balance increase. It is not really a problem, i just found it interesting to observe.
Maybe this has always been the case.