v0.16 Testing
- Thread starter Pasta
- Start date
@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.
@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.
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.
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.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 & 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.
Last edited:
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
''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
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.
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.
Last edited:
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.
Done. It is through a lite mode wallet, so give it some time.
Hello all.
Would anyone kindly send me 1000 tDash? After testing, I will either send back or forward it to someone, of course.
Thanks in advance.
My address: ygCbNEvSFja3ZX4RJB2hh88vKJYZzuiLoY
Would anyone kindly send me 1000 tDash? After testing, I will either send back or forward it to someone, of course.
Thanks in advance.
My address: ygCbNEvSFja3ZX4RJB2hh88vKJYZzuiLoY
I have been doing some mixing on Mainnet with Dash Core version 0.15 and i noticed that mixing slowed when wallet reached about 90% of my target amount.
Wallet did not find any other people to mix denomination 10.0 with all night, it had absolutely no problem mixing with denominations 0.001, 0.01, 0.1, 1 (which most likely formed that 90%). I noticed this same behavior in v0.16 release candidate 2 on Testnet, the first 90% goes smooth and fast, but then the mixing slows considerably. I suspect (but i am not sure) that denomination 10.0 caused the slow down there as well. Although conditions differ considerably between Testnet and Mainnet.
With regards to mixing on Mainnet i suspect many users simply mix with lower then 10 Dash amounts, which means denomination 10.0 is not mixed that often.
Link :
https://dashradar.com/charts/mixing-transactions-per-day-by-denomination (denomination 10.0 is used considerably less, then denomination 1.0)
https://terminal.bytetree.com/dash (Average Median Transaction Value is about $6)
Is it possible to introduce some kind of check into a user mixing session, which keeps on eye on denomination 10.0 and when that denomination is not getting mixed for a long period of time, it will break the 10.0 denomination down to smaller denominations ? (denomination 1.0 for example). To be done through a special PrivateSend Create Denominations transaction (one that excludes denomination 10.0).
I rather have the wallet continue mixing in a smooth and fast way with the smaller denomination amounts, then have the wallet waste a lot of time trying to mix with a denomination it has difficulty finding a match for on Mainnet.
A switch to smaller denominations in the specific situation that the wallet can't find a match for denomination 10.0 for some time, could speed things up on Mainnet for mixing larger Dash amounts (a few hundreds of Dash).
Wallet did not find any other people to mix denomination 10.0 with all night, it had absolutely no problem mixing with denominations 0.001, 0.01, 0.1, 1 (which most likely formed that 90%). I noticed this same behavior in v0.16 release candidate 2 on Testnet, the first 90% goes smooth and fast, but then the mixing slows considerably. I suspect (but i am not sure) that denomination 10.0 caused the slow down there as well. Although conditions differ considerably between Testnet and Mainnet.
With regards to mixing on Mainnet i suspect many users simply mix with lower then 10 Dash amounts, which means denomination 10.0 is not mixed that often.
Link :
https://dashradar.com/charts/mixing-transactions-per-day-by-denomination (denomination 10.0 is used considerably less, then denomination 1.0)
https://terminal.bytetree.com/dash (Average Median Transaction Value is about $6)
Is it possible to introduce some kind of check into a user mixing session, which keeps on eye on denomination 10.0 and when that denomination is not getting mixed for a long period of time, it will break the 10.0 denomination down to smaller denominations ? (denomination 1.0 for example). To be done through a special PrivateSend Create Denominations transaction (one that excludes denomination 10.0).
I rather have the wallet continue mixing in a smooth and fast way with the smaller denomination amounts, then have the wallet waste a lot of time trying to mix with a denomination it has difficulty finding a match for on Mainnet.
A switch to smaller denominations in the specific situation that the wallet can't find a match for denomination 10.0 for some time, could speed things up on Mainnet for mixing larger Dash amounts (a few hundreds of Dash).
Last edited:
- Apr 8, 2014
- 1,971
- 1,339
- 1,283
Repository: dashpay/dash · Tag: v0.16.0.0-rc3 · Commit: 9ded950 · Released by: PastaPastaPasta
This is a release candidate and not meant for production. It is only meant for testnet deployments.
This release was signed by keybase.io/pasta.
github.com
This is a release candidate and not meant for production. It is only meant for testnet deployments.
This release was signed by keybase.io/pasta.
Release Dash Core v0.16.0.0 RC3 · dashpay/dash
This is a release candidate and not meant for production. It is only meant for testnet deployments. This release was signed by keybase.io/pasta.
github.com
This is not possible currently because they need to verify governance objects which rely on op_returns and op_returns are pruned. But even if we would implement them say via special txes IMO it should not be possible for masternodes to run in prune mode because they are meant to be full archived nodes serving the blockchain to new nodes.
v0.16 has some improvements to create more of smaller denoms when possible but in general you want some balance there because creating lots of small denoms doesn't help really - you can't pay for anything without using lots of them and this makes on-chain analysis easier which defeats the whole idea.I have been doing some mixing on Mainnet with Dash Core version 0.15 and i noticed that mixing slowed when wallet reached about 90% of my target amount.
Wallet did not find any other people to mix denomination 10.0 with all night, it had absolutely no problem mixing with denominations 0.001, 0.01, 0.1, 1 (which most likely formed that 90%). I noticed this same behavior in v0.16 release candidate 2 on Testnet, the first 90% goes smooth and fast, but then the mixing slows considerably. I suspect (but i am not sure) that denomination 10.0 caused the slow down there as well. Although conditions differ considerably between Testnet and Mainnet.
With regards to mixing on Mainnet i suspect many users simply mix with lower then 10 Dash amounts, which means denomination 10.0 is not mixed that often.
Link :
https://dashradar.com/charts/mixing-transactions-per-day-by-denomination (denomination 10.0 is used considerably less, then denomination 1.0)
https://terminal.bytetree.com/dash (Average Median Transaction Value is about $6)
Is it possible to introduce some kind of check into a user mixing session, which keeps on eye on denomination 10.0 and when that denomination is not getting mixed for a long period of time, it will break the 10.0 denomination down to smaller denominations ? (denomination 1.0 for example). To be done through a special PrivateSend Create Denominations transaction (one that excludes denomination 10.0).
I rather have the wallet continue mixing in a smooth and fast way with the smaller denomination amounts, then have the wallet waste a lot of time trying to mix with a denomination it has difficulty finding a match for on Mainnet.
A switch to smaller denominations in the specific situation that the wallet can't find a match for denomination 10.0 for some time, could speed things up on Mainnet for mixing larger Dash amounts (a few hundreds of Dash).
Hey all,
reallocation HF is active(activated at block 387500), and the reallocation has started. The first reallocation can be seen here https://testnet-insight.dashevo.org...f866ab054e57b36077d09622e9814b4385fbfe160b363
Spork 21 is also active on testnet.
v15 nodes did fork off as expected, and it appears that chain has stalled on testnet as expected.
Next is for spork 22 to be activated on testnet. All systems operational so far.
Let us know of any issues that you have. Expect either a (very short lived) rc4 to be tagged soon, or for the .0 release to be tagged soon
reallocation HF is active(activated at block 387500), and the reallocation has started. The first reallocation can be seen here https://testnet-insight.dashevo.org...f866ab054e57b36077d09622e9814b4385fbfe160b363
Spork 21 is also active on testnet.
v15 nodes did fork off as expected, and it appears that chain has stalled on testnet as expected.
Next is for spork 22 to be activated on testnet. All systems operational so far.
Let us know of any issues that you have. Expect either a (very short lived) rc4 to be tagged soon, or for the .0 release to be tagged soon
Testnet reallocation points for anyone interested
Reallocation points (block height, percentage to MN)
387504 51.30%
387576 52.60%
387648 53.30%
387720 54.00%
387792 54.60%
387864 55.20%
387936 55.70%
388008 56.20%
388080 56.70%
388152 57.20%
388224 57.70%
388296 58.20%
388368 58.50%
388440 58.80%
388512 59.10%
388584 59.40%
388656 59.70%
388728 59.90%
388800 60.00%
Reallocation points (block height, percentage to MN)
387504 51.30%
387576 52.60%
387648 53.30%
387720 54.00%
387792 54.60%
387864 55.20%
387936 55.70%
388008 56.20%
388080 56.70%
388152 57.20%
388224 57.70%
388296 58.20%
388368 58.50%
388440 58.80%
388512 59.10%
388584 59.40%
388656 59.70%
388728 59.90%
388800 60.00%
Make sure you are on DashCore test wallet v0.17.0.0 RC2 : https://github.com/dashpay/dash/releases/tag/v0.17.0.0-rc2
If you were on v0.16.0.0 and you experience problems syncing blocks, may i suggest you delete everything inside your testnet3 folder except your wallet.dat and dash.conf (don't delete those two !!) and have your Dash Core wallet download the blockchain from scratch.
I will send you some tDash
Happy testing
Last edited:
RC3 Is now available https://github.com/dashpay/dash/releases/tag/v0.17.0.0-rc3Make sure you are on DashCore test wallet v0.17.0.0 RC2 : https://github.com/dashpay/dash/releases/tag/v0.17.0.0-rc2
If you were on v0.16.0.0 and you experience problems syncing blocks, may i suggest you delete everything inside your testnet3 folder except your wallet.dat and dash.conf (don't delete those two !!) and have your Dash Core wallet download the blockchain from scratch.
I will send you some tDash
Happy testing
Last edited: