v0.11.0 - Darkcoin Core Release

HammerHedd said:
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
Click to expand...
Me :) already maintaining the instances of stonehedge and camosoul so drop me a PM
 
stonehedge said:
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?
Click to expand...

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.
 
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.
 
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.
 
So how many testnet masternodes do we need?
Is it like the more the better or is there a number that is enough?
 
jpr said:
So how many testnet masternodes do we need?
Is it like the more the better or is there a number that is enough?
Click to expand...

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.
 
flare said:
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.
Click to expand...

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!
 
stonehedge said:
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.
Click to expand...

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.
 
yidakee said:
...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...
Click to expand...

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...
 
yidakee said:
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!
Click to expand...

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.
 
oblox said:
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.
Click to expand...

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:
Had my wallet to run DS mixing the last 8 hours and just now it suddenly crashed for no reason.......
:sad:
 
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
 
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.
 
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 :)
 
TanteStefana said:
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 :)
Click to expand...
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.
 
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.
 
David said:
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.
Click to expand...
not if it's from Evan ;-)
 
You must log in or register to reply here.
Back
Top