v0.11.0.x Core Testing

Status
Not open for further replies.
qwizzie said:
i seem to have difficulty getting my wallets to mix with update v0.11.0.4-gc1fde4d
windows 32 bit.

So far i got 2 of my 6 wallets to mix 1 round but now they are all either in idle status or status
no compatible masternode found. I deleted the peers.dat already with all wallets and they are
all having 4 or 5 connections by now (i would really like to add some more addnodes to get them to
8 connections btw) and they all see 35 masternodes.

Most of my wallets are of the same amount / rounds (780 / 8) and they should have an easy time pairing against each other
but that just doesnt seem to happen right now.

Maybe it just needs more time, so i will let it run some more.

qwizzie
Click to expand...
Are you running multiple wallets from the same computer? My understanding is Evan changed how DS works, like if A pairs with B at the first round, A can't pair with B again until much later or not at all. So on Testnet it takes 2 participants at each round but not the same 2 participants on every round. Also, your pairing has to be at a different masternode each time, or not too recent, this is why DS can take a long time. (And I hope DS works like this or even more complex, because if pairing is so easy and frequent with same participants. it's not going to accomplish anonymity and the code needs to be revised, imho.)

I can be wrong and hope someone else who knows better can help us to understand better.
 
qwizzie said:
can we have some stable connection nodes pls to add in our darkcoin.conf
thanks
Click to expand...
please delete your peers.dat and try again. your client should never get stuck at 0 connections as it cointains seednodes. if this happens again, could you share the debug log?
 
where do all these conflicted transactions come from? does anyone else see this? v11.0.4

NXDkrgU.png
 
eduffield said:
v0.11.0.4

This version has everything and works on mainnet. If there's anything else needed before we launch let me know.
Click to expand...

Roadmap for release of v11 eduffield flare UdjinM6 freynder
  • darksend balance is not accurate. reproduce: if you try to exactly spend your available anonymous balance, it always throws an error message: not enough denominated funds.
  • unchecking and checking the darksend box on send page resets darksend available funds to 0. (Jira-140, Jira-145, Testing-368, Testing-406)
  • darksend denominations do not stop at the set limit (e.g. 2000 DRK), it continuosly denominates all available coins. (which is good in my opinion, darksend is very stable recently and we should turn on denominations by default and allow all users to denominate all available coins. maybe we could provide a commandline flag -darksend=0 which disables auto-denominations or -darksendlimit=-1 which sets the denomination amount to unlimited) (Testing-385)
  • the darksend ui features have several typos and for instance do not use darkcoin units but a hardcoded "DRK" string. this needs some fine tuning. (Testing-398, Testing-399, Testing-400, Testing-401, Testing-403)
  • another major issue is client performance during scanning the blockchain for darksend transactions. the qt wallet freezes during this process. we really need to put these actions into a seperate thread! it's not releasable, we need to deliver a responsive qt wallet at any time. (Testing-337, Testing-432)
  • the darksend progress bar is confusing. maybe improve the label what is 100%, which progress? or simplify it to anon-coins/total-coins. (Testing-415)
  • the unlock for anonymization is bugged, it does not reset correctly and shows empty warning messages while sending coins. (Testing-326, Testing-384, Testing-369, Testing-408)
  • the wallet miner still does not work on some systems (reported win32). (Jira-144)
  • a bug in masternode configuration allows to get paid without having 1000 drk (i suspect the masternode=1 flag in config is causing trouble). (Jira-146)
  • mac wallet is unusable (not build correctly, doesnt install). (Testing-322, Testing-413)
  • miner crashs the wallet while rescanning/reindexing. (Github-89)
  • conflicted transactions spam the transaction view. (Testing-336, Testing-355, Testing-429)
  • we need automated testing scripts. (Testing-342)
  • darksend status enabled/disabled ui issue. (Testing-353, Jira-143)
Anything missing?

eduffield we should not release without having at least fixed the two major highlighted issues.
 
Last edited by a moderator:
the syncing of this new update on windows 32bit seems different than previous updates, if you have enough connections to sync from start
you often see the following :

- out of sync for lets say 8 hours
- sync icon not moving around so it visually appears not to be syncing yet
- after a minute or so its suddenly totally synced .. going from out of sync 8 hrs to totally synced.
- i'm not seeing a countdown from 8 hrs to 0 hrs and i dont think i saw the sync icon ever move during sync.

