Following along with my rebuttal to Dan (I do not have a steem account and so cannot post there):
Dan：anyone can sync BTS and STEEM faster than they can sync ETH it seems clear to me that his statement is fundamentally wrong.
Really? You can sync an ethereum node in a few minutes with parity. Also, even if this is true now, it will absolutely stop being true if it ever gets to processing thousands of transactions per second.
Dan：Ethereum light-clients have to trust the block producers calculated things properly because they only check the hashes not the logic.
It's possible to create light clients that collaboratively verify the logic (see "fraud proofs" and more recently "data availability proofs"). Moreover, even if this functionality is not implemented in software today, it's something that people could always do manually - but only if the Merkle proofs are there.
Dan：You have to buy and hold over $100 of cryptocurrency to justify the time and money of acquiring it in the first place. It certainly isn't viable to expect users to go through this process for a $0.01 fee.
For now. I expect that once substantial dapps start existing, which require small amounts of ETH to run to pay fees but not more, we'll start to see people find some way to sell $5 gift cards. Physical coins already exist. There is just little incentive to develop these services now because at the present time people tend to buy cryptocurrencies more for SoV and large-scale MoE use, which requires $100+ purchases.
Dan：Low voter participation has been addressed over the past 3 years through a combination of voting proxies, easier user interfaces, and a reduction on the number of things people have to vote for.
Sure, but this puts a lot of power in the hands of the proxies. If users are not voting on all N delegates per period, then someone else is doing that, and that someone else becomes a point of centralization that can be influenced or attacked. Furthermore, delegates don't have deposits, so their incentives to act well in any particular moment may not be all that high.
Dan：Concerns over "exchanges voting" were largely remedied via Steem Power (exchanges need liquid tokens)
That's the exchanges of today. What about "banks" that sell 2-year Steem Power-denominated bonds and pay interest rates? I imagine many people would want to buy such a financial product. Now, this is true for Casper as well, but with Casper if you "invest" in a validator and that validator screws up, your money's gone, so there is a strong incentive for users not to put their money into untrustworthy stake pools.
There is also one other substantial concern with voting: in order to win votes, any delegate would need to have a visible public identity; anonymous delegating would be very difficult to sustain in the long term. This makes the entire system substantially more vulnerable to political attacks.
If I had to summarize the reason why I dislike the DPOS philosophy I would say that it's waaaay too subjective. If you want to see why it's a bad idea, take a look at any bitcoiner's criticisms of Casper, and multiply them by ten. Casper uses subjectivity only as part of its very weak synchrony assumption, which it uses to reject long-range forks and resolve majority-offline attacks. This is a highly contained use of subjectivity, and it works totally fine as long as you or someone you trust logs on once a month - a rather trivial bar to pass. DPOS seems to rely heavily on users' subjective judgements for... pretty much everything. Who should be a validator? Steem Power holders would need to keep up with politics to know whom to vote for, or which delegate they should trust to tell them whom to vote for. Was there an invalid state transition? The number of nodes who can tell is quite small, and everyone else has to trust... someone. Was there a 51% attack? The miscreants can be punished, but instead of being one month the synchrony assumption is around a minute - an attacker who can selectively delay network messages by a minute can make it looks like the attacker is a victim and the victims are attackers.
Dan：Lastly EOS is designed around the idea that service providers (DApp Developers) should cover network costs, not the users. A good application needs a monetization strategy that is fully independent of network operation.
You can do this in ethereum too. You can have applications that refund transaction fees to their users. And yet none of them do this, and moreover none of them want to. This is for good reason: the users are ultimately the ones that have the most control over how many transactions they send, and so they should be the ones that bear the marginal economic responsibility.
I also suspect that STEEM simply has not yet had enough interest to be the victim of a properly well-planned denial-of-service attack...
Dan：Due to the fractional reserve nature of the blockchain bandwidth allocation, most people only need to purchase enough for their "base load" and the network can handle the surges in demand
Suppose that you thought you were going to need 1 tx/day. Then you realize you need 2 tx/day. With ethereum, you had bought $5 of ETH when you started off, and all that happens is that the ETH runs down twice as quickly and you need to make your next purchase earlier. With STEEM, there has to be some quantity of STEEM that, in the long run, lets you do 1 tx/day but not more. When you realize that you need more, you would need to buy more STEEM, and do so before your "burst allowance" runs out. Now suppose that you realize a week later that you only need 0.5 tx/day after all. With ethereum, your existing ETH lasts 2x longer. With STEEM, you now have unused capacity, and you're stuck with the STEEM you already paid for, as it's too inconvenient to sell the rest back. This is what I mean when I say that the allocation-based model provides an inferior user experience. You have to choose either user experience inconvenience, or capital inefficiency.
Dan：DPOS can offer trivial slashing for producing two blocks with the same timestamp and thus attempting to create a fork
Sure, but there are ways to create two forks without triggering that trivial slashing condition. Making a consensus algorithm that can actually finalize blocks properly is a tricky business; it took us over a year to figure it out, and the result was heavily based on 30-year-old BFT theory (and yes, we do have a way of getting past the 33% offline attack). And yet we have one, and it's formally verified.
Also, your review of Casper is nearly two years old. The algorithm has greatly changed since then.
Specifically:
Dan：After posting a bond you have an opportunity to bet on which block will be included next. The incentives are such that you make money by betting with the eventual consensus and lose money by betting against the consensus. Any cryptographically provable misbehavior results in the forfeit of the bond.
This is not how it works anymore. Now it's simple prepare/commit messages, not arbitrarily sized economic bets. You lose money for equivocation - for sending pairs of messages that are inconsistent with each other.
Dan：In a sustainable system, income from transaction fees must be sufficient to cover the cost of participation.
Technically, (i) you can have a system where coin supply grows by up to some annual amount p, where p is somewhere below world GDP growth but we don't know how far below it must be, and (ii) it's not just direct transaction fees, it can also come out of fees in the form of ETH getting burned to pay for in-protocol activity (we're particularly considering using this to pay for storage).
Dan：Under such a system, costs of operating a full node are constant but the potential income is dependent upon stake. Anyone without sufficient stake would be unable to participate profitably.
This is true. However, the costs of operating a full node are negligible relative to the revenues of being even a minimally-sized validator.
Dan：To make an analogy with proof-of-work, suppose someone had 51% of the hash power and decided to refuse to include blocks produced by anyone else. The other miners have no choice but to join the attacker or lose money. In the same way, everyone betting on the next block has no choice but to bet with the “deciders”.
This seems like it applies to any consensus algorithm. The main difference though is that in Casper, because of slashing conditions, you cannot use this "attack" to revert finalized blocks. You could try to use it to censor, but then there is a protocol by which nodes can refuse to recognize censored blocks and build their own chain, and anyone participating in the censorship would get forked away and lose a substantial portion of their deposit. Additionally, as long as there are at least some "honest" nodes that refuse to follow along a malicious majority, such an attack is expensive.
In general, the review fails to capture one of the key advancements in Casper research over the last year: the idea that we can create a protocol where it is expensive for the validators to attack the protocol, even if they are a majority. Proof of work does not have this: 51% can double their revenue by excluding everyone else. In Casper, even if one validator does get 50%, they'll still get roughly the same returns as everyone else; if they go offline then the network will fail to provide finality guarantees for a week or two, but at the end of it they will lose a large portion of their deposit, things will go back to normal and life will go on, if they try to revert finality they will lose their deposit instantly, and if they try to censor then they will get forked off.