v0.11.0 - Darkcoin Core Release

[Walter]

Why should I update my masternodes to a version that I know to be unstable? If I have x masternodes running perfectly well, why should I upgrade them to a version that seemingly kills them once or twice a day? Fingers crossed 11.10 has resolved this...people will start to update then.

EDIT: Why do you think old versions aren't booted from the network? Just in case the new version doesn't work?

I have to agree to an extent. I've always diligently updated my MNs as soon as the latest versions are available. Sadly, all it seems to bring me is hassle and lost MN payments... Of course, the reason I stick to my policy of updating ASAP is because I want to 'do the right thing' for the good of the network. However, it must have cost me at least 25DRK of lost MN payments over the last six months. Small beer some may say but I can quite easily see how a less altruistic MN owner may look at such a situation and take the view that updating is costly and should be avoided if at all possible...!

It's a tricky situation...

Walter

 

[Raico]

Why should I update my masternodes to a version that I know to be unstable? If I have x masternodes running perfectly well, why should I upgrade them to a version that seemingly kills them once or twice a day? Fingers crossed 11.10 has resolved this...people will start to update then.

EDIT: Why do you think old versions aren't booted from the network? Just in case the new version doesn't work?

Take it easy~ You know what i mean. And you are definitely have right to update or not. It's your Freedom. On the other hand, hat off to the ppl who update their MN on main net and contribute to the WHOLE Darkcoin network.


Edit:
btw, i own some MN on my hand to operate directly and some on flare's service. I appreciate that flare's professional service that try to protect the clients' interest by only updating from stable to stable. And i just update my side MN in every single version that release by the Dev.team. I think it's a way to show my support to their hard work.

 

[stonehedge]

I have to agree to an extent. I've always diligently updated my MNs as soon as the latest versions are available. Sadly, all it seems to bring me is hassle and lost MN payments... Of course, the reason I stick to my policy of updating ASAP is because I want to 'do the right thing' for the good of the network. However, it must have cost me at least 25DRK of lost MN payments over the last six months. Small beer some may say but I can quite easily see how a less altruistic MN owner may look at such a situation and take the view that updating is costly and should be avoided if at all possible...!

It's a tricky situation...

Walter

Now that I use a masternode hosting service I trust the judgement of that service on when they update my masternodes.

I don't really care about lost DRK, I care about testnet being improved so that this isn't even an issue. I decided to use a masternode hosting service when I was eating up into family time repeatedly updating my masternodes around release dates.

I appreciate that it is almost impossible to create a realistic test environment in testnet but surely there are improvements to be made to reduce the number of on the fly updates we see once a release hits main net?

 

[thelonecrouton]

Evan has mentioned that IX will be coming as part of a true Proof of Service implementation. Hopefully those nodes unable to prove their service compliance will be penalised.

Could every running client (regular users, MN ops, pools) check for the latest version and then if needed:
1. Issued a warning to the user: 'This software is deprecated old and must be updated within 48hrs or it will cease to work.'
2. Cease to work after 48hrs.

I have mentioned checksums a few times. Is it possible for the client to verify itself as unmodified? Isn't that how a lot of games prevent cheating? Could we learn something from the gaming industry? - Run the right software or you don't get to play. Surely someone somewhere has already solved this problem?

Or clients are required to obtain verification from (up to date) Masternodes?

Running a Masternode is a job, it requires a commitment. That's why you get paid. Most jobs don't continue to pay you if you don't turn up/don't do the work...

 

[stonehedge]

Evan has mentioned that IX will be coming as part of a true Proof of Service implementation. Hopefully those nodes unable to prove their service compliance will be penalised.

Could every running client (regular users, MN ops, pools) check for the latest version and then if needed:
1. Issued a warning to the user: 'This software is deprecated old and must be updated within 48hrs or it will cease to work.'
2. Ceased to work after 48hrs.

I have mentioned checksums a few times. Is it possible for the client to verify itself as unmodified? Isn't that how a lot of games prevent cheating? Could we learn something from the gaming industry? - Run the right software or you don't get to play. Surely someone somewhere has already solved this problem?

