RC3 Soft Fork

[derk]

Bad players are either daft & greedy for the extra 20%, or just dont care, or do not check up on the Dark-news.
We cant really depend on "bad players" to start playing nice, for us to get going.

I cannot comment on technical details due to my ignorance of these things, unfortunately, but I wholeheartedly support the philosophy above.
The world of cryptocurrency is fast-moving, and there is no time to hang about while supposed members of the community get their acts together. As soon as it is technically possible DRK should forge ahead.

 

[jpr]

I cannot comment on technical details due to my ignorance of these things, unfortunately, but I wholeheartedly support the philosophy above.
The world of cryptocurrency is fast-moving, and there is no time to hang about while supposed members of the community get their acts together. As soon as it is technically possible DRK should forge ahead.

I know nothing about technicals but agree with yidakee and derk to go ahead if possible.

 

[yidakee]

I know nothing about technicals but agree with yidakee and derk to go ahead if possible.

I am certainly not proposing anything! I am not qualified enough for a properly formed opinion.
I trust Evan and the devs for that, they've got way better judgement than me, and the technical background.

I'm just putting "it out there" for debate and learning.

 

[flare]

We cant really depend on "bad players" to start playing nice, for us to get going.

I agree with you, nevertheless in the end its network concensus who defines who is "bad" or "good" - not a single checkpoint server. If that would be the case darkcoin is not decentralized anymore and heavily reliant on this central server. Not good.

Spork technology is no doubt a crucial stepstone to facilitate the process of changing the rules - but only as the final push. If the majority of players is still playing the old (bad) rules, enabling enforcement too early will not instantly change the behaviour of the bad players, but break the game (forks).

From my experience in real world IT projects you will run into trouble and fail if you only rely on technology to change processes. Never underestimate the communication with the people involved...

60% "good" players are not sufficient for me to start enforcing the rules for the other 40%, we should see at least 80% here to be on the safe side.

Just my 0.01DRK

 

[jpr]

What if we don't get 80% because the "bad guys" will not update? Any way to make them update?

 

[ozziecoin]

When enforcement is switched on, there will be forks, which is what the network is supposed to do: fork off the unknown pools.

 

[flare]

What if we don't get 80% because the "bad guys" will not update? Any way to make them update?

How do you convince people to change their mind?

 

[ozziecoin]

How do you convince people to change their mind?

I think we were lucky some of the multipools updated because it was not in their best interest. The unknown pools are unlikely to update, IMHO.
The random banning of some MNs is a little bit worrying though. Anybody know what is triggering it?

 

[yidakee]

How do you convince people to change their mind?

Will 100% orphaned blocks not be enough?

 

[HammerHedd]

Something to consider:
Right now, we are moving really quite fast with the push to get Darksend up and running in ts full glory. The X.X.X11.5 builds came out less than 24 hours ago, and the x.x.11.4 builds really only came out about 24 hours before that. Today is Saturday, and I am going to assume many people who work during the week will be able to sit down and read the many various threads on here and bitcointalk.
Personally, I think getting 60% compliance in 48 hours is pretty impressive, considering that although everyone has a stake in DRK, most of us have to make a living elsewhere. This was, in fact, the prime reason for the capability to "spork" when its needed rather than trying to hard fork at a particular time.
At some point the incentive to update needs to be enforced for pools and MNs. What is the incentive to run them? Well, to get additional DRK, of course. So if that stops happening, pool and MN owners will start trying to figure out what went wrong, and figure out that they need to upgrade.
In the meantime, many of the OPs in the developer threads still list x.x.11.4 as the current version. Can we get a single point of reference on here that matches bitcointalk? I like this board much better, but I had to go back to check the OP on bitcointalk to find out that we had a client upgrade.

 

[MykelSIlver]

For more than 8 days online with latest version no errors in any log. Still no payment. I guess I have no luck. https://elbzo.net/masternodes.html 80.240.140.196:9999 MN:
XrBXkgRuKUoJVVoWuPn75AHtSAFWSi7fED

 

[TanteStefana]

We've only been getting paid for 3 days?

I also haven't seen a payment in 2 and don't know if mine is running correctly or not. Could be miners have rolled back their changes or changed the payments to 0, I don't know, but eventually Evan will decide that it's running properly and have us switch on to enforcement More than anything, this needs to just work

 

[rango]

Anybody of you guys managed to move masternode payments out of the masternode wallet without disabling the masternode/touching the 1k deposit?

I like to do this using CLI on linux. Somebody already wrote it is possible using Qt wallet, but that's not really suitable for automatic handling. I suppose, there is no "coin control" available on linux wallet to do this?

Thank you!

 

[vertoe]

Anybody of you guys managed to move masternode payments out of the masternode wallet without disabling the masternode/touching the 1k deposit?

I like to do this using CLI on linux. Somebody already wrote it is possible using Qt wallet, but that's not really suitable for automatic handling. I suppose, there is no "coin control" available on linux wallet to do this?

Thank you!

you can do something like a shell script that checks if the balance is > 1000.1 DRK and if true, send out balance minus 1000.1 drk. This should leave the 1k masternode darkcoin untouched and you still have some reserve (.1) available for fees.

 

[MykelSIlver]

First payment received (after 9 days). Patience was the key.

 

[blackempress]

I was able to recover my private keys by reverse engineering the wallet and using a custom scalpel config to pull every instance off my hard drives. I then wrote a script to chop out the private keys put them in an array, convert the hex versions to each kind of of public key (compressed and not compressed) and found it within seconds.

I will write a more in depth guide and provide the tools I made open source to help anyone else who runs into the issues I did.

 

[TsuyokuNaritai]

Wow. Well done, that's awesome.

 

[fandarig]

blackempress
Nice to hear. But you and your friend(reddit) said you dumped all drk. So who cares...

 

[flare]

I had a look at the last 12hours (Block 93776 - Block 94056) on http://drk.poolhash.org/graph.html

Total generation: 280 Blocks
Paid blocks: 137 Blocks
Unpaid Blocks: 143 Block

This means there is still 51% of overall hashpower belonging to 'bad actors'.

I stand by my opinion: As long as bad actors account for that large amount of hashing power, enabling enforcement is dangerous - remember: 51% hashpower can even break bitcoin.
Sad that obviously the majority of miners are not interested in supporting the coin they mine.

Nice coincidence though that the masternode reward is actually 49% of the 20% expected as per now, very close to the 10% Evan originally had in mind

 

[David]

We've only been getting paid for 3 days?

I also haven't seen a payment in 2 and don't know if mine is running correctly or not. Could be miners have rolled back their changes or changed the payments to 0, I don't know, but eventually Evan will decide that it's running properly and have us switch on to enforcement More than anything, this needs to just work

Stef, El Presidente was kind enough to run my address against the block templates and show that I was successfully voted on, but just wasn't paid (bad actor pool).

Devs: It would be nice to get an idea of what the strategy is for getting compliance from the bad acting pools in order to finally enable enforcement. If you are unwilling to turn enforcement on before xx% comply, and bad actors are unwilling to comply without enforcement being on, then we have reached an impasse and all our technical developments will be for naught. What is the next step?

FWIW: My suggestion is that Evan edit the OP on bitcointalk and ONLY include the pools that are known to be "good actors." This may seem drastic, but human nature being what it is, many people aren't going to cut themselves out of 20% profit unless and until somebody compels them to.

 

[flare]

FWIW: My suggestion is that Evan edit the OP on bitcointalk and ONLY include the pools that are known to be "good actors." This may seem drastic, but human nature being what it is, many people aren't going to cut themselves out of 20% profit unless and until somebody compels them to.

I concur: Bad actors should not be promoted in the OP - but my feeling is that we actually don't know who these pool are ("pool_unknown_xx"). Maybe they are not even pools, but powerful mining grids/rigs...

 

[rango]

As flare said, 90% of the bad actors are unknown und unwilling to update. So you won't make anybody updating putting them on a blacklist etc. They simply don't care.