also in the time between out of sync and wallet having total sync the GUI wallet on windows 32 is very unresponsive,
the window of the wallet has a lot of drag if you try to move it around and also trying to get to the options of the wallet
gives you a lot of lag. Basicly this means waiting till wallet is totally in sync before doing anything with the wallet.

I checked this period of heavy drag with my taskmanager and with a core temp program, no heavy CPU use (and all
nicely spread out of multiple cores on my quad core cpu) and no abnormal RAM use or network use or disk use.
The lag seems to be coming from the wallet itself.

edit 1: also i would really really really really really like some stable addnodes to put in my darkcoin.conf

edit 2: for one of my wallets i deleted the whole blockchain, wallet, peers.dat .. everything.
During sync there was no lag and sync icon was showing sync movement.

edit 3 : did a total delete and resync for all my wallets, seems to have fixed the lagging of the wallets during sync (i need to check this tomorrow .. when its syncing again for a number of hours / night). i did noticed that all my debug.logs were of 26 MB before i decided to start with a new blockchain & wallet for all my wallets. Perhaps that was creating a lot of lag. Unfortunetely i dont have those debug.logs anymore to see what got them so large.
 
Last edited by a moderator:
vertoe said:

Roadmap for release of v11 eduffield flare UdjinM6 freynder
  • darksend balance is not accurate. reproduce: if you try to exactly spend your available anonymous balance, it always throws an error message: not enough denominated funds.
  • unchecking and checking the darksend box on send page resets darksend available funds to 0. (Jira-140, Jira-145, Testing-368, Testing-406)
  • darksend denominations do not stop at the set limit (e.g. 2000 DRK), it continuosly denominates all available coins. (which is good in my opinion, darksend is very stable recently and we should turn on denominations by default and allow all users to denominate all available coins. maybe we could provide a commandline flag -darksend=0 which disables auto-denominations or -darksendlimit=-1 which sets the denomination amount to unlimited) (Testing-385)
  • the darksend ui features have several typos and for instance do not use darkcoin units but a hardcoded "DRK" string. this needs some fine tuning. (Testing-398, Testing-399, Testing-400, Testing-401, Testing-403)
  • another major issue is client performance during scanning the blockchain for darksend transactions. the qt wallet freezes during this process. we really need to put these actions into a seperate thread! it's not releasable, we need to deliver a responsive qt wallet at any time. (Testing-337)
  • the darksend progress bar is confusing. maybe improve the label what is 100%, which progress? or simplify it to anon-coins/total-coins. (Testing-415)
  • the unlock for anonymization is bugged, it does not reset correctly and shows empty warning messages while sending coins. (Testing-326, Testing-384, Testing-369, Testing-408)
  • the wallet miner still does not work on some systems (reported win32). (Jira-144)
  • a bug in masternode configuration allows to get paid without having 1000 drk (i suspect the masternode=1 flag in config is causing trouble). (Jira-146)
  • mac wallet is unusable (not build correctly, doesnt install). (Testing-322, Testing-413)
  • miner crashs the wallet while rescanning/reindexing. (Github-89)
  • conflicted transactions spam the transaction view. (Testing-336, Testing-355, Testing-429)
  • we need automated testing scripts. (Testing-342)
  • darksend status enabled/disabled ui issue. (Testing-353, Jira-143)
Anything missing?

eduffield we should not release without having at least fixed the two major highlighted issues.
Click to expand...

Nice and clear color coded todo list, i like it!
 
qwizzie said:
the syncing of this new update on windows 32bit seems different than previous updates, if you have enough connections to sync from start
you often see the following :

- out of sync for lets say 8 hours
- sync icon not moving around so it visually appears not to be syncing yet
- after a minute or so its suddenly totally synced .. going from out of sync 8 hrs to totally synced.
- i'm not seeing a countdown from 8 hrs to 0 hrs and i dont think i saw the sync icon ever move during sync.

also in the time between out of sync and wallet having total sync the GUI wallet on windows 32 is very unresponsive,
the window of the wallet has a lot of drag if you try to move it around and also trying to get to the options of the wallet
gives you a lot of lag. Basicly this means waiting till wallet is totally in sync before doing anything with the wallet.

I checked this period of heavy drag with my taskmanager and with a core temp program, no heavy CPU use (and all
nicely spread out of multiple cores on my quad core cpu) and no abnormal RAM use or network use or disk use.
The lag seems to be coming from the wallet itself.

edit 1: also i would really really really really really like some stable addnodes to put in my darkcoin.conf

