V12 Release

[splawik21]

lol that is strange, rly.... can you provide the config please?
you can PM me too.

 

[UdjinM6]

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

tbh, I'm not sure what we are trying to fix here and why would someone want them in help command at all - it's cmd-line option while "help smth" is for rpc

 

[GermanRed+]

I have cron script to take care of the crash. Please do not consider this as some complain because my MNs did not get paid. My MNs got paid but I am aware of these two issues. When we see both large variance and crash, this should ring a bell.

 

[camosoul]

I have cron script to take care of the crash. Please do not consider this as some complain because my MNs did not get paid. My MNs got paid but I am aware of these two issues. When we see both large variance and crash, this should ring a bell.

You're starting to smell like a troll, but I'll withhold my wrath for the moment...

1) Large variance in what? Payment quantity? Payment timing? Money hose just not what it used to be? Say something useful in a complete sentence. Your current statement is nonsense.

2) I've had no crashes on .53, and I'm notoriously stingy about my VPS. Not to mention that I bitch and whine like a little girl who didn't get her way every time there's a problem. We need more info to help you. If you are not forthcoming with useful info, then you're going to get the troll boot.

 

[UdjinM6]

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?

No, this number shouldn't affect queue - it's all about "blockhash" vs "mn collateral hash" in the end of the queue.
There is no rpc for this yet.

EDIT: re variance: this happens sometimes for some "unlucky" MNs but that shouldn't happen many times in a row in general. Think of it as of an "optimized" normal distribution - 90% you are in linear queue and last 10% of queue is some kind of normal distribution i.e. in general it should be fine but there still will be some lucky and unlucky MNs. Anyway I think we need more time to get some stats so we can have a look if there is smth can/need to be tuned or is it actually ok.

 

[GermanRed+]

You're starting to smell like a troll, but I'll withhold my wrath for the moment...

1) Large variance in what? Payment quantity? Payment timing? Money hose just not what it used to be? Say something useful in a complete sentence. Your current statement is nonsense.

2) I've had no crashes on .53, and I'm notoriously stingy about my VPS. We need more info to help you. If you are not forthcoming with useful info, then you're going to get the troll boot.

1. I mentioned variance in payment timing. I said blocks between successive payments.
2. I am not the only one experiencing the crashes. The nodes have plenty of RAM and disk space and the setup has no problem for 0.11.2.x.

If you consider mentioning these two issues as trolling, the only thing I can do is to shut up to avoid being booted.

 

[camosoul]

1. I mentioned variance in payment timing. I said blocks between successive payments.
2. I am not the only one experiencing the crashes. The nodes have plenty of RAM and disk space and the setup has no problem for 0.11.2.x.

If you consider mentioning these two issues as trolling, the only thing I can do is to shut up to avoid being booted.

I've noted a bit more randomization between payments, but nothing to be concerned about or that appears exploitable. We're not longer on a forcible list. If you have only a few MNs, or just one, then it's possible you're on the edge of a bell curve. I have enough nodes to notice some stretch a little, some are tighter. I had one lag to almost 7 days once, but that's the only odd one out. Everything has been predictable with just that one flier.

I'm enjoying the higher payments. Block reward share may only be 50% now, but more DASH per... Yummie.

As for your crashes, we're going to need some debug or error log. I had a hell of a fight a while back with the daemon just disappearing without a trace. Running it with a monitor/hypervisor caused it to stop crashing, so I never could get any useful info...

Compare package dependencies with other people who are crashing. I admit that I haven't done an apt-get update, apt-get upgrade in many months. Perhaps a recent package/dependency is goofing on you and plenty of us are just leaving our old crap alone because it works, so why fix it? Money hose not broken, don't fuck with it!

 

[GermanRed+]

No, this number shouldn't affect queue - it's all about "blockhash" vs "mn collateral hash" in the end of the queue.
There is no rpc for this yet.

EDIT: re variance: this happens sometimes for some "unlucky" MNs but that shouldn't happen many times in a row in general. Think of it as of an "optimized" normal distribution - 90% you are in linear queue and last 10% of queue is some kind of normal distribution i.e. in general it should be fine but there still will be some lucky and unlucky MNs. Anyway I think we need more time to get some stats so we can have a look if there is smth can/need to be tuned or is it actually ok.

