RC3 Soft Fork

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

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.
 
rango said:
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.
Click to expand...
+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 :)
 
rango said:
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.
Click to expand...
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???
 
TanteStefana said:
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???
Click to expand...
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:
 
Red-Shinobi said:
-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 :)
Click to expand...
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.
 
donho said:
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?
Click to expand...
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:
 
donho said:
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:
Click to expand...
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.
 
fernando said:
donho said:
donho said:
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?
Click to expand...

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

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

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:
 
You must log in or register to reply here.
Back
Top