• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

v0.10.13.x RC5 Testing

Status
Not open for further replies.
What about this? Best of both worlds? :D

5JgM5Mt.jpg

Much better :)
 
Created DRK-70 on Jira. Not sure if this is a bug on my local computer or a software bug:

I'm not sure if it was just a Windows thing or if it was an actual software problem.

Earlier today, I was having problems getting the .4 client to start...it kept crashing. So I decided to delete the entire Darkcoin datadir, including my wallet, since I can always get more tDRK from the faucet. I did so, opened up RC5 v.4 and synced up, got more money from faucet, and went on about my business.

After RC5 v.5 came out and I updated, I saw the faucet was down so thought I would load up my earlier wallet with 14k tDRK. I undeleted it, moved it back to my datadir, and went to open Darkcoin and received a very dramatic error message: https://imgur.com/yV0iZ0G
 
the completion bar looks misleading as certain input amounts (mostly the 4096's amounts) have n/a for Darksend Rounds and will therefore not be included in the
completion bar.. i should be on some 1% completion of Total Balance but wallet shows 75% completion.

edit : i set Amount and Rounds to 19800 / 8 rounds

QDNtgBS.jpg


PTul0Sq.jpg
 
This.

Enforcement now! xD
Agreed. The pool operators have taken the masternode operators to the woodshed for long enough. If they want to keep 100% of their mined coins, go mine something else. We are Darkcoin. It's time for the pimp hand.
 
As long as it isn't a surprise enforcement, I am all for it to prevent unnecessary forks. Pools should have ample time to be ready for the enforcement (from daemon updates to server-side code). Any pool operator running a DRK pool should know by now that it is a 80/20 breakout. Having said that, is the masternode system functioning as a truly random system (I know there was a bug about every other block the same MN would be selected). There is a point of variance but then there shouldn't be these replicated patterns of payouts as time passes. I'm certainly not complaining when it is my nodes getting the payout but I can see it causing a ruckus if it's not a truly random selection.
 
version 10.13.5

Very high CPU load during first synchronization.

50 to 80%.

On Windows 7 Fast CPU 10 GB Ram
 
v101305 is working nicely, so far so good! I have a few nit-picky suggestions to make the GUI more friendly to the "basic" users among us.

Regarding the last message display on the overview screen. Evan can you uh, dumb that down for us some more :)
Remember not everyone knows what passive submission is. And the syntax feels a bit clunky. Since this is an informational overview that should accommodate all users, perhaps something a bit less technical, e.g:

"Attempted passive submission, Incompatible denominations, will retry"
--> Darksend request incomplete: no matching denominations found for mixing. Will retry...

"Attempted passive submission, Signing timed out, please resubmit, will retry"
--> Darksend request incomplete: timed out. Will retry...

"Attempted passive submission, Queue is full, will retry"
--> Darksend request incomplete, masternode queue is full. Will retry...

"Successfully denominated funds! Transaction completed successfully"
--> Darksend request complete: transaction successful!


Also, I would suggest changing the status bar mouseover text. That status bar percentage (yes please keep it in there) has the potential to be confusing to anyone who doesn't understand how the completion % is being calculated. A few extra words might go a long ways:

"Inputs have an average of x of y rounds"
-->"Darksend inputs have completed an average of x of total y rounds".
 
