Full disclosure: tech lead on Keep (the project whose blog this is posted to), and the post is by one of our advisors. You're right that this particular exampl

Full disclosure: tech lead on Keep (the project whose blog this is posted to), and the post is by one of our advisors. You're right that this particular example has other downsides. The goal was to present the simplest examples of some attacks and issues that are easy to miss when doing blockchain programming. As I mentioned in another comment (https://news.ycombinator.com/item?id=16144892 https://news.ycombinator.com/item?id=16144892), the important thing is that, as a developer for a given chain, you need to be aware of the pitfalls of your chain (keeping in mind some apply across chains) so you can design around them. That includes the pitfall you described---everything is public, and that introduces some careful decisions that need to be made when building smart contracts. That one is pretty widely discussed; on the other hand, we hadn't seen any other content with a basic introduction to the pitfalls around miner misbehavior, so we felt James's post was super valuable. I think a key piece of it is the last paragraph: > Miners aren’t your friends or enemies — they’re a force of nature in our consensus systems. Systems that fail to plan around this will eventually lose out to clever miners. We've built many systems today that fail to take into account the dangers of ignoring security, and we're starting to pay the price. Public blockchain apps will need to be careful to have a decent understanding of the threats, especially since many of these threats have the potential to be even more directly tied to money than security issues in current systems. The more important (you consider) your system, the more important it is that your threat model include entities that are required for your system to function, like miners.