Thank you guys for kind words. Really appreciate it 
11.2 - Dash Release
- Thread starter eduffield
- Start date
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!!!Thank you guys for kind words. Really appreciate it
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
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?
Last edited by a moderator:
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?
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?
Last edited by a moderator:
He posted a reply on the 15th on BCT.Not to cause panic or anything but havn't heard from Evan for almost a week
I'm quietly watching our developers activities on github. So, I can tell they are busy working everyday..Not to cause panic or anything but havn't heard from Evan for almost a week
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...You are being obsessive-compolsive moli
Are you gonna tie me to any user that has Light in their nick?
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?
- 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?
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:
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).
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)
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.
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
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
Last edited by a moderator:
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.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.
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
- Apr 8, 2014
- 1,950
- 1,311
- 1,283
Good findOK 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.
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.
- Apr 8, 2014
- 1,950
- 1,311
- 1,283
Testing never enoughGood 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.
Thnx Crowning, no need to rush.... and have a great weekend.
It's fixed, see https://github.com/dashpay/dash/pull/321.Testing never enough
Thnx Crowning, no need to rush.... and have a great weekend.
Looks like this now:
