11.2 - Dash Release

Light · Apr 17, 2015

False alarm then

moli · Apr 17, 2015

Light said:
False alarm then

Very funny, Mr.~~Spread~~Light... :tongue:

Light · Apr 18, 2015

moli said:
Very funny, Mr.~~Spread~~Light... :tongue:

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?

moli · Apr 18, 2015

Light said:
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...

moli · Apr 20, 2015

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?

UdjinM6 · Apr 21, 2015

moli said:
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.

moli · Apr 22, 2015

UdjinM6 said:
- 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?

moli · Apr 22, 2015

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.

UdjinM6 · Apr 22, 2015

moli said:
...
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. :smile: 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.

moli said:
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.

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"?

raganius · Apr 22, 2015

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).

crowning · Apr 22, 2015

raganius said:
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)

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?

raganius · Apr 22, 2015

crowning said:
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

raganius · Apr 23, 2015

raganius said:
Hi, crowning, thank you for your reply.

I'll keep watching my MN's behaviour (...)

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.

Solarminer · Apr 23, 2015

raganius said:
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.

raganius · Apr 23, 2015

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 :wink:

splawik21 · Apr 24, 2015

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.

crowning · Apr 25, 2015

splawik21 said:
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

:smile:

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.

splawik21 · Apr 25, 2015

crowning said:
Good find

:smile:

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.

Testing never enough

Thnx Crowning, no need to rush.... and have a great weekend.

crowning · Apr 26, 2015

splawik21 said:
Testing never enough
Thnx Crowning, no need to rush.... and have a great weekend.

It's fixed, see https://github.com/dashpay/dash/pull/321.

Looks like this now:

darkwing · Apr 26, 2015

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

11.2 - Dash Release

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Official Dash Dev

Well-known member

Well-known member

Official Dash Dev

cryptoPag.com

Well-known member

cryptoPag.com

cryptoPag.com

Well-known member

cryptoPag.com

Yeah, it's me....

Well-known member

Yeah, it's me....

Well-known member

Active member