Regarding the variance, I still need to observe it a little bit. It looks like the payment for MN with large variance was skipped instead of having a normal distribution.

 

[GermanRed+]

I've noted a bit more randomization between payments, but nothing to be concerned about or that appears exploitable. We're not longer on a forcible list. If you have only a few MNs, or just one, then it's possible you're on the edge of a bell curve. I have enough nodes to notice some stretch a little, some are tighter. I had one lag to almost 7 days once, but that's the only odd one out. Everything has been predictable with just that one flier.

I'm enjoying the higher payments. Block reward share may only be 50% now, but more DASH per... Yummie.

As for your crashes, we're going to need some debug or error log. I had a hell of a fight a while back with the daemon just disappearing without a trace. Running it with a monitor/hypervisor caused it to stop crashing, so I never could get any useful info...

Compare package dependencies with other people who are crashing. I admit that I haven't done an apt-get update, apt-get upgrade in many months. Perhaps a recent package/dependency is goofing on you and plenty of us are just leaving our old crap alone because it works, so why fix it? Money hose not broken, don't fuck with it!

As I mentioned, I am not complaining about the payment. After more than one month observing the the nodes with large variances, it seems exploitable because payments seem to be skipped rather than delayed. The variance should make the payment time sometimes shorter and longer, not doubling the payment time with a much lower average payments over a long period.

EDIT: Regarding the crashes, there are different MN operators here providing the ktrace and other types of log. One of them is about releasing some memory that should not be released or something like that (I forget what I read). Perhaps, MN operators with apt-get upgrade experiencing crashes should report whether they compile from the source or not as well.

We can also say "Money hose not broken, why develop and upgrade?"

 

[Solarminer]

tbh, I'm not sure what we are trying to fix here and why would someone want them in help command at all - it's cmd-line option while "help smth" is for rpc

UdjinM6, I am asking for some information in the command line help to show how to anonymize funds or be a liquidity provider. It is A OK if these are configuration settings that are added to a dash.conf. It seems unreasonable to look at a qt wallet to get options for a command line wallet.

This is the closest information I see in help with dash-cli help. There is no further information by typing dash-cli help darksend. It should be simple to add the 4 missing darksend options(in pic above) between darksend and masternode commands and specify they need to be in the dash.conf.
== Dash ==
darksend <dashaddress> <amount>
masternode "command"... ( "passphrase" )
masternodelist ( "mode" "filter" )......

 

[UdjinM6]

UdjinM6, I am asking for some information in the command line help to show how to anonymize funds or be a liquidity provider. It is A OK if these are configuration settings that are added to a dash.conf. It seems unreasonable to look at a qt wallet to get options for a command line wallet.

Why qt? "dashd --help", see first pic in my prev post.

This is the closest information I see in help with dash-cli help. There is no further information by typing dash-cli help darksend.
...

There is and it's an information about "darksend" rpc command:

> dash-cli help darksend
darksend <dashaddress> <amount>
dashaddress, reset, or auto (AutoDenominate)
<amount> is a real and will be rounded to the next 0.1

Yes, command itself is quite an ugly mix of functionality, description is not too verbose and text formatting is broken (all this can be fixed for sure) but this "help" actually does exactly what it should - it gives some info about rpc command.

Once again:
1) command line options which are used... yes, for command line (and dash.conf) on daemon start. To get help about them - "dashd --help". No rpc commands here.
2) rpc commands which are used to issue commands to wallet. To get help about them "dash-cli help". No command line options here.
There is no need to mix things, they are from 2 completely different "universes".

 

[Solarminer]

Thanks. Sorry, I didn't understand what you meant in your post with RPC/cmd-line references. Now it is clear. Your terms are a little advanced, so I will summarize for simplicity and for those still at the 'beginner DASH course'.
dash.conf settings use:
./dashd -help
Commands executed while daemon is running(RPC) use:
./dash-cli help

Weird that you need a - for the ./dashd but can't use the - for the dash-cli.

The actually help text is readable and easy enough to understand. If you expand the width of the ssh window it formats ok. I just was using the wrong command.

