v0.16 Testing
- Thread starter Pasta
- Start date
qwizzie
Well-known member
Done. It is through a lite mode wallet, so give it some time.
Atra-Hasis
New member
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
1005 sent off
qwizzie
Well-known member
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:
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.
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.
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.
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).
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.
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%
qwizzie
Well-known member
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:
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
RC3 Is now available https://github.com/dashpay/dash/releases/tag/v0.17.0.0-rc3
Last edited: