• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

RC3 Soft Fork

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...
 
Last edited by a moderator:
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.
 
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
 
-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 :)
 
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.
 
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%.
 
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???
 
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.
 
Whatever it is, bring it on!! It is boring to be paid only once in a while :smile:
 
-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.
 
I don't know if someone has already suggested this. But I think a really nice feature for the next RC would be the option to set a payout address for the MN payments in the cold wallet.
So one has the option to set an address of a hot or another cold wallet to get the masternode payments send to.
To change the address one would obviously need to unlock the cold wallet with the 1000DRK once and then put in a payment address.
Once this is done you would only have to access the cold MN wallet if you want to access the 1000DRK. And you could manage the payments on another wallet.
Thoughts?
No one commented so far (but I got 2 likes) so I'll give myself a shameless selfquote as a last desperate cry for attention :wink:
 
No one commented so far (but I got 2 likes) so I'll give myself a shameless selfquote as a last desperate cry for attention :wink:
That idea is great, but I'm not sure it is that easy to implement. And not all MNs work with the hot/cold setup. Once everything is working perfectly I would definitely do it, but I would try not to include new complications until then.
 
I don't know if someone has already suggested this. But I think a really nice feature for the next RC would be the option to set a payout address for the MN payments in the cold wallet.
So one has the option to set an address of a hot or another cold wallet to get the masternode payments send to.
To change the address one would obviously need to unlock the cold wallet with the 1000DRK once and then put in a payment address.
Once this is done you would only have to access the cold MN wallet if you want to access the 1000DRK. And you could manage the payments on another wallet.
Thoughts?

No one commented so far (but I got 2 likes) so I'll give myself a shameless selfquote as a last desperate cry for attention :wink:

That idea is great, but I'm not sure it is that easy to implement. And not all MNs work with the hot/cold setup. Once everything is working perfectly I would definitely do it, but I would try not to include new complications until then.

I really like the idea - donho do you mind entering this as a 'enhancement' in the ticket system? That way we can keep track of all the feature requests and nothing passes under Evans' radar :wink:
 
Back
Top