Post
Topic
Board Development & Technical Discussion
Re: A(nother) downside to Proof-of-Stake?
by
work2heat
on 01/11/2014, 01:35:42 UTC
As andytoshi points out, all of these analyses are complicated by the specific model assumptions and therefore the different systems are not necessarily directly comparable. However, it would be interesting to work towards a formal proof under a standard bitcoin model that shows PoW is the only way to achieve secure consensus.

I'm still not completely convinced this is true, though. So long as the protocol is entirely self-contained, perhaps, but supposing we can rely on "reflecting" the consensus off reality (through social networks and other media), I think we can actually solve this in the real world.

The main issue with PoS is so-called nothing at stake. Slasher can mitigate this effectively for its temporal range (Vitalik likes 3000 blocks), but is subject to long-range attacks. Long-range attacks can be mitigated by check-pointing, so the problem becomes one of secure check-pointing (say every 3000 blocks). One approach would be a proof-of-work based checkpointing mechanism in an otherwise fully proof-of-stake system. The PoS people probably won't like that, and it could be very dangerous (I literally just thought of it). The other approach is stake based check-pointing on chains of progressively higher security (where security is effectively measured by the size of the security deposits that must be put up to be eligible for signing/checkpointing). So the question can be reduced further to one of secure-checkpointing on the most secure chain (we are assuming here an interweb of chains, where lower security chains checkpoint on higher security chains). The highest security chain then checkpoints against the real world, by literally broadcasting hashes on facebook and twitter and so on.

It's a little ridiculous, but it has an interesting appeal in that in brings the consensus full circle by embedding it back in reality. Of course it already is semi embedded in reality due to the nature of software development (clients are not developed according to a protocol, they are made by humans who do their best, but are not infallible).

Either way, it will be interesting to see this field play out!

As to your original question, hardware devices that do not export keys but simply allow inputs to be signed and spit those out can mostly mitigate your concern. Stay tuned!