3 ms·

>Which is itself possible by penalizing stake pools that go offline, thus motivating them to maximize uptime. This is still unfair to stakers that legitimately

>Which is itself possible by penalizing stake pools that go offline, thus motivating them to maximize uptime. This is still unfair to stakers that legitimately have infra disruptions. I have not seen any design for PoS that is actually fair and reasonable and I doubt it will ever happen because this is simply not something you want to just put in an algorithm. The problem space fundamentally requires human intervention at a high level.

yellowapple 4y ago
> 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 unfairness. This is evident both within the crypto space (Safemoon comes to mind) and outside of it (the legacy financial system comes to mind).
- hnthrow1010 4y ago
  >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 of just using what most people (including many promoters of cryptocurrencies in their real, physical lives) use: trustworthiness. >It fundamentally requires the opposite. No, this is extremely, extremely, extremely wrong on every possible level. Even from the perspective of a cryptocurrency, this is extremely wrong. I can't stress this enough. You are creating a system for humans to use for human purposes. The entire point of it is human intervention. 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. Even within your example it's wrong; discriminating against those with bad uptime enables exploitation and corruption towards areas that have bad infra. 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.
  - yellowapple 4y ago
    > Uptime isn't the same as trustworthiness 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.

yellowapple 4y ago

> 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 unfairness. This is evident both within the crypto space (Safemoon comes to mind) and outside of it (the legacy financial system comes to mind).

hnthrow1010 4y ago
>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 of just using what most people (including many promoters of cryptocurrencies in their real, physical lives) use: trustworthiness. >It fundamentally requires the opposite. No, this is extremely, extremely, extremely wrong on every possible level. Even from the perspective of a cryptocurrency, this is extremely wrong. I can't stress this enough. You are creating a system for humans to use for human purposes. The entire point of it is human intervention. 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. Even within your example it's wrong; discriminating against those with bad uptime enables exploitation and corruption towards areas that have bad infra. 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.
- yellowapple 4y ago
  > Uptime isn't the same as trustworthiness 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.