Good discussion about the pros and cons of proof of stake vs proof of work in these articles and the comments:
https://medium.com/@hugonguyen/proof-of-stake-the-wrong-engineering-mindset-15e641ab65a2 …
https://medium.com/@hugonguyen/proof-of-stake-private-keys-attacks-and-unforgeable-costliness-the-unsung-hero-5caca70b01cb …
via @hugohanoi
“When there is a fork, an external process can determine the blame by requiring each validator to justify all of its round votes.” Couple of problems with this:
-
-
a/ This “external process/governance” is incredibly hard to scale & much less robust than PoW. Think about pausing a multi-billion dollar blockchain for days/weeks to “determine the blame”.
@NickSzabo4 also has something to say about this:https://twitter.com/nickszabo4/status/956461360161935361 … -
b/ You’re naively assuming there’s always a “bad” actor to be blamed. Chain splits could occur due to network partition/outage (see my Part 1). Who’s to say who’s good / bad when there’s an unintentional partition? Or multiple partitions (say, US, Europe & China all got split)?
-
Stop right there, you don’t have a clue about Tendermint.
-
lol dude I'm taking quotes straight out of your link
How about provide an actual argument or point out how I misunderstood Tendermint? do you deny that your "external process" requires pausing the chain for an undetermined amount of time, and assumes that 1/3+ must be "bad"? -
I gave you all the resources you need, maybe you should read the spec or whitepaper, esp Ethan Buchman's thesis. I could keep spoon feeding you facts about Tendermint, like how it doesn't fork with merely a network partition, but it's time you start chewing your own food.
-
> and assumes that 1/3+ must be "bad"? // That's not an assumption, that's just a result of the facts of the consensus algorithm. It says that a fork won't happen if +1/3 *aren't* bad. You've completely misunderstood even the most basic logical statement about BFT/Tendermint.
-
Ok I re-read, so Tendermint won't fork in the case of a network partition taking away 1/3+ of the active validator set, because you simply choose to HALT the chain instead of continuing on with the forks. (I admit I don't always remember which PoS implementation does what).
-
But by choosing to halt, you’re just trading one problem for another. If you would have chosen liveness instead, then you’ll have a problem with (b), but now instead of (b) your chain faces the risk of regularly starting & stopping.
- 9 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