I am a little confused on how you refer to cmd-line/command line since it isn't specific. This typically refers to anything run from a command line. I would think it would refer to the dash-cli commands since they are run after the daemon is running. dashd can't actually accept any command line options directly. This is probably carryover from when dashd issued commands directly.

 

[camosoul]

The variance should make the payment time sometimes shorter and longer, not doubling the payment time with a much lower average payments over a long period.

My experience, monitoring blocks explicitly and counting each one compared against the entire loop depth of total MN count is that a payment coming a few blocks sooner than expected happens quite frequently. Then every once in a blue moon I get one that lags a day or two. Overall its a wash. Theclagging ones really stand out so they get noticed. The ones getting early are not dramaticly early so they don't get noticed unless you're counting every block.

When a node gets paid, add the current mn count to the block height of that payment. About 65% of the time, the next payment has been sooner than that number by about 10 to 15 blocks for me. The occasional laggy one evens it out to essentially the same average as when we had the regulated system.

Those are my observations across 62 nodes.

I can't attest to the rest since I've not seen a crash yet. I cut my cron just to be sure. Cronless for several days, all nodes still solid... I'm usually the guy with the weird problems, lols.

 

[Bridgewater]

Finally had a 12.0.55 problem that caused a MN to get delisted.

Crontab+restart script did not work because the process was still running and using plenty of CPU load for what looks like 30 hours straight with no further update to the debug.log until my stop command.

Before I stopped it, I tried "./dash-cli getinfo" returned nothing (had to ctrl+C). But "./dash-cli masternode status" returned a successfully started response (incorrectly, since the node was obviously not synched).

UdjinM6 would you want to see my full debug.log for this? I'm not sure what to look for to see what caused the problem.

 

[GermanRed+]

Finally had a 12.0.55 problem that caused a MN to get delisted.

Crontab+restart script did not work because the process was still running and using plenty of CPU load for what looks like 30 hours straight with no further update to the debug.log until my stop command.

Before I stopped it, I tried "./dash-cli getinfo" returned nothing (had to ctrl+C). But "./dash-cli masternode status" returned a successfully started response (incorrectly, since the node was obviously not synched).

UdjinM6 would you want to see my full debug.log for this? I'm not sure what to look for to see what caused the problem.

This observation tells us the exact workaround for the delisting problem.

 

[Defacto]

Mac.
Dash Core version v0.12.0.55-c30a0aa (64-bit).

Process: Dash-Qt [1273]
Path: /Applications/Dash-Qt.app/Contents/MacOS/Dash-Qt
Identifier: io.dashpay.Dash-Qt
Version: 0.12.0 (0.12.0)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Dash-Qt [1273]
User ID: 501

Date/Time: 2015-10-10 05:45:09.465 +0200
OS Version: Mac OS X 10.11.1 (15B30a)
Report Version: 11

Time Awake Since Boot: 61000 seconds
Time Since Wake: 4 seconds

System Integrity Protection: disabled

Crashed Thread: 19 dash-msghand

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010
Exception Note: EXC_CORPSE_NOTIFY

VM Regions Near 0x10:
-->
__TEXT 000000010a279000-000000010b7d4000 [ 21.4M] r-x/rwx SM=COW /Applications/Dash-Qt.app/Contents/MacOS/Dash-Qt


Thread 19 Crashed:: dash-msghand
0 libstdc++.6.dylib 0x00007fff91fd84ef std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) + 118
1 io.dashpay.Dash-Qt 0x000000010a62e2fd 0x10a279000 + 3887869
2 io.dashpay.Dash-Qt 0x000000010a62e448 0x10a279000 + 3888200
3 io.dashpay.Dash-Qt 0x000000010a62dee9 0x10a279000 + 3886825
4 io.dashpay.Dash-Qt 0x000000010a62b7d1 0x10a279000 + 3876817
5 io.dashpay.Dash-Qt 0x000000010a455d82 0x10a279000 + 1953154
6 io.dashpay.Dash-Qt 0x000000010a425fc7 0x10a279000 + 1757127
7 io.dashpay.Dash-Qt 0x000000010a474361 0x10a279000 + 2077537
8 io.dashpay.Dash-Qt 0x000000010a4c24fd 0x10a279000 + 2397437
9 io.dashpay.Dash-Qt 0x000000010a4c248e 0x10a279000 + 2397326
10 io.dashpay.Dash-Qt 0x000000010a4c233b 0x10a279000 + 2396987
11 io.dashpay.Dash-Qt 0x000000010a4c01e8 0x10a279000 + 2388456
12 io.dashpay.Dash-Qt 0x000000010a4ac5ce 0x10a279000 + 2307534
13 io.dashpay.Dash-Qt 0x000000010a4b57fc 0x10a279000 + 2344956
14 io.dashpay.Dash-Qt 0x000000010a4c54ab 0x10a279000 + 2409643
15 io.dashpay.Dash-Qt 0x000000010a7a4b29 0x10a279000 + 5421865
16 libsystem_pthread.dylib 0x00007fff8a98f9b1 _pthread_body + 131
17 libsystem_pthread.dylib 0x00007fff8a98f92e _pthread_start + 168
18 libsystem_pthread.dylib 0x00007fff8a98d385 thread_start + 13

 