edit 2: for one of my wallets i deleted the whole blockchain, wallet, peers.dat .. everything.
During sync there was no lag and sync icon was showing sync movement.

edit 3 : did a total delete and resync for all my wallets, seems to have fixed the lagging of the wallets during sync (i need to check this tomorrow .. when its syncing again for a number of hours / night). i did noticed that all my debug.logs were of 26 MB before i decided to start with a new blockchain & wallet for all my wallets. Perhaps that was creating a lot of lag. Unfortunetely i dont have those debug.logs anymore to see what got them so large.
Click to expand...
two posts up, point five (red).
 
Found about 20 masternodes on Mainnet using 0.11.0.4 already , Is this ok for the darkcoin? how about jira-146 issue?
 
thelazier said:
Found about 20 masternodes on Mainnet using 0.11.0.4 already , Is this ok for the darkcoin? how about jira-146 issue?
Click to expand...

eduffield said:
v0.11.0.4

This version has everything and works on mainnet.
Click to expand...

Aside from being left in the dark, and appropriately so, about some changes to function and features, it's working fine... Was a bit confusing to deal with the "undocumented new stuff" but it isn't officially released, so what kinda docs would there be?

MNs auto-start and 30 minute ping. Don't let that "feature" fool you... The only reason I find for even sshing to a node is that the daemon has poofed with no trace of why...

It crashed:
ssh username@ipaddress "~/.darkcoin/darkcoind"

Update:
ssh username@ipaddress "~/.darkcoin/darkcoind-cli stop"
ssh username@ipaddress "rm ~/.darkcoin/darkcoind"
ssh username@ipaddress "scp -C username@localmachine:~/.darkcoin/darkcoind ~/.darkcoin/"
ssh username@ipaddress "scp -C username@localmachine:~/.darkcoin/darkcoin-cli ~/.darkcoin/"
ssh username@ipaddress "~/.darkcoin/darkcoind"

Optionally after both:
ssh -t username@ipaddress "top -d 1"

After either of those, everything else is done from the "local" wallet which consists of nothing more than:

masternode start-alias [alias]

OR

[lazymode]
masternode start-many
[/lazymode]

Now that idiot-proofing seems to be in effect, lazy admin can be lazy...

Or if a handfull of them poofed, just skip figuring out the alias/ip correlation and hit start-many. Success reporting/feedback when the command is issued needs some updating, but that's just window dressing. The meat and potatoes are working. Issuing the start-many or start-alias commands repeatedly doesn't result in repeat announce or listing anymore, so being lazy is not harmful.

[if you have 25 MNs, 4 of them crashed and you restarted the daemons as above, issuing start-many as a catch-all is just fine and doesn't do anything bad now, BUT, it will tell you that it successfully started 25 masternodes even though 21 were already running and it in fact did not start 25 masternodes, but only 4 announcements were amde. This can be verified by sitting on your thumbs for about 30 seconds and then checking the masternode list | grep foo; no duplicates in the list! Bewbs!. You can also stare at your tail -f debug.log as you do it and see that it doesn't actually broadcast all 25.]

Does it get any easier than that?

[-C is compress. It saves pipe, but also accelereates transfer. Matters when you have 0.768Mbps ADSL uplink...]

I find no other reason to even touch the nodes...

Start-many is now the hot sex. When nodes mystery poof, it's easy to put them back. Managing dozens of nodes is now a breeze. Multi-announce idiot proofing seems to be in full-effect. Expect to see more. Working on finding out why they mystery poof in the first place... gdb seems to stabilize the client, so that makes it hard, lol. Use gdb, nothing crashes. Stop using gdb, they go back to crashing... Cute.

I expect there will be a few more tics of the end version number. I doubt Evan would have made the above statement if it were harmful.

A few notes...

If you are running a 0.11.0.4 qt locally, and a 0.10.whatever remotely, you still have to tell the remotes to "masternode start" - supposedly you don't have to do this, but I've found through actually using it that, yes, you do.

If your "remote" is 0.11.0.4 (or probbaly greater as this is likely to be a feature that is kept from now on), it will autoping at 30min intervals with no need to tell it to "masternode start"

Found this bit out the hard way... But it's hot and sexy.
 
Last edited by a moderator:
I don't think v.11.0.4 is officially released yet. If we use it on Mainnet, use it at our own risk. I think there's still so many things to be fixed.
 
Status
Not open for further replies.
Back
Top