Enforcing also includes the possibility to set a new checkpoint. So we should announce enforcement beeing enabled "within next 24h". This will make 25% of the network hashrate upgrade instantly because they don't know the excact timepoint when their new blocks will be orphaned. So as 75% has correctly been upgraded, we are safe to proceed. Evan remotely setting a checkpoint will avoid wrong forks on updated clients.

 

[derk]

As flare said, 90% of the bad actors are unknown und unwilling to update. So you won't make anybody updating putting them on a blacklist etc. They simply don't care.
Enforcing also includes the possibility to set a new checkpoint. So we should announce enforcement beeing enabled "within next 24h". This will make 25% of the network hashrate upgrade instantly because they don't know the excact timepoint when their new blocks will be orphaned. So as 75% has correctly been upgraded, we are safe to proceed. Evan remotely setting a checkpoint will avoid wrong forks on updated clients.

+1
Let's shed a skin and grow

 

[Red-Shinobi]

-An announcement would get a chunk of miners to update.
-Devs could enforce for like 3 hours the first day, 6 hours the next, 9, and so on until 24 hours.

Just like how bars and clubs turn the lights out for a few seconds when "the partys over" a few hours of 100% block rejection will get those miners attention to update without going full blast on them...nudge em a little

We've got a fancy enforce button...it'd be a shame to only flip it once. Toggle that muth, show bad actors whos boss

 

[David]

As flare said, 90% of the bad actors are unknown und unwilling to update. So you won't make anybody updating putting them on a blacklist etc. They simply don't care.

Enforcing also includes the possibility to set a new checkpoint. So we should announce enforcement beeing enabled "within next 24h". This will make 25% of the network hashrate upgrade instantly because they don't know the excact timepoint when their new blocks will be orphaned. So as 75% has correctly been upgraded, we are safe to proceed. Evan remotely setting a checkpoint will avoid wrong forks on updated clients.

I like this a lot, actually!

P.S. I agree that a blacklist probably isn't workable due to the pool_unknowns. But an official white list, promoted in the OP, could go a long ways.

 

[JGCMiner]

I really think this is much more of a case of ignorance or laziness rather than maliciousness. If 51% of the network really disliked MN payments to the point of purposely mining the wrong blockchain then we would have heard from them before the previous two hard forks.

It was a ninja-spork and there hasn't been any PR since. People likely don't know or are too lazy to update so long as they are finding blocks. If Evan says "72 hrs before enforcement -- update or your blocks will be orphaned" I am very very sure that more than half will update. If for no other reason than 80% is better than 0%.

 

[TanteStefana]

It's probably greed, but even so, Evan knew this was how it was going to go. I *think* he was planning on studying what happens when blocks are rejected here in the wild so he can avoid unnecessary forking. There weren't enough variables in the testnet. So I have to assume there will be another update before anything is enforced, one that keeps "good players" from forking.

Well, that's how I thought I understood the plan, I might be totally off???

 

[David]

It's probably greed, but even so, Evan knew this was how it was going to go. I *think* he was planning on studying what happens when blocks are rejected here in the wild so he can avoid unnecessary forking. There weren't enough variables in the testnet. So I have to assume there will be another update before anything is enforced, one that keeps "good players" from forking.

Well, that's how I thought I understood the plan, I might be totally off???

I'm thinking you're probably right. I've been expecting another client update soon as well.

 

[fernando]

Whatever it is, bring it on!! It is boring to be paid only once in a while

 

[fusecavator]

-An announcement would get a chunk of miners to update.
-Devs could enforce for like 3 hours the first day, 6 hours the next, 9, and so on until 24 hours.

Just like how bars and clubs turn the lights out for a few seconds when "the partys over" a few hours of 100% block rejection will get those miners attention to update without going full blast on them...nudge em a little

We've got a fancy enforce button...it'd be a shame to only flip it once. Toggle that muth, show bad actors whos boss

I like this. Random enable and disable totaling 8 hours of enforcement per day would cause the bad pools to earn less, as 30% of their blocks would be rejected, more than offsetting the gain they get on the ones that do.