We love you, Eugene!!! Make sure you get enough sleep and good food every day!!! Oh and don't forget to take a break from coding once in a while!!!
UdjinM6 , I found in my debug.log... Do the transactions (in boldface) from block 250907 to block 250911 belong to the bad actor? Their scriptSig are different than other normal scriptSigs. And those addresses belong to the same person: https://chainz.cryptoid.info/dash/wallet.dws?857577.htm
so there are bad actors/hackers that actively trying to cheat the system, especially with such new code releases? are they looking through the change logs/new code to find vulnerabilities ?
I hope so. The more attacks, the more solid DASH becomes. Can someone explain to me what the reference node is? Ok, so poking back in this thread, it looks or sounds like the reference node is a node that keeps tabs on all the masternodes. When they enter the system, when they are no longer pinging, etc... and controls which masternodes are up for voting as the current working masternode. Is this correct?
Today, my son's mn finally got paid. Last payment was April 7. So it should be on track again Question: Is there any way that the reference node could be integrated into each wallet, with another consensus thingy (love my vocabulary, LOL) It seems necessary, therefore it needs to be decentralized. If all it does is keep track of where each masternode is on the list, a secondary, short blockchain could be added, who's older info expires at some point. Say it holds a month's worth, and dumps the older info to keep it short and sweet ?? I know the node does more, more like serves up eligible masternodes to be voted in, we don't just go down a list, right? If we did, then it would be too predictable as to which masternode would be next, no?
I'm quietly watching our developers activities on github. So, I can tell they are busy working everyday.. https://github.com/evan82?tab=activity
You are being obsessive-compolsive moli What do you what rom this poor SpreadLight? Poor user is getting unwanted attention now lol Are you gonna tie me to any user that has Light in their nick?
ROFL.... I'm just having a good laugh because I can tease you and you're not upset with me... LOL... It's just funny that you're the only one that thought Evan went missing for a week... lol...
UdjinM6 - Win32 wallet crashed three times while DS mixing was running. - After the last restart the wallet started getting collateral fees and so far it's got 5 collateral charges. - Many DS inputs got locked on Coin Control and stayed unlocked (until the wallet was restarted). - Some of my denominated inputs went from having 5 rounds to less rounds after sometime. Then they worked back up to 5 rounds again. Is this something new in the DS code?
- please copy crash info (if any) provided in crash window - could be connected with vvvv - could be connected with ^^^^ will have a look - yes, this can happen when mixing got a bit uneven because rounds now count from the shortest rounds "chain" i.e. if you have your inputs with 2 rounds and your inputs with 5 rounds mixing together they will end up with 2+1 = 3 rounds both. That means that you'll have some mixing done twice but otherwise shortest rounds "chain" could compromise you. However there is surely some place for optimization and smarter logic of choosing inputs to minimize that effect.
I stopped my wallet after getting the 5th collateral fee and just now started it back up. So far it hasn't crashed and no collateral (yet). The DS rounds of some inputs went down and up and down again, making the completion bar go down and up and down... It seems taking longer for Darksend because of mixing twice.. You mentioned "the shortest rounds 'chain'"... Does this mean now the denom inputs in our wallets are programmed to mix with each other and not necessarily have to wait/depend on other people for mixing pairs? I've noticed the DS message still says something like "Waiting for more entry (2/3)...", but are we at the point now denom inputs in a same wallet can be mixed internally with each other AND also with other external mixing pairs?
UdjinM6 - I just looked at my wallet... During the last 10 hours it got 5 more collateral fees... for a total of 10 collaterals now... and the completion is only at 26% for 16 rounds. Also got 75 locked inputs... Going to shut it down.
Yep and nope. Yep, because you sending many inputs and they are technically saying mixing together too. Nope, because mixing with your own outputs only instead of waiting for 3rd participant doesn't really help - it would be just the same as 2 participants mixing instead of 3 and therefore a lot less secure. Regarding "the shortest rounds 'chain'": DS rounds basically means how many mixing txes I can found scanning from that input back in history that are "chained" together. So 2 rounds means I can find one mixing tx and another one next to it and next after it will be non-mixing one. Same for 5 rounds but the "chain" is longer. I got even more collaterals and that's ok if you have them ~ at every 10th mixing https://github.com/dashpay/dash/commit/ecd37e134eb1690fb008229b4f93a3ef5c6c66f9 - they are 10 times lower since 0.11.2: 0.1 DASH -> 0.01 DASH (but charging more often) Regarding locket inputs - are they still locked after you hit "Stop Mixing"?
Please, UdjinM6 (and others here), can you help me figure this out? Today my MN is receiving this PoSe score "1", and I am trying to figure out why, so from the "putty" terminal I did a grep "error" debug.log command and have received the following: 2015-04-11 22:42:41 socket recv error Connection reset by peer (104) 2015-04-12 03:07:18 socket recv error Connection reset by peer (104) 2015-04-12 03:07:18 socket recv error Connection reset by peer (104) 2015-04-12 03:07:18 socket recv error Connection reset by peer (104) 2015-04-12 03:07:18 socket recv error Connection reset by peer (104) 2015-04-12 03:07:18 socket recv error Connection reset by peer (104) 2015-04-12 03:07:18 socket recv error Connection reset by peer (104) 2015-04-12 05:40:13 socket send error Connection timed out (110) 2015-04-12 10:50:07 socket recv error Connection reset by peer (104) 2015-04-12 11:28:28 socket send error Connection reset by peer (104) 2015-04-12 12:45:04 socket send error Connection reset by peer (104) 2015-04-12 13:09:15 socket recv error Connection timed out (110) 2015-04-12 14:41:01 socket recv error Connection reset by peer (104) (...) 2015-04-13 06:54:30 dseep - Asking source node for missing entry CTxIn(COutPoint(a841216e99eea66d0a375de74e826c965a240ad2ce58453a1509200e32a2f9a6, 1), scriptSig=OP_GREATERTHAN [error]) 2015-04-13 08:06:56 socket recv error Connection reset by peer (104) 2015-04-13 09:44:48 socket recv error Connection reset by peer (104) 2015-04-13 11:40:24 socket recv error Connection reset by peer (104) 2015-04-13 12:02:13 socket recv error Connection reset by peer (104) 2015-04-13 12:20:09 socket recv error Connection reset by peer (104) 2015-04-13 14:36:19 socket recv error Connection reset by peer (104) 2015-04-13 16:09:28 socket recv error Connection reset by peer (104) 2015-04-13 18:48:18 socket send error Connection timed out (110) 2015-04-13 19:25:08 socket send error Connection timed out (110) 2015-04-13 19:38:14 socket recv error Connection reset by peer (104) (...) 2015-04-21 04:06:25 socket recv error Connection reset by peer (104) 2015-04-21 04:36:08 socket recv error Connection reset by peer (104) 2015-04-21 06:28:20 socket send error Connection timed out (110) 2015-04-21 06:32:43 socket send error Bad file descriptor (9) 2015-04-21 06:38:42 socket recv error Connection reset by peer (104) 2015-04-21 07:33:09 socket recv error Connection reset by peer (104) 2015-04-21 09:22:49 socket recv error Connection reset by peer (104) 2015-04-21 13:15:30 socket recv error Connection reset by peer (104) 2015-04-21 14:48:18 socket recv error Connection reset by peer (104) 2015-04-21 15:33:14 socket recv error Connection reset by peer (104) 2015-04-21 15:36:36 socket send error Bad file descriptor (9) 2015-04-21 15:37:53 socket send error Connection timed out (110) 2015-04-21 16:02:33 socket recv error Connection reset by peer (104) 2015-04-21 16:03:57 socket recv error Connection reset by peer (104) 2015-04-21 17:43:40 socket recv error Connection reset by peer (104) 2015-04-21 17:57:00 socket recv error Connection reset by peer (104) 2015-04-21 21:20:30 socket send error Connection timed out (110) 2015-04-22 08:29:08 socket send error Broken pipe (32) 2015-04-22 09:01:20 socket recv error Connection reset by peer (104) 2015-04-22 11:34:04 socket recv error Connection reset by peer (104) 2015-04-22 11:51:36 socket send error Connection timed out (110) 2015-04-22 12:38:55 socket send error Connection timed out (110) 2015-04-22 16:02:04 socket send error Connection timed out (110) 2015-04-22 16:15:18 socket recv error Connection reset by peer (104) 2015-04-22 17:00:25 socket send error Connection timed out (110) 2015-04-22 17:04:10 socket recv error Connection reset by peer (104) 2015-04-22 18:10:06 socket send error Broken pipe (32) 2015-04-22 18:14:09 socket send error Connection timed out (110) It seems to be lots of errors... I sometimes receive this "score 1" for my MN's PoSe, but, after a couple of minutes, it soon corrects itself to "score 0" on its own (without the need of any "intervention" from myself) but this time the "score 1" is lasting for several hours now. Is it possible to know what's wrong from this info above? Is there anything I can do to repair it? Thank you for your help, my friend(s).
Your node has problems to connect to other nodes. Does your network connection has hiccups or is VERY slow? When you run a "ping" for a while, how are the response times? All almost equal (good) or with wide variations?
Hi, crowning, thank you for your reply. I'll keep watching my MN's behaviour from now on regarding its network connection. If this error persists, and I find no other reason for the problem, I'll consider changing its VPS. Here's the tail of the "debug.log": tail debug.log 2015-04-22 20:26:26 CDarksendPool::UpdateState() - Can't set state to ERROR or SUCCESS as a Masternode. 2015-04-22 20:26:27 ResendWalletTransactions() 2015-04-22 20:26:56 CDarksendPool::UpdateState() - Can't set state to ERROR or SUCCESS as a Masternode. 2015-04-22 20:27:25 CActiveMasternode:seep() - RelayMasternodeEntryPing vin = CTxIn(COutPoint(bec46d27708071655b4af58c394460781db35140f5f6ebcb228c8f54a904064b, 1), scriptSig=) 2015-04-22 20:27:26 CDarksendPool::UpdateState() - Can't set state to ERROR or SUCCESS as a Masternode. 2015-04-22 20:27:56 CDarksendPool::UpdateState() - Can't set state to ERROR or SUCCESS as a Masternode. 2015-04-22 20:28:25 CActiveMasternode:seep() - RelayMasternodeEntryPing vin = CTxIn(COutPoint(bec46d27708071655b4af58c394460781db35140f5f6ebcb228c8f54a904064b, 1), scriptSig=) 2015-04-22 20:28:26 CDarksendPool::UpdateState() - Can't set state to ERROR or SUCCESS as a Masternode. 2015-04-22 20:28:51 receive version message: /darkcoinseeder:0.1.2/: version 70076, blocks=250000, us=200.98.129.165:9999, them=0.0.0.0:0, peer=5.45.101.232:54018 2015-04-22 20:28:56 CDarksendPool::UpdateState() - Can't set state to ERROR or SUCCESS as a Masternode. Can't set state to ERROR or SUCCESS as a Masternode !? It seems bad And, after your suggestion, I did a ping here, to check it. These were the results: ping dashtalk.org PING dashtalk.org (85.159.209.13) 56(84) bytes of data. 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=1 ttl=53 time=224 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=2 ttl=53 time=224 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=3 ttl=53 time=224 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=4 ttl=53 time=225 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=5 ttl=53 time=224 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=6 ttl=53 time=225 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=7 ttl=53 time=224 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=8 ttl=53 time=224 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=9 ttl=53 time=224 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=10 ttl=53 time=224 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=11 ttl=53 time=225 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=12 ttl=53 time=225 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=13 ttl=53 time=225 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=14 ttl=53 time=225 ms 64 bytes from darkcointalk.org (85.159.209.13): icmp_req=15 ttl=53 time=225 ms ^C --- dashtalk.org ping statistics --- 15 packets transmitted, 15 received, 0% packet loss, time 14004ms rtt min/avg/max/mdev = 224.761/225.020/225.584/0.615 ms ping google.com PING google.com (173.194.118.37) 56(84) bytes of data. 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=1 ttl=57 time=1.56 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=2 ttl=57 time=1.65 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=3 ttl=57 time=1.65 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=4 ttl=57 time=2.00 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=5 ttl=57 time=1.75 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=6 ttl=57 time=1.65 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=7 ttl=57 time=1.99 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=8 ttl=57 time=1.73 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=9 ttl=57 time=1.57 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=10 ttl=57 time=1.71 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=11 ttl=57 time=1.71 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=12 ttl=57 time=1.51 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=13 ttl=57 time=1.62 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=14 ttl=57 time=1.69 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=15 ttl=57 time=1.61 ms 64 bytes from gru06s10-in-f5.1e100.net (173.194.118.37): icmp_req=16 ttl=57 time=1.58 ms ^C --- google.com ping statistics --- 16 packets transmitted, 16 received, 0% packet loss, time 15024ms rtt min/avg/max/mdev = 1.514/1.690/2.004/0.139 ms ping 144.76.239.66 PING 144.76.239.66 (144.76.239.66) 56(84) bytes of data. 64 bytes from 144.76.239.66: icmp_req=1 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=2 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=3 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=4 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=5 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=6 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=7 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=8 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=9 ttl=47 time=241 ms 64 bytes from 144.76.239.66: icmp_req=10 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=11 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=12 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=13 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=14 ttl=47 time=240 ms 64 bytes from 144.76.239.66: icmp_req=15 ttl=47 time=240 ms ^C --- 144.76.239.66 ping statistics --- 16 packets transmitted, 15 received, 6% packet loss, time 15021ms rtt min/avg/max/mdev = 240.369/240.628/241.422/0.650 ms
UPDATE: At this very moment my MN's PoSe score fixed itself to "0" again. So, maybe, this kind of fluctuation in the score might be normal, after all.
I had the same thing happen with 2 of my nodes. It looked like the server was fine. Dashd was running and responsive to commands. I restarted dashd anyway just to be sure. It lasted about 8 hours and then reset to 0. I have other nodes at the same location that had solid 0s. It looks like you have 5 chances to get dinged each day before your node gets delisted on the 6th one, so a 1 score shouldn't be a big deal. Maybe reducing the allowable connections to 200 or 150 would help.
Thanks, Solarminer. I'll try tweaking things the way you suggested to see how it behaves... Actually, it's quite fun to take care of my baby Masternode
OK I think I`ve found visual bug On new created wallet going to FILE/SENDING ADDRESS when all is blank the Address label is not complete and it is impossible to change the width of the collumn.
Good find Just to keep you updated: I'll fix this, but unfortunately I can only reproduce it under Windows and my local build system for Windows is down for maintenance this weekend, so I'll need some more days to start this.
Small bug on mac wallet under transactions the end of the amounts is obscured by the scrollbar. *I posted this in the wrong thread before I think - apologies if already addressed