Or clients are required to obtain verification from (up to date) Masternodes?

There are a number of problems that need addressing and if you arrange them into a hierarchy, the one that needs fixing first is main net release stability rather than enforcing updates onto potentially unstable releases. If 90% of our main net releases were stable then people would update quickly. Main net should never be used for testing intentionally or not.

This is weird. I'm off to work now to have pretty much the same discussion about a faulty release.

 

[crowning]

Could every running client (regular users, MN ops, pools) check for the latest version and then if needed:
1. Issued a warning to the user: 'This software is deprecated old and must be updated within 48hrs or it will cease to work.'
2. Ceased to work after 48hrs.

A lot of Masternode-owners never see a client or the output of their Masternodes.

I have mentioned checksums a few times. Is it possible for the client to verify itself as unmodified? Isn't that how a lot of games prevent cheating? Could we learn something from the gaming industry? - Run the right software or you don't get to play. Surely someone somewhere has already solved this problem?

I have a gamer-friend who hates the online-registration stuff. He always buys the games and waits until a no-internet, no-steam, no-you-name-it patch is available before he plays.
He never has to wait long...

 

[Walter]

That's the problem though... I turn up, do the job, then don't get paid - whereas the guy who doesn't show up keeps getting nice fat MN payments! :tongue:

 

[thelonecrouton]

A lot of Masternode-owners never see a client or the output of their Masternodes.

That can be changed. And if the damn thing just shut itself down because it wasn't fit for work any more the operator might start to pay some attention.

I have a gamer-friend who hates the online-registration stuff. He always buys the games and waits until a no-internet, no-steam, no-you-name-it patch is available before he plays.
He never has to wait long...

Understood, but that doesn't mean that no effort should be made at all. Most of the useless DRM crap is imposed by publishers, not the game coders...

This is a currency, allowing anyone who pleases to bugger things up at will isn't a realistic approach.

 

[thelonecrouton]

There are a number of problems that need addressing and if you arrange them into a hierarchy, the one that needs fixing first is main net release stability rather than enforcing updates onto potentially unstable releases. If 90% of our main net releases were stable then people would update quickly. Main net should never be used for testing intentionally or not.

This is weird. I'm off to work now to have pretty much the same discussion about a faulty release.

I agree, it's probably not the top priority right now, I'm just voicing some notions.

 

[jpr]

Refusing to update the nodes is not helping us. Evan is the lead dev and this is the way he works. I can sacrifice 10 min a day to update my nodes even if I might loose a payment or 2, because my goal is not a few $ but to get thousands out of it. What is Evans motivation going to be if he see people refusing to cooperate.
Now I do understand and agree we need a bigger stronger testnet but as for now we do not have it and we should do as devs ask.
Peace.

 

[stonehedge]

Refusing to update the nodes is not helping us. Evan is the lead dev and this is the way he works. I can sacrifice 10 min a day to update my nodes even if I might loose a payment or 2, because my goal is not a few $ but to get thousands out of it. What is Evans motivation going to be if he see people refusing to cooperate.
Now I do understand and agree we need a bigger stronger testnet but as for now we do not have it and we should do as devs ask.
Peace.

What would have happened if everybody updated to 11.0 within 30 minutes of release?

 

[thelonecrouton]

What would have happened if everybody updated to 11.0 within 30 minutes of release?

There would have been less grief from older versions pushing conflicting data.

I think it is remarkable just how much backwards-compatability Evan has maintained given the pace of development. I'm just opining that at some point you need to stop wasting time on the laggards and move on, because some people will never update unless they absolutely have to - for example a lot of the mining pools when MN payments were unenforced.

 

[stonehedge]

That I do agree with.

 

[flare]

There would have been less grief from older versions pushing conflicting data.

To be honest: If "conflicting data" is giving v11 problems (forks, crashes, stuck), the problem is v11 - not the conflicting data.

