That doesn't work with the "fake nice" problem I was talking about. Witnesses have the same problem, they are afraid to make their own decision as you will lose witness votes if you don't conform to the decisions made by the top 20. There are other issues at play as well.
Not quite that simple. Top witnesses participate in a secret slack and are all on board with whatever goes on in there. I just know of it... I've not seen it, nor been invited to it.
The new code can be deployed and the fork accepted by a super-majority of the top-20 witnesses. The rest of the witnesses do not factor into it. If those witnesses outside of the top-20 do not then upgrade to the new fork, they will effectively become defunct.
So, sure - anyone can review the code. But if the people in the top-20 are going to blindly accept it anyway, there's nothing that the rest of the witnesses can do. You either go along with it or shut down your node.
And if you're in the secret Slack, you play by Ned's rules or you're ousted. So...guess what those people decide to do?
Yes, @ats-david had a very in depth post on his blog about his concerns that I really didn't see elsewhere. I was surprised he was one of the tiny few.
There are too many lines of code to look for oddities... It's humanly impossible to study.
This is correct when there are massive updates that are backed up for over 18 months and pushed out by the devs as a blob. It is not the case when there are smaller targeted updates (such as the one release a few months ago to address some json spamming attack). The latter are more closely scrutinized by witnesses (not all of whom, but some of whom, have a software development background and are capable of reviewing code to a reasonable degree). Carefully reviewing and second guessing 18 months of design and development work that occurs largely behind a private and opaque process just isn't possible.
Either we flat out reject the release and insist that it be (re)packaged in small bite size pieces to be individually approved (and indeed a minority of witnesses is strongly in favor of this approach) or, absent some known, identified reasons to reject it (for example, stability considerations prompted by the recent crash was seen as such as reason by a minority of witnesses) or we pass it through on the basis of assuming that the dev team is competent. (If they are not, then the Steem community ought to be seriously working to replacing or restructuring it). All of which needs to be considered as a tradeoff between conservatism and 'best practices' on the one hand and the practical consideration of availability of upgraded features on the other (and numerous devs and community members were communicating to witnesses how important many of these upgrades were perceived to be, representing a clear incentive to get them rolled out).
Mostly, things are working now, and the upgrade glitches lasted about 1 day (exchange downtime is fully up to the exchanges, and nothing prevents them from being up; the necessary fixes was released to them yesterday). Whether getting the feature improvements out in deployment was the right call relative to stability risk will be something that time will tell.
Yes, I agree. I'm going to be looking at changing my witness votes around significantly (but does it even matter when @freedom can strong arm anyone it wants into the top 20?)
Someone who has millions and millions of dollars worth of Steem at stake should have a much bigger say than you. However, your votes absolutely do count (just not to the same degree, as it should be), so please use them.
Of course that makes sense. And yeah, I always use all 30 of my votes. Shifted them around quite significantly today, too, based on what I observed during the past couple of weeks.
I wish we could revisit some of the suggestions made in this post from 10 months ago where @steemitblog asked for input, and then seemingly very few or none of them were implemented.
I especially liked the idea of an adjustable slider for curation % on posts. If not that, I believe an increase in general is needed, either to 33.33%, 37.5%, or 50%.
As with everything there are tradeoffs. Community input is great, but at the same time a full time dev team has its own (hopefully) coherent vision on how the system should evolve. Possibly, such a coherent vision is preferable to a hodgepodge of (even individually good) ideas. Some community-sourced ideas can be implemented without disrupting a development roadmap, but not necessarily all.
If you feel strongly that the approach being taken is the wrong one then please continue to express that (including via witness votes, but not only that).
Yeah, I know what you mean. But, with all due respect, what we have now comes off as a hodge-podge of random ideas thrown together. Devs aren't renowned for their social skills, but it would be nice if there was a whole liaison team that tried to convey that vision to the overall Steemit community, not just @andrarchy. Maybe then it would seem more cohesive.
I guess a major difficulty in the whole thing is that it's hard to bridge the gap between programmer knowledge and concepts a layman can understand. Nonetheless, I'll keep doing my best to try to grasp why things work the way they do and keep questioning if they really ought to be that way. Thanks @smooth.
Speaking of shifting witness votes around, I have not been able to unvote witnesses for months now. Once I vote for a witness, trying to unvote them just makes the upvote icon spin for hours without actually unvoting them.
Yes, I'm logged in with my active key,
Do you have any idea how to fix this? I've contacted github about it an never got a response.
@freedom uses @pumpkin as witness voting proxy. For the top 20 witnesses, @pumpkin voted 17. Without @pumpkin's vote, 13 witnesses won't be in top 20.
The conclusion is our votes do not make difference.
Slowly getting through the debates here and... please consider @stem.witness - the brand new witness from @steemSTEM. We have a new Standalone app on the way and an unimaginable amount of stuff coming up!
That doesn't work with the "fake nice" problem I was talking about. Witnesses have the same problem, they are afraid to make their own decision as you will lose witness votes if you don't conform to the decisions made by the top 20. There are other issues at play as well.
Not quite that simple. Top witnesses participate in a secret slack and are all on board with whatever goes on in there. I just know of it... I've not seen it, nor been invited to it.
I don't know what that has to do with reviewing the code before deploying it? Maybe you can explain.
The new code can be deployed and the fork accepted by a super-majority of the top-20 witnesses. The rest of the witnesses do not factor into it. If those witnesses outside of the top-20 do not then upgrade to the new fork, they will effectively become defunct.
So, sure - anyone can review the code. But if the people in the top-20 are going to blindly accept it anyway, there's nothing that the rest of the witnesses can do. You either go along with it or shut down your node.
And if you're in the secret Slack, you play by Ned's rules or you're ousted. So...guess what those people decide to do?
Actually, I've mentioned you twice this morning. I saw that you actually posted and discussed your concerns. I think that was the right thing to do.
Even if I don't always agree with all you say and do, you acted with integrity on this one.
Yes, @ats-david had a very in depth post on his blog about his concerns that I really didn't see elsewhere. I was surprised he was one of the tiny few.
There are too many lines of code to look for oddities... It's humanly impossible to study.
The only way to test it, is to run data through it. Not just "live" data as @timcliff mentioned in a previous reply to me.
(Apparently testnet gets live data sent to it, the same data flowing in the steem mainnet)
...but tainted data. Horribly corrupt data. Throw everything at it.
This is correct when there are massive updates that are backed up for over 18 months and pushed out by the devs as a blob. It is not the case when there are smaller targeted updates (such as the one release a few months ago to address some json spamming attack). The latter are more closely scrutinized by witnesses (not all of whom, but some of whom, have a software development background and are capable of reviewing code to a reasonable degree). Carefully reviewing and second guessing 18 months of design and development work that occurs largely behind a private and opaque process just isn't possible.
Either we flat out reject the release and insist that it be (re)packaged in small bite size pieces to be individually approved (and indeed a minority of witnesses is strongly in favor of this approach) or, absent some known, identified reasons to reject it (for example, stability considerations prompted by the recent crash was seen as such as reason by a minority of witnesses) or we pass it through on the basis of assuming that the dev team is competent. (If they are not, then the Steem community ought to be seriously working to replacing or restructuring it). All of which needs to be considered as a tradeoff between conservatism and 'best practices' on the one hand and the practical consideration of availability of upgraded features on the other (and numerous devs and community members were communicating to witnesses how important many of these upgrades were perceived to be, representing a clear incentive to get them rolled out).
Mostly, things are working now, and the upgrade glitches lasted about 1 day (exchange downtime is fully up to the exchanges, and nothing prevents them from being up; the necessary fixes was released to them yesterday). Whether getting the feature improvements out in deployment was the right call relative to stability risk will be something that time will tell.
Exactly what I thought when I read that last pre HF20 post by Steemitblog.
Cg
Yes, I agree. I'm going to be looking at changing my witness votes around significantly (but does it even matter when @freedom can strong arm anyone it wants into the top 20?)
Someone who has millions and millions of dollars worth of Steem at stake should have a much bigger say than you. However, your votes absolutely do count (just not to the same degree, as it should be), so please use them.
Of course that makes sense. And yeah, I always use all 30 of my votes. Shifted them around quite significantly today, too, based on what I observed during the past couple of weeks.
I wish we could revisit some of the suggestions made in this post from 10 months ago where @steemitblog asked for input, and then seemingly very few or none of them were implemented.
I especially liked the idea of an adjustable slider for curation % on posts. If not that, I believe an increase in general is needed, either to 33.33%, 37.5%, or 50%.
As with everything there are tradeoffs. Community input is great, but at the same time a full time dev team has its own (hopefully) coherent vision on how the system should evolve. Possibly, such a coherent vision is preferable to a hodgepodge of (even individually good) ideas. Some community-sourced ideas can be implemented without disrupting a development roadmap, but not necessarily all.
If you feel strongly that the approach being taken is the wrong one then please continue to express that (including via witness votes, but not only that).
Yeah, I know what you mean. But, with all due respect, what we have now comes off as a hodge-podge of random ideas thrown together. Devs aren't renowned for their social skills, but it would be nice if there was a whole liaison team that tried to convey that vision to the overall Steemit community, not just @andrarchy. Maybe then it would seem more cohesive.
I guess a major difficulty in the whole thing is that it's hard to bridge the gap between programmer knowledge and concepts a layman can understand. Nonetheless, I'll keep doing my best to try to grasp why things work the way they do and keep questioning if they really ought to be that way. Thanks @smooth.
Likewise thanks for the discussion.
Speaking of shifting witness votes around, I have not been able to unvote witnesses for months now. Once I vote for a witness, trying to unvote them just makes the upvote icon spin for hours without actually unvoting them.
Yes, I'm logged in with my active key,
Do you have any idea how to fix this? I've contacted github about it an never got a response.
Hmmm, that's very odd. I've never heard of that and don't know of a fix, but let me ask around @luzcypher.
@freedom uses @pumpkin as witness voting proxy. For the top 20 witnesses, @pumpkin voted 17. Without @pumpkin's vote, 13 witnesses won't be in top 20.
The conclusion is our votes do not make difference.
Woah
Ouch!
Slowly getting through the debates here and... please consider @stem.witness - the brand new witness from @steemSTEM. We have a new Standalone app on the way and an unimaginable amount of stuff coming up!