V12 Release

[TaoOfSatoshi]

And.....swing and a miss.....

Keep 'em coming, though! You never know when you actually do find something... We are all testers! :grin:

 

[MangledBlue]

Pretty sure my MN issue(s) has been corrected

kudos to moocowmoo :-D

 

[moli]

UdjinM6 -- From the code it looks like the list history of MN winners was kept as 2x the number of MNs before but now it got changed to 1.25x ... Can we change this back ? so when we don't get paid after 7 days it doesn't say "Never/Unknown" under "Last Paid" on DashNinja, and i think it helps to know if a node gets skipped when we do "masternode winners 5000| grep Xaddr". Or is there a better way to check? Thank you.

 

[UdjinM6]

UdjinM6 -- From the code it looks like the list history of MN winners was kept as 2x the number of MNs before but now it got changed to 1.25x ... Can we change this back ? so when we don't get paid after 7 days it doesn't say "Never/Unknown" under "Last Paid" on DashNinja, and i think it helps to know if a node gets skipped when we do "masternode winners 5000| grep Xaddr". Or is there a better way to check? Thank you.

yep, 1.25x is the reason for "Never/Unknown" for someone being very unlucky.
basically storing 2x is eating way too much memory now (it's stored not in a very efficient way) so we need to optimize it first

 

[moli]

yep, 1.25x is the reason for "Never/Unknown" for someone being very unlucky.
basically storing 2x is eating way too much memory now (it's stored not in a very efficient way) so we need to optimize it first

Oooo.. so that's the reason. Okiedokey then. Maybe someone can find a way to store it on a website and we can check?
Thanks

 

[camosoul]

Oooo.. so that's the reason. Okiedokey then. Maybe someone can find a way to store it on a website and we can check?
Thanks

Seems like any system able to monitor MN's payment vote records, would be able to record them for eternity, if it's operator wanted to do that.

 

[Defacto]

another crash... this time on Mac... so there is more information...

Crashed Thread: 18 dash-msghand

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called
*** error for object 0x7fa51ea9d0c0: pointer being freed was not allocated

Thread 18 Crashed:: dash-msghand
0 libsystem_kernel.dylib 0x00007fff9a6da0ae __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff96db3500 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff9980337b abort + 129
3 libsystem_malloc.dylib 0x00007fff96447051 free + 425
4 io.dashpay.Dash-Qt 0x000000010deae238 0x10dd1c000 + 1647160
5 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
6 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
7 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
8 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
9 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
10 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
11 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
12 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
13 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
14 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
15 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
16 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
17 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
18 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
19 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
20 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
21 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
22 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
23 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
24 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
25 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
26 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
27 io.dashpay.Dash-Qt 0x000000010deae22c 0x10dd1c000 + 1647148
28 io.dashpay.Dash-Qt 0x000000010e0ce35e 0x10dd1c000 + 3875678
29 io.dashpay.Dash-Qt 0x000000010e059e3a 0x10dd1c000 + 3399226
30 io.dashpay.Dash-Qt 0x000000010def7009 0x10dd1c000 + 1945609
31 io.dashpay.Dash-Qt 0x000000010dec5b05 0x10dd1c000 + 1743621
32 io.dashpay.Dash-Qt 0x000000010df187ec 0x10dd1c000 + 2082796
33 io.dashpay.Dash-Qt 0x000000010df67a15 0x10dd1c000 + 2406933
34 io.dashpay.Dash-Qt 0x000000010df678bb 0x10dd1c000 + 2406587
35 io.dashpay.Dash-Qt 0x000000010df65768 0x10dd1c000 + 2398056
36 io.dashpay.Dash-Qt 0x000000010df4f407 0x10dd1c000 + 2307079
37 io.dashpay.Dash-Qt 0x000000010df587fc 0x10dd1c000 + 2344956
38 io.dashpay.Dash-Qt 0x000000010df684ab 0x10dd1c000 + 2409643
39 io.dashpay.Dash-Qt 0x000000010e247b29 0x10dd1c000 + 5421865
40 libsystem_pthread.dylib 0x00007fff96db09b1 _pthread_body + 131
41 libsystem_pthread.dylib 0x00007fff96db092e _pthread_start + 168
42 libsystem_pthread.dylib 0x00007fff96dae385 thread_start + 13​

 

[Solarminer]

Oooo.. so that's the reason. Okiedokey then. Maybe someone can find a way to store it on a website and we can check?
Thanks

Check out dashwhale.org. They have previous history with graphs and the whole works. Rango is super responsive too.

 

[Solarminer]

Feature Request/Bug Fixes
On the help screen of the QT wallet(win 64 version) it says keypool=<n> with default 100. This should be keypoolsize=<n> and the default is 1000. This will create a new wallet with the requested keys. This command doesn't do anything on existing wallets without the keypoolrefill command. So maybe suggest running keypoolrefill after this is changed.

Add all the darksend options in the dash-cli command line(linux x64 version) help they are missing.
Darksend options:
-enabledarksend=<n> Enable use of automated darksend for funds stored in this wallet (0-1, default: 0)
-darksendrounds=<n> Use N separate masternodes to anonymize funds (2-8, default: 2)
-anonymizedashamount=<n> Keep N DASH anonymized (default: 0)
-liquidityprovider=<n> Provide liquidity to Darksend by infrequently mixing coins on a continual basis (0-100, default: 0, 1=very frequent, high fees, 100=very infrequent, low fees)

The anonymizedashamount defaults to 2, not 0. (this should be 0) (linux64 dash-cli version)

Also when darksend mixing, suggest that suspend/hybernate/shutdown be disabled so wallet can finish without computer shutting down.
Also the keypool reserve and keypool keep come up with the same number. Seems like the keypool reserve should be the amount of keys remaining or the amount to keep remaining, not the amount already used which is what both show.
Also suggest when mixing that remaining keys is checked. (keypoolsize - keypool keep) and that should be 1000 or more, if not run keypoolrefill=keypool keep+1000, and backup wallet first before mixing.

 

[crowning]

Feature Request/Bug Fixes

I'll take care of that.

 

[elbereth]

Oooo.. so that's the reason. Okiedokey then. Maybe someone can find a way to store it on a website and we can check?
Thanks

I always add the payment information in my database on Dash Ninja so I added along the RPC information the one from the blockchain on the mndetails page.
It is also returned from the api masternode end-point (obviously).

 

[GermanRed+]

yep, 1.25x is the reason for "Never/Unknown" for someone being very unlucky.
basically storing 2x is eating way too much memory now (it's stored not in a very efficient way) so we need to optimize it first

Does that number have anything to do with your MN position on the payment queue? Some of my MNs got paid in roughly 6 days while some did not get paid for more than a week. How can I check the positions of MNs on the queue?

 

[GermanRed+]

another crash... this time on Mac... so there is more information...

Crashed Thread: 18 dash-msghand

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called
*** error for object 0x7fa51ea9d0c0: pointer being freed was not allocated

Thread 18 Crashed:: dash-msghand​

​

The bug is definitely still there. I can confirm that.

 

[GermanRed+]

What is the variance for getting payment with average number of blocks per payment? It seems a deviation of 2260 blocks from the average number of blocks (i.e. the total number of MNs) is too large. Take this as an example:

https://dashninja.pl/mndetails.html?mnpubkey=Xg7QUn3dAeQRdMDTf29maYEog4BXk9V8q9

It hasn't got paid for more than 5500 blocks.

 

[crowning]

Feature Request/Bug Fixes
On the help screen of the QT wallet(win 64 version) it says keypool=<n> with default 100. This should be keypoolsize=<n> and the default is 1000.
This will create a new wallet with the requested keys. This command doesn't do anything on existing wallets without the keypoolrefill command. So maybe suggest running keypoolrefill after this is changed.

This is fixed, see https://github.com/dashpay/dash/pull/638

Add all the darksend options in the dash-cli command line(linux x64 version) help they are missing.
Darksend options:
-enabledarksend=<n> Enable use of automated darksend for funds stored in this wallet (0-1, default: 0)
[...]

UdjinM6 , I have trouble to get this working, I've added e.g. "enabledarksend" to the available RPC commands, "help enabledarksend' shows the help text correctly in the console, but help (without any parameters) does NOT show this option.

 

[Defacto]

today one of my mn goes to 100% CPU utilization... here is some of ktrace log:

23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdfffdd08)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdddec918)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e1a0,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdddec7d0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdfffdd08)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdfffdd08)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdfffdd08)
23269 dashd CALL clock_gettime(0,0x7fffdddec918)
23269 dashd RET clock_gettime 0
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)
23269 dashd CALL _umtx_op(0x80203e1a0,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdddec7d0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdfffdd08)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdfffdd08)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdddec918)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e1a0,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdddec7d0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdfffdd08)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdfffdd08)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdddec918)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e1a0,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdddec7d0)
23269 dashd RET _umtx_op -1 errno 60 Operation timed out
23269 dashd CALL clock_gettime(0,0x7fffdfffdd08)
23269 dashd RET clock_gettime 0
23269 dashd CALL _umtx_op(0x80203e008,UMTX_OP_WAIT_UINT_PRIVATE,0,0x18,0x7fffdfffdbc0)