As long as it isn't a surprise enforcement, I am all for it to prevent unnecessary forks. Pools should have ample time to be ready for the enforcement (from daemon updates to server-side code). Any pool operator running a DRK pool should know by now that it is a 80/20 breakout. Having said that, is the masternode system functioning as a truly random system (I know there was a bug about every other block the same MN would be selected). There is a point of variance but then there shouldn't be these replicated patterns of payouts as time passes. I'm certainly not complaining when it is my nodes getting the payout but I can see it causing a ruckus if it's not a truly random selection.
Definitely. We don't want a surprise enforcement, but we should take advantage of the current 90% voluntary paying super-majority we have now. The altruism isn't guaranteed at any point in the future. When we kick off the non-payers, we want them to be a tiny minority.
Darkcoin is becoming more refined with its core anon features. It makes sense to get the better randomness of RC3 back (not perfect but it's way better than our current situation with RC4), and put the non-paying pools on the right track before moving on to other things. Getting the MNs paid properly should be a part of the fine tuning that's happening here.
 
Definitely. We don't want a surprise enforcement, but we should take advantage of the current 90% voluntary paying super-majority we have now. The altruism isn't guaranteed at any point in the future. When we kick off the non-payers, we want them to be a tiny minority.
Darkcoin is becoming more refined with its core anon features. It makes sense to get the better randomness of RC3 back (not perfect but it's way better than our current situation with RC4), and put the non-paying pools on the right track before moving on to other things. Getting the MNs paid properly should be a part of the fine tuning that's happening here.

Guys, I agree with you, but the problem isn't the level of consensus. The problem is that the enforcement code doesn't work!
 
the completion bar looks misleading as certain input amounts (mostly the 4096's amounts) have n/a for Darksend Rounds and will therefore not be included in the
completion bar.. i should be on some 1% completion of Total Balance but wallet shows 75% completion.

edit : i set Amount and Rounds to 19800 / 8 rounds


I noticed that too now that I am trying to denom larger amounts (5000, 4 rounds). I'll go ahead and create a Jira ticket, since I don't see one there yet.
 
Details, please.

It turns out the masternode voting system is over complicated and somewhat risky to the network, so I've removed it and am using the RC3 masternode payment system. This means we won't have enforcement, but it fixes all of these issues and removes the risk to the network. <Quote from JIRA-33 http://jira.darkcoin.qa/browse/DRK-33?>

The RC4 system has inherent issues that were documented in Jira, plus it also has a systematic risk to the network (Sporking is less risky than a hard fork, but there's a risk the network forks wouldn't actually go away when the spork was turned off after a failure). These few issues combined with the fact that we've reached 80-90% payment efficiency tells me that it's not worth the risk to the network to move from the RC3 payment system.

Also, I have a separate plan I've been considering as an alternative that carries no risk and can be done at RC5's launch. Basically, I would set a minimum protocol version and boot anyone not running RC4 or later off the network. This should get us to 98%+ payments. <Quote from https://bitcointalk.org/index.php?topic=421615.msg8563225#msg8563225>

Evan seems to think that updating the minimum protocol level will suffice. Flare does not.
 
Thanks for the explanation. I wonder if a block height based AND protocol based boot would be possible. Soft intro RC5 in parallel with RC4, and once a certain number of blocks go by after the soft launch, give RC4 the real boot.
 
95pcUpfef5pLI19LKWUDw5mWVS5nsyM3BjUBQPS5U1t1OFAthZWRFyQZDj6SmbV33GHAp2aK__5_CBrdzBpsEDgFbUftOefgpsoCeIDxOcVUJpCqjleWjxnUstkVPs4QsA


What about this?
I actually think this is basically fine.

Just prompt the user upon first time usage to select low/med/high (2/4/8 rounds), be sure to include a brief explanation that more rounds cost more and takes more time, and finally let the user input how much they want anonymized. After that tell the user that settings and changed at anytime and refer them to the correct menu location.

Done. Easy to understand and not intrusive.
 
Last edited by a moderator:
I'm testing on anonymizing 300 tdrk, 4 rounds. Need someone to pair with. Is anyone doing testing right now?

Edit: GUYS, this is RC5 testing, you can't sleep yet!! Also, you can talk about what you want for the interface later!!! We need to test the heck out of all of the wallets!

:grin::smile::grin::smile:
 
Last edited by a moderator:
1000
I'm testing on anonymizing 300 tdrk, 4 rounds. Need someone to pair with. Is anyone doing testing right now?

Edit: GUYS, this is RC5 testing, you can't sleep yet!! Also, you can talk about what you want for the interface later!!! We need to test the heck out of all of the wallets!

:grin::smile::grin::smile:
1000 on the road of privacy :wink:
 
Status
Not open for further replies.
Back
Top