Earlier quoted context omitted.
> This is still unfair to stakers that legitimately have infra disruptions. I'd hardly characterize that as "unfair"; it's no more unfair than any other perceived correlation between uptime and trustworthiness. > The problem space fundamentally requires human intervention at a high level. It fundamentally requires the opposite. The more human intervention possible, the more room for exploitation and corruption and un…
>it's no more unfair than any other perceived correlation between uptime and trustworthiness. I am saying that correlation inherently makes no sense. Uptime isn't the same as trustworthiness, that assumption is only made because designers of blockchain algorithms have bizarrely decided that "trustworthiness" is not a real thing so they need to continuously look for other things to use as a substitute for it, instead…
The former is pretty darn important for the latter. How can I trust something that is prone to outages?
> You are creating a system for humans to use for human purposes. The entire point of it is human intervention.
One does not follow from the other.
> When designing these blockchain algorithms (which I should remind you are designed and maintained by humans as code that needs to be continuously maintained by humans) all that happens is you encode that particular form of exploitation and corruption and unfairness into the system itself.
Well then it's a good thing that code is available to the general public and can be audited by the general public.
> Even within your example it's wrong; discriminating against those with bad uptime enables exploitation and corruption towards areas that have bad infra.
The correct response would be to improve infra in those areas, or for people in those areas to use one of the umpteen gajillion VPS providers in the world to run their stake pools instead of trying to do so from their closets.
> And remember since this is code that can be updated and changed by humans it will be vulnerable to the same level of corruption that you see anywhere else. You might trust the maintainers not to do this but now you're back to the same old trustworthiness again.
Then it's a good thing that the code in question is open to audit by the general public and that new versions of the code require consent from the network before they actually go "live" in any meaningful sense.