A very quick look at ripple leads to my following interpretation.

"ripple is voting with a consensus level of 80%, so it can tolerate byzantine failure of 20% of all nodes". My question is then, how does this deal with sibyl attacks. That is, how does it prevent me from just creating a large amount of participants. Similarly, what happens when nodes 'leave' the system.

Say we have 200 nodes, then the consensus level is 160 nodes. What happens when 10 nodes stop responding? Are we forever stuck with the consensus level of 160 or does it ever drop to 152 nodes? In the first case, we are inevitably careening towards faulty nodes forming 20% of all required votes. In the second, we can enforce consensus by censoring other nodes.

I absolutely do respond to alternatives to proof of work in my post, thank you very much! And I agree that they may be valuable, but I'm skeptical, and you can reread my post to see why. And, by the by, the DDOS argument is a strawman, because we already survive DDOSes in services every day.

You're right, you do mention proof of stake and dismiss it quickly. There is also delegated proof of stake, where validators can elect a leader without needing a proof of work arms race.

But you should really look at Ripple's consensus and study it:

https://ripple.com/build/xrp-ledger-consensus-process/

As well as HashGraph. Both of these do NOT require proof of work!

But in any case I think consensus is the wrong long term goal for technology powering currencies and other things. See my other comment in this thread regarding that (https://news.ycombinator.com/item?id=15646385)