[Solarminer]

I had several transactions get stuck doing a darksend mixing. I think there is something wrong this version that causes a hangup. After so many mixes there are long delays(30 minutes) with unconfirmed transactions. Seems like the old peers don't like confirming transactions from mixes with .55. I would like to suggest two fixes:

Only allow mixing with the latest peers (V.55 or later)
Resend any unconfirmed transactions during a mix after 1 or 2 blocks.

Also another wallet feature that would be nice is a "Resend Transaction".
I had a standard send transaction get stuck. Not confirmed for 5+ blocks. I did a getrawtransaction, copied, and pasted into another wallet and did a sendrawtransaction and it went. It would be ideal to have an option to right click the transaction and hit resend.

 

[moli]

I had several transactions get stuck doing a darksend mixing. I think there is something wrong this version that causes a hangup. After so many mixes there are long delays(30 minutes) with unconfirmed transactions. Seems like the old peers don't like confirming transactions from mixes with .55. I would like to suggest two fixes:

Only allow mixing with the latest peers (V.55 or later)
Resend any unconfirmed transactions during a mix after 1 or 2 blocks.

Also another wallet feature that would be nice is a "Resend Transaction".
I had a standard send transaction get stuck. Not confirmed for 5+ blocks. I did a getrawtransaction, copied, and pasted into another wallet and did a sendrawtransaction and it went. It would be ideal to have an option to right click the transaction and hit resend.

It's kinda strange your tx didn't get confirmed for 5 blocks. I'm wondering if we could also have malleability problem like bitcoin if someone is doing something similar like this guy: http://motherboard.vice.com/read/i-broke-bitcoin

UdjinM6 , what do you think?

 

[Solarminer]

I have had this happen twice with bitcoin, but the first time with DASH. I think it was related to the mixing I did before hand. There was a darksend denominate the transaction before that said status: conflicted.

 

[UdjinM6]

I had several transactions get stuck doing a darksend mixing. I think there is something wrong this version that causes a hangup. After so many mixes there are long delays(30 minutes) with unconfirmed transactions. Seems like the old peers don't like confirming transactions from mixes with .55.

The only way that left for them to stuck is that some old but compatible MNs (i.e.they are on proto 70103) still send "tx" instead of "dstx" mesages for mixing and as a result such transaction cannot be identified and prioritised. This should be ok in almost every case but for some huge txes mixing 0.1 inputs this result in very low priority -> "conflicted" status.

I would like to suggest two fixes:

Only allow mixing with the latest peers (V.55 or later)

This would require protocol bump i.e. to disable enforcing (for about a week or so) and ask whole network to update again. Does not worth it imo.

Resend any unconfirmed transactions during a mix after 1 or 2 blocks.

Also another wallet feature that would be nice is a "Resend Transaction".
I had a standard send transaction get stuck. Not confirmed for 5+ blocks. I did a getrawtransaction, copied, and pasted into another wallet and did a sendrawtransaction and it went. It would be ideal to have an option to right click the transaction and hit resend.

Wallet is already doing this (resending unconfirmed txes) every 5~30 minutes (time is randomized to prevent malicious nodes from determining the initial transaction source).
https://github.com/dashpay/dash/blob/master/src/wallet.cpp#L1224-L1260