and last few lines of log:

Sun Oct 4 05:50:03 2015 ERROR: CheckInputs() : txin values out of range
Sun Oct 4 05:50:03 2015 ERROR: AcceptableInputs: : ConnectInputs failed 3d084cde9ac61ec233f530cefde961b8559a019695c1d6e31728798af8fe10b6
Sun Oct 4 05:50:03 2015 CMasternodePing::CheckAndUpdate - Got bad Masternode address signature CTxIn(COutPoint(59a412d956d2a62d4462f6be28cff66365296abbb5536cd19896020c7e254140, 0), scriptSig=)
Sun Oct 4 05:50:03 2015 Misbehaving: 5.196.23.182:55888 (0 -> 33)
Sun Oct 4 05:50:03 2015 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(59a412d956d2a62d4462f6be28cff66365296abbb5536cd19896020c7e254140, 0), scriptSig=)


there are still problems with 12.0.55 :-(

 

[GermanRed+]

With 0.12.0.x, we are back to have two previous problems before having centralized control of MN network:
1. Large variance for blocks between successive payments.
2. MN crash.
After 55 minor versions, we still have no words on what is causing the crashes. Do we even know what the source of problem is? Or, it is some old known problems (e.g. bad/evil MN operators on the network) that we still cannot resolve at this moment?

 

[fible1]

If it helps any, my MN haven't crashed at all in like 5 weeks. I'm hosted with Flare so it may have something to do with your setup?

Pablo.

 

[splawik21]

With 0.12.0.x, we are back to have two previous problems before having centralized control of MN network:
1. Large variance for blocks between successive payments.
2. MN crash.
After 55 minor versions, we still have no words on what is causing the crashes. Do we even know what the source of problem is? Or, it is some old known problems (e.g. bad/evil MN operators on the network) that we still cannot resolve at this moment?

Mine nodes didn`t crashed since v53 - don`t you have small amount of RAM meaby?

 

[Defacto]

Mine nodes didn`t crashed since v53 - don`t you have small amount of RAM meaby?

it's not a 'not enough RAM' issue. All my nodes have more than 8GB of RAM and no swap usage... and they all crashes (different physical servers - machine types, different locations). Even Mac OS X client (not mn) crashes once.