4 ms·
> The fork starts from before the unstaking transaction. So what? The fork wouldn't be built on by anyone but the attacker. Any new entrant would have software
by billytetrud 5y ago
> The fork starts from before the unstaking transaction.
So what? The fork wouldn't be built on by anyone but the attacker. Any new entrant would have software that expects a blockchain being built substantially faster (or with substantially higher difficulty).
> you wouldn't have to reason it out if you had read the paper I linked.
I have read Peolstra's "pos.pdf" that PoS detractors incessently reference multiple times. The paper's conclusion is not correct. All the problems he presents are solvable at once (eg in this protocol: https://github.com/fresheneesz/validatedProofOfStake https://github.com/fresheneesz/validatedProofOfStake). He doesn't consider that hard coded checkpoints handily solve the problem of long-range revisions.
- kerkeslager 5y ago> Any new entrant would have software that expects a blockchain being built substantially faster (or with substantially higher difficulty). "Difficulty" isn't a thing in PoS. Provable random functions that choose validators always have fallbacks, because if they didn't, a single absent validator would bring the entire chain to a halt. Repeated fallbacks would look suspicious, so a smart attacker would simply neglect to include transactions from the real chain that transfer money or power away from addresses he controls, which would quickly lead to >50% ownership of the fake chain. It would be impossible to distinguish this on-chain from a real validator drop event (such as an AWS US1 East outage). > He doesn't consider that hard coded checkpoints handily solve the problem of long-range revisions. Hard-coded checkpoints do absolutely nothing to address this issue. If you're requiring that the checkpoints come from a trusted entity, you've just given up decentralization. If you're not requiring that they come from a trusted entity, then they can be spoofed just as easily as a block. Instead of reading a paper and immediately believing what it says, you need to try to think like an attacker and see how you would try to get around the "solution". There's likely not a paper written on this, because it's so trivial to get around that it really doesn't require a paper to refute. The fact that you presented this idea non-ironically seriously undermines your credibility. FWIW, I'm not a PoS detractor. I'm quite excited for Ethereum's implementation of PoS, because if anyone can solve the issues with PoS, it's the Ethereum team. My current thinking is very much in the "wait and see" camp. Weak subjectivity with PoS is a real thing (if you don't believe me, perhaps you should listen to Vitalik Buterin, who cannot be accused of being a "PoS detractor"). What remains to be seen is how much of a problem it is in practice. The release of Ethereum 2.0 will be the largest full-scale test of a mature implementation, but depending on how quickly full roll-outs of PoS happens for Cardano or Polkadot happen, one of them may get there first.
- billytetrud 5y ago> "Difficulty" isn't a thing in PoS Yes it is. The more people with coins actively minting in the system, the higher the difficulty of getting chosen. Please do more research. If you really want to keep discussing this with me, read through the WHOLE of https://github.com/fresheneesz/validatedProofOfStake https://github.com/fresheneesz/validatedProofOfStake and show me a full attack on it. > FWIW, I'm not a PoS detractor. You could have fooled me. But it sounds like you're saying you believe in Vitalik, and anyone else on the internet (ie me) must be idiots who can't understand solutions to these problems. Yet, you're not putting in the effort to understand the solutions out there. PoS protocols are more complex than PoW - there are more edge cases to shore up. So telling me you can "trivially" get around any particular solution ignores the fact that solutions work together. They aren't isolated. So slow down and actually try to understand a protocol holistically before attacking it. If you're not a detractor, than how about just trying to learn instead of insulting the intelligence of people who have actually worked on solutions to these problems?
- kerkeslager 5y ago> Yes it is. The more people with coins actively minting in the system, the higher the difficulty of getting chosen. I'm well aware. But eventually a large validator will get chosen--it's not difficult to get chosen, it's rare. The fact that PoS folks call this "difficulty" does not make it so. > If you really want to keep discussing this with me, read through the WHOLE of https://github.com/fresheneesz/validatedProofOfStake https://github.com/fresheneesz/validatedProofOfStake and show me a full attack on it. Given your proposed solution is checkpoints from a centralized trusted entity, you're giving up decentralization. Sure, your solution works. If you don't trust the source of the checkpoint, you're back to square one--it no longer works. And if you're willing to give up decentralization, may I suggest you just store all transactions in Postgres? You don't need a blockchain if you're just going to trust a centralized entity. I'm not going to give your design a free audit. If there's some way this isn't centralized, feel free to explain, otherwise, this isn't relevant--I think we can assume that PoS is being discussed in the context of decentralized, trustless models. > If you're not a detractor, than how about just trying to learn instead of insulting the intelligence of people who have actually worked on solutions to these problems? I haven't insulted your intelligence. You're probably a smart guy. Which is probably why you're overconfident in your solution: smart people aren't used to being wrong, so you aren't taking the time to actually grok the attack I've already proposed, or why the only working solution you've actually proposed depends on centralization. I did question your credibility to make claims here, because it's pretty clear you either don't understand the attack proposed by On Stake and Consensus, or you don't understand decentralization, which are both fundamental prerequisites to this discussion. The time constraints defense is literally in the paper, and the checkpoints solution you've proposed is just proof of authority by a different name. If you choose to feel insulted by someone saying you're wrong, that's your prerogative.