v0.11.0 - Darkcoin Core Release

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,287
2,406
1,183
Germany
You make an excellent point... I'd be willing to put up a few vultr instances and donate them to a dev who wants to use them as whatever on testnet. the problem is, I don't have the time to maintain them. If someone else wants to maintain them, contact me and I'll give you the login info
Me :) already maintaining the instances of stonehedge and camosoul so drop me a PM
 

hashcow

New Member
Jul 21, 2014
24
19
3
So, this is the question for the entire dev team. What do you need to make testnet and testing more robust? Change of approach, money, more hands on deck?
really important point. I read your comment on BTCtalk and agree.
This version hopping should not be on the mainnet. Its time consuming and quite dangerous for normal users.
Worst case they loose some of their money and in that case the trust in darkcoin.

I tried to do my best in testing the wallet and DS on my systems.
but at the end it was quite a hurry and the official release was suddenly there.
I would prefer we all test it a longer time to wrangle out the most of the bugs.
And lets make the testnet the same mess as the mainnet is now. different versions of MN. different wallets,...
So the devs could see what to expect.

It will never be the case that all the MN owner update their systems the same time after release - so count on a mixed network and find a solution for.
 
  • Like
Reactions: moli

stonehedge

Well-known Member
Foundation Member
Jul 31, 2014
696
333
233
Don't forget we also have merchants who have to update too...yet another reason why we need to keep main net releases to a minimum. Our current model threatens adoption.
 
  • Like
Reactions: moli

stonehedge

Well-known Member
Foundation Member
Jul 31, 2014
696
333
233
I do just want to add that I'm actually really bowled over by the progress that has been made with 11.x. I don't want to sound overly negative when a huge amount has been achieved.

The question is, how do Bitcoin manage their releases? (Other than slowly!).

Somehow we need to combine the management and quality controls that Bitcoin employs with the innovation and pace of development of the Darkcoin team.
 
  • Like
Reactions: Lukas_Jackson

jpr

Active Member
May 11, 2014
493
393
133
So how many testnet masternodes do we need?
Is it like the more the better or is there a number that is enough?
 

stonehedge

Well-known Member
Foundation Member
Jul 31, 2014
696
333
233
So how many testnet masternodes do we need?
Is it like the more the better or is there a number that is enough?
I don't think its as simple as throwing as many masternodes at testnet as we can. From what I have read I think it is about not having enough people testing in a concerted and pre-planned way and perhaps not reaching consensus amongst the dev team and testing community if and when a release is ready.

Having said that, the more we can make testnet look like mainnet the better. I just feel our problem is with how we use our testing volunteers and the processes that support the conception of a release to its birth into the wild.
 
  • Like
Reactions: moli, Raico and jpr

yidakee

Well-known Member
Foundation Member
Apr 16, 2014
1,812
1,168
283
Good stuff, i am seeing

Code:
terminate called after throwing an instance of std::bad_alloc'  what():  std::bad_alloc
quite often, but was not able to catch the stacktrace yet.
I've never had a MN drop. Except once. One thing I've noticed is that the debug.log bloats massively, so I've been routinely deleting it every time I log in to update. The only time I had a drop was the daemon stopped working for some reason, and when I logged in I saw my 10 GB ssd VPS around 90% used. I deleted without taking note of how big the file was, but it was around Oct/Nov when there was a long run without development updates.

On another note, have a VULTR instance ready to deploy for testnet!
 
  • Like
Reactions: Raico

yidakee

Well-known Member
Foundation Member
Apr 16, 2014
1,812
1,168
283
I don't think its as simple as throwing as many masternodes at testnet as we can. From what I have read I think it is about not having enough people testing in a concerted and pre-planned way and perhaps not reaching consensus amongst the dev team and testing community if and when a release is ready.

Having said that, the more we can make testnet look like mainnet the better. I just feel our problem is with how we use our testing volunteers and the processes that support the conception of a release to its birth into the wild.
That is not entirely true. We've always done our best to break testnet. For the less code-versed among us, we've happily been doing ping-pong routines and track-the-anonymity-trail. What else is there to test besides the underlying MN network?

Even with absurdly variant hashrate, testnet has always delivered. I do believe the main "problem" is exactly the lack of huge amounts of tMN's and network activity to better lessen the variance between testnet and mainnet.
 

crowning

Well-known Member
May 29, 2014
1,415
1,997
183
Alpha Centauri Bc
...One thing I've noticed is that the debug.log bloats massively, so I've been routinely deleting it every time I log in to update...
I while ago I had a look into the code (for other reasons) and from memory (I'm not near my dev-box right now) the file should be truncated if it grows above a certain limit. Never tested this in real-life, though...
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
I've never had a MN drop. Except once. One thing I've noticed is that the debug.log bloats massively, so I've been routinely deleting it every time I log in to update. The only time I had a drop was the daemon stopped working for some reason, and when I logged in I saw my 10 GB ssd VPS around 90% used. I deleted without taking note of how big the file was, but it was around Oct/Nov when there was a long run without development updates.

On another note, have a VULTR instance ready to deploy for testnet!
When you stop the daemon (in your case, to update) and restart it, it should automatically purge the old debug.log file and start fresh on load.
 
  • Like
Reactions: yidakee

yidakee

Well-known Member
Foundation Member
Apr 16, 2014
1,812
1,168
283
When you stop the daemon (in your case, to update) and restart it, it should automatically purge the old debug.log file and start fresh on load.
Not the case, empirically speaking. I didnt take note so can't be certain about numbers, but I am certain that many many updates without deleting debug.log kept increasing the filesize. Not sure about the releases in the past few months though, because I've been manually deleting the log since I saw the memory running out.
What I can say is that the few nodes I have went from +/- 85% used to around 40-45% used after deleting the log. Maybe it is purging since then? idk... all I am saying is that I manually delete my debug.log since a few months ago and never had a MN drop, except the one time and sure enough my VPS was running out of HDD.

Could it be the swap file/ram getting crammed indirectly due to debug.log? Doesnt really make sense as swap in solely used by RAM so should never theoretically get "crammed" due to lack of space. Swap in linux is fixed and not dynamic like in Windows. But the math does add up, more or less. My EC2 instances have 1GB swap, which is about 10% of total HDD space. Could be coincidence, idk... just putting it out there.

.
 
Last edited by a moderator:

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Had my wallet to run DS mixing the last 8 hours and just now it suddenly crashed for no reason.......
:sad:
 

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
v0.11.0.11

This is the last protocol bump and we're moving back to testnet, sorry about all the
updates I just wanted DS to be as secure as possible before moving on to InstantX.

There's going to be 1 more version (11.0.12) after this with some stability fixes (still some segfaults
happing for some people).

- Protocol change: Masternode operators / Darksend users please update!
- Fix unlocking wallet on ds toggle event (UdjinM6)
- Fix incorrect DS txes + few small things including some cleanup / debugging (UdjinM6)
- Implemented DarkSend convertability (thx Aswan/UdjinM6/Minotaur for the idea)

Darksend defaults to a new mode which enables inputs/outputs
of each session to be different. For example 10DRK can be input
and 1DRKx10 can be output. This strengthens the anonymity of
Darksend greatly, which also increasing the usability (Users who
run out of .1DRK denominations can simply turn on Darksend to
split up larger inputs).

11.0.11 Core - All Users

Source: https://github.com/darkcoin/darkcoin
Windows .exe: https://github.com/darkcoinproject/darkcoin-binaries/raw/master/darkcoin-0.11.0.11-win.zip
Mac OSX: https://raw.githubusercontent.com/d...in-binaries/master/darkcoin-0.11.0.11-osx.dmg
Linux: https://github.com/darkcoinproject/darkcoin-binaries/raw/master/darkcoin-0.11.0.11-linux.tar.gz
 

David

Well-known Member
Dash Support Group
Jun 21, 2014
618
628
163
IMO, all major updates (10.x to 11.x, InstantX implementation, etc.) need to be announced at least 24 hours in advance. Major updates (that might cause network issues) should have 72 hours notice, along with a note to upgrade ASAP. These ninja releases are not particularly conducive to fast upgrading.
 
  • Like
Reactions: yidakee

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,861
1,854
1,283
I didn't think of this until last night, but could you make it so that when you hit "start darksend" and the pop up comes for unlocking the wallet, that the "for anonymization only" is default ticked? I keep forgetting to tick it, and I think everyone would prefer to have the wallet somewhat protected during denomination. Why leave a wallet completely unlocked if you're just darksending? Thanks :)
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
I didn't think of this until last night, but could you make it so that when you hit "start darksend" and the pop up comes for unlocking the wallet, that the "for anonymization only" is default ticked? I keep forgetting to tick it, and I think everyone would prefer to have the wallet somewhat protected during denomination. Why leave a wallet completely unlocked if you're just darksending? Thanks :)
Not sure if the wallet can be made to be unlocked while DS mixing the coins.. Or it would be another complicated layer added to the already complex architecture... IMO security can never be entirely up to the software but more so on the responsibility of users. Users should know they should not run Darksend at work, in a library, or some public place or even at home that opens access to his computer by someone else. Also if their computer is already infected and compromised, a password can't protect their wallet.
 

Sub-Ether

Well-known Member
Mar 31, 2014
1,516
1,254
183
another tasty windows update, version 11 of 11 clears my uncompleted wallet mix ickyness that kept carrying over from previous versions (even when I deleted the whole roaming folder and uninstalled all known versions)
Getting not compatible masternode, am assume more people need to update firstly.
 

drkhouse

Member
Nov 22, 2014
79
19
48
IMO, all major updates (10.x to 11.x, InstantX implementation, etc.) need to be announced at least 24 hours in advance. Major updates (that might cause network issues) should have 72 hours notice, along with a note to upgrade ASAP. These ninja releases are not particularly conducive to fast upgrading.
not if it's from Evan ;-)
 

drkhouse

Member
Nov 22, 2014
79
19
48
I love the new tools and help menu. Alot more user friendly.
 
Last edited by a moderator:
  • Like
Reactions: Raico

italx

Well-known Member
Foundation Member
Jul 31, 2014
65
52
158
California
I just updated all my nodes to 11.0.11. I was able to "start" each from the cold wallets and got a "Successfully started Masternode" message. However, each node's log continues to repeat the following:

Code:
2015-01-21 17:52:43 CActiveMasternode::ManageStatus() - Checking inbound connection to '54.xxx.xxx.xxx:9999'
2015-01-21 17:52:43 CActiveMasternode::GetMasterNodeVin - Could not locate specified vin from possible list
2015-01-21 17:52:43 CActiveMasternode::ManageStatus() - Could not find suitable coins!
2015-01-21 17:52:43 CActiveMasternode::Dseep() - Error: masternode is not in a running status
2015-01-21 17:52:43 CActiveMasternode::ManageStatus() - Error on Ping: masternode is not in a running statusconnected to self at 54.xxx.xxx.xxx:50995, disconnecting
ALSO:
Code:
2015-01-21 17:56:50 connection from xx.xxx.xx.xxx:35455 dropped (banned)   - Where the ip address here that I have masked with "x" is the ip of my local cold wallet machine.

All nodes, even ones that I have not tried to start yet still show in the masternode list. This might be because I only just updated though.

Any ideas? I was able to update to v.10 fine yesterday.


EDIT:

Right after I execute masternode start in the local wallet I see this in the log of the remote:

Code:
2015-01-21 18:06:55 dseg - Sent 585 masternode entries to xx.xxx.xx.xx:35644
2015-01-21 18:06:55 Misbehaving: xx.xxx.xx.xx:38717 (0 -> 100) BAN THRESHOLD EXCEEDED
2015-01-21 18:06:55 dseg - peer already asked me for the list
2015-01-21 18:06:55 mnget - Sent masternode winners to 69.xxx.xx.xxx:35644
 
Last edited by a moderator:

moocowmoo

Bovine Bit-flipper
Foundation Member
Jun 15, 2014
483
603
263
masternode.me
Dash Address
XmoocowYfrPKUR6p6M5aJZdVntQe71irCX
I just updated all my nodes to 11.0.11.
did you update your local wallet too?
v0.11.0.11 will only accept start signals from v0.11.0.11

You'll probably want to stop your nodes, delete peers.dat and restart them to get a fresh un-banned start too.
 

GilAlexander

Member
Jun 26, 2014
84
23
48
I got the same problem, but only on one node, not the others. Normally I dont look at debug.log, but this time I did so i noticed. The masternode also shows with a :1 like you described, but the debug log does not tell it was successfully activated, just this:
The same, tons of it. Log is 270mb after an hour.
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Nice Tools menu in this version where to find the Debug console:

upload_2015-1-21_13-55-41.png

In previous versions before v.110011:

upload_2015-1-21_13-57-14.png
 

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,335
571
283
Finland
After multiple attempts to get my MN:s online after v11 update, i give up and MN:s can have a day off.

Local say started succesfully, but remote is still offline.
 

italx

Well-known Member
Foundation Member
Jul 31, 2014
65
52
158
California
did you update your local wallet too?
v0.11.0.11 will only accept start signals from v0.11.0.11

You'll probably want to stop your nodes, delete peers.dat and restart them to get a fresh un-banned start too.
Yep. local wallet is .11 Mac. Updating that was the 1st thing I did. Deleted peers.dat on all locals and MNs. Even tried doing a full restart on two of the nodes, no change in behavior.
Nodes are now dropping off the masternode list, which makes sense it's been just over an hour. So they are definitely not active
 

moocowmoo

Bovine Bit-flipper
Foundation Member
Jun 15, 2014
483
603
263
masternode.me
Dash Address
XmoocowYfrPKUR6p6M5aJZdVntQe71irCX
Yep. local wallet is .11 Mac. Updating that was the 1st thing I did. Deleted peers.dat on all locals and MNs. Even tried doing a full restart on two of the nodes, no change in behavior.
Nodes are now dropping off the masternode list, which makes sense it's been just over an hour. So they are definitely not active
odd. is behaving like it's a protocol mismatch. do 'getinfo' in your local and remote and verify these two values match:

Code:
"version" : 110011,
"protocolversion" : 70054,
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
All my MNs decided to take a lunchbreak and leave their deamons still running. Thankfully start-many makes whipping them all back to their slavepits a speedy procedure. No unusual spikes in the stats, they just sloped off.

Some easily grepped marker added to the debug.log like 'MN stopped!' would be handy, if such a thing could be incorporated.
 

italx

Well-known Member
Foundation Member
Jul 31, 2014
65
52
158
California
odd. is behaving like it's a protocol mismatch. do 'getinfo' in your local and remote and verify these two values match:

Code:
"version" : 110011,
"protocolversion" : 70054,
Yes correct values on both. I can't spend anymore of my workday trying to troubleshoot, bummer. I'll check back in later.

EDIT: Keep in mind I'm getting "Successfully started Masternode' in the local wallet. So at least from that end it thinks it's working.
 
  • Like
Reactions: coingun