I think it is remarkable just how much backwards-compatability Evan has maintained given the pace of development. I'm just opining that at some point you need to stop wasting time on the laggards and move on, because some people will never update unless they absolutely have to - for example a lot of the mining pools when MN payments were unenforced.

Sounds like Microsoft policy, deprecating stable (old) versions in favor of unstable new ones^^

 

[thelonecrouton]

To be honest: If "conflicting data" is giving v11 problems (forks, crashes, stuck), the problem is v11 - not the conflicting data.

Fair point. - and why we should have more structured testing, with a testnet that deliberately mimics a fractured mainnet.

Sounds like Microsoft policy, deprecating stable (old) versions in favor of unstable new ones^^

I don't think that's a fair comparison. Microsoft do this for obvious financial reasons. That's not the motivation here.

 

[flare]

I don't think that's a fair comparison. Microsoft do this for obvious financial reasons. That's not the motivation here.

Point taken

But i prefer not to force people to update to an unstable version, as this will put the whole network at risk. If v11 is mature Evan can change the enforcement so that only recent protocol nodes get paid. This is how it worked for v10 and v9 anyway - only difference that we now see old versions in the stats. v9 and v10 always started from scratch.

 

[Lukas_Jackson]

It looks like Darkcoin became a Rainbowcoin

 

[stonehedge]

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?

 

[flare]

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?

More hands on deck - remember v11 was a huge release, leaving Litecoin codebase behind, adding 1000+ commits to Darkcoin codebase to catch up with Bitcoin. We should have made myriads of regression tests...

 

[stonehedge]

Would the right person be able to devise test plans and scripts that could be split and delegated to individuals on a testing team to cover the myriads of regression tests?

One of the greatest strengths of Darkcoin is the pace of development but this has come with a reduction in quality imho.

EDIT:

Approval Process (thus diversifying testing and spreading the authority to decide upon a release):

Regression testing --> Service Readiness Review Stage 1 --> UAT --> SRR Stage 2 --> Change Advisory Board --> RELEASE

 

[stonehedge]

How about something like this? Sorry it is messy, I only have Visio 2003 on this PC and I'm in between meetings. I've deliberately not included decision gates or made assumptions on who would make up the various groups/teams. I've also omitted Quality Management but other than that its pretty much straight up ITIL V3 nuts and bolts.

 

[elbereth]

Just for the record... 3 of my nodes (not mns) died (again) tonight.

I have to restart them every day since v11.

My debug logs are available if needed...

 

[flare]

Just for the record... 3 of my nodes (not mns) died (again) tonight.

I have to restart them every day since v11.

My debug logs are available if needed...

Same here, v11 is not stable, daemons keep on dying. That's why i did not update all customers yet...

 

[stonehedge]

Same here, v11 is not stable, daemons keep on dying. That's why i did not update all customers yet...

Flare, do you want to upgrade 12 of my masternodes to 11.10 so that we can monitor them closely? I don't mind being a crash test dummy...

 

[flare]

Flare, do you want to upgrade 12 of my masternodes to 11.10 so that we can monitor them closely? I don't mind being a crash test dummy...

Sure, will do - use at your own risk

 

[flare]

Just for the record... 3 of my nodes (not mns) died (again) tonight.

I have to restart them every day since v11.

My debug logs are available if needed...

Btw: The daemon which is running explorer.darkcoin.io seems to be stable, running it with disablewallet=1 - just in case you want to try

 

[stonehedge]

Sure, will do - use at your own risk

LOL, I'm sure it'll be fine. I'll start from local side at about 1800GMT.

 

[elbereth]

Same here, v11 is not stable, daemons keep on dying. That's why i did not update all customers yet...

Btw: The daemon which is running explorer.darkcoin.io seems to be stable, running it with disablewallet=1 - just in case you want to try

Will try that. I am also running one of them with strace in case I can find out why they die...

 

[HammerHedd]

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?

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

 

[flare]

Will try that. I am also running one of them with strace in case I can find out why they die...

Good stuff, i am seeing

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.