RE: Tron and Steemit Join Forces
It doesn't literally do that. Given the numbers, if you assume (probably incorrectly) that a Tron/Steemit bloc would have no other support, then it probably couldn't vote in 17 witnesses, and certainly would have a harder time doing so. But with even some additional support (which IMO is likely given marketing/campaigning/etc.), they could probably still do it. Pretty damn hard to come up with voting rules that block stake that is 50% larger than entire rest of the voting population. This isn't just trying to block a tiny majority (say 51%), it is trying to block a very significant supermajority.
In doing so you inevitably weaken the chain against smaller-stake attackers. Still, the compromise may be worth it.
I doubt it is that complicated, and it could be possibly be done.
Hmm,...I agree that stake will find friends willing to sell out.
We are playing crapitalism, after all, and easy money is the sweetest.
Am I wrong thinking that voting full sp on 30 witnesses is alot more than voting full sp divided by up to 30 witnesses?
Rather than voting 1m sp 30x, each vote is reduced by concurrent votes on more than one, 1m sp on one, 500k on two, 333k on three, etc.
I fail to see how this would empower small accounts in any attacks.
Currently in order to vote in any witnesses small stake has to overcome the full weight of all stake voting for the 20+ witnesses acceptable to the majority stake, so something like >50%.
If votes have to be split up then in a minority attack situation, the majority splits its votes across 20+ "good guys" and the minority need only achieve 1/20 (5%) of the majority voting power to vote in one malicious "bad guy" witness (not necessarily all that bad, but strictly speaking undesirable) and 7/21 (33%) to vote in enough to break BFT.
It might be good to resplit the governance and block production roles as was the case in Bitshares, each with slightly different rules. The governance roles might favor broader consensus while the block production roles favor tighter chain security. But I haven't thought this through sufficiently; it could open up other attacks or undesirable outcomes.
There are probably other undesirable effects to different voting systems apart from security too. If voting for another witness splits your votes then up-and-coming witnesses will have a much harder time getting votes at all Most voters will choose to either support one of the top 20 or maybe 21 or 22 trying to push them in. "Wasting votes" on #56 won't happen.
Hmm, can one bad witness harm the chain?
I see what you mean about that concentrating votes on very many fewer witnesses.
Looks like we just need JS to work with us rather than against us.
What do you see as a priority to improve about the chain?
What we have seems to be working as well as can be expected.
When do we go into coast mode on economics?
Clearly the harm that can be caused by one witness is small, even negligible (a bit of chain instability, a potentially-harmful but generally-overruled vote on hard forks, etc.). But what about two witnesses? Three? Four? Where do you draw the line?
Clearly at every increment (starting with zero) where more and more witnesses can be installed with less stake, the chain is less secure.
Yeah, I see that, but would think the community would catch on and gang tackle them.
How do you feel about down votes for witnesses and dead man switches on votes?
Downvotes may have some merit, I haven't thought enough about it. On the surface I like downvotes as being somewhat less prone to vote buying, self-voting, etc. We see that clearly with vote payouts and some of the same issues apply to witnesses. That being said, overall there are various angles that all need to be considered in evaluating a voting system (fairness, representation, abuse- and corruption-resistance, security, etc.) and it isn't a trivial effort.
If by dead man switches you mean some sort of vote expiration/decay, then I agree with it, though the devil is in the details. IMO the most clearly supportable version would have votes from completely idle accounts decay or just removed after some period of time, say two years. Other versions are plausible too, but the tradeoffs are less clear.
So no elections twice a year?
Vote anytime in between, but all votes expire in March and Sep?
I guess that may be disruptive.
I'll be glad when changes are mostly cosmetic.
What do you mean by elections twice per year?
You might be interested to know, Golos(Steem fork) has implemented the automatically started power down for accounts which did not used the active key for 6 month.
Why would they do that?
Dead man switches turn off legacy votes.
Active users should have priority, no.
It works very much like quoting @smooth