v0.16 Testing

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

 

[xkcd]

It looks like DCG flipped the switch, We Are One.

 

[xkcd]

@frankafn https://www.dash.org/forum/threads/v15-0-testing.49140/page-2#post-222560 I have sent you the 1000 tDASH, can you use this thread from now on? We are testing v16.0 and please make sure you update to the latest version.

 

[frankafn]

Thank you very much

 

[codablock]

@xkcd Yepp, you've already spotted it

We've activated spork21 yesterday. Shortly after that, I accidentally spent collaterals of 150 tMNs due to a bug in one of my provisioning scripts

I've setup 300 new MNs with 0.16 and 75 with 0.15. Spork21 already caused multiple of the 0.15 MNs to get PoSe banned, so the new PoSe improvements seems to work as expected. We'll monitor this a few more days and expect all old MNs to get banned by then.

InstantSend is unstable atm, due to the mistake I made yesterday. It should get back on track in the following hours.

 

[xkcd]

Guys, I need to determine if we have a UI bug in RC2, I had a wallet setup to do nothing but mixing and noted these txes on my overview tab, my understanding is that mixing TXes should be filtered from this screen, is that true? Also, is this a new bug or also happening in v15.0 ?

 

[qwizzie]

Guys, I need to determine if we have a UI bug in RC2, I had a wallet setup to do nothing but mixing and noted these txes on my overview tab, my understanding is that mixing TXes should be filtered from this screen, is that true? Also, is this a new bug or also happening in v15.0 ?

RC1 only had 'payment to yourself' mixing txes visible on our overview tab (Recent Transactions), which got classified as a bug by Pasta. If your transactions in RC2 are indeed 'payment to yourself' mixing txes, then that is a known bug for v0.16.
(RC1 & RC2)

See : https://www.dash.org/forum/threads/v0-16-testing.50294/#post-222478

I am not sure if this bug is also present in our Mainnet v0.15 code base.

 

[xkcd]

Thanks I will add it as an issue to the github.

 

[qwizzie]

Looking forward to RC3 containing :

''We are still working on / investigating the mixing issues and plan to include a potential fix for RC3''

and containing fixes for : https://github.com/dashpay/dash/issues

 

[qwizzie]

Currently in v0.16 prune works on lite mode wallets through commandline option -litemode -txindex=0 -prune=945

Link : https://github.com/dashpay/dash/pull/3488

Testnet Wallet : 1,91 GB
Prune Testnet Wallet : 1,09 GB

Will it be possible to implement -txindex=0 -prune=945 on masternodes (mainnet) some day ?
It sure would be handy to limit or reduce expensive SSD storage space for masternodes.
Or will prune be technically impossible on masternodes ?

Downside of prune is having to download the full blockchain in case of blockchain problems
and -reindex / -rescan not working.

 

[xkcd]

Currently in v0.16 prune works on lite mode wallets through commandline option -litemode -txindex=0 -prune=945

Link : https://github.com/dashpay/dash/pull/3488

Testnet Wallet : 1,91 GB
Prune Testnet Wallet : 1,09 GB

Will it be possible to implement -txindex=0 -prune=945 on masternodes (mainnet) some day ?
It sure would be handy to limit or reduce expensive SSD storage space for masternodes.
Or will prune be technically impossible on masternodes ?

Downside of prune is having to download the full blockchain in case of blockchain problems
and -reindex / -rescan not working.

hahaha, you're gonna love Platform when it launches, each MN needs to keep a fully indexed node (2x space requirement), a running insight, 11 Docker containers and a SSL/TLS cert.