Hard fork contingency plans and SegWit readiness - a challenge to solution evangelists

Currently, the biggest discussion in the Bitcoin community concerns the possible forks we might see this year - Bitcoin Unlimited and SegWit. Whether those forks should or should not be activated and whether they will create a network split is an important discussion, but what is less discussed is the risk mitigation in case either of those forks happen. I would like to post a challenge to the various solution evangelists to see if their software is ready for any outcome.

Note - some questions apply to more than one scenario. Duplicates have been omitted for conciseness.

Scenario 1 - SegWit activates before Bitcoin Unlimited

Lets say SegWit activates before Bitcoin Unlimited or any other block scaling solution takes place.

First, some questions to the Core team:

How much extra transaction throughput are you expecting to see with this solution?
Do you have any estimates as to how many transactions should move off-chain in the near future? When do you expect this solution to start reaching critical mass to alleviate the block congestion?

How many of the big Bitcoin companies will be ready for SegWit?
This important question is somewhat answered by a handy spreadsheet or two. Let's have a look and see if some important players are missing... Coinbase is "planned" so far. BitPay is nowhere to be seen. BitGo is "wip". Top exchanges - Poloniex, bitFlyer, BTC-E, OKCoin are missing. For the wallets - Armory, BreadWallet are wip, Bither, Exodus and Multibit HD are planned.

All in all, the coverage looks good, but some top players still need to get on board.

What are the fees users should be expecting?
A large pressure for the increase in the network capacity comes from the high fees to the average user. What fees should the users expect under SegWit? I've seen mention that on-chain fees will drop from 0.5BTC/block to about 0.2BTC/block, but some numbers on the off-chain fees would also be interesting.

What is the block scaling plan going forward?
Are you planning on changing the block size following SegWit? If so, when are we likely to see the size change and what would it be?

And a big question for the Bitcoin Unlimited team:

Is your client SegWit ready?
Are you ready to integrate SegWit into your client? Will it have some issues in case SegWit activates?

Scenario 2 - Bitcoin Unlimited activates first, network splits

In this scenario, Bitcoin Unlimited activates first and the network splits itself into Bitcoin Core and Bitcoin Unlimited.

Question to both sides:

How are you mitigating the damages of the split for your users?
There are many things that need to be considered when the network splits. How are you mitigating the cross-split replay vulnerability? How will you avoid the confusion when it comes to addresses being the same on both networks?

Bitcoin Unlimited devs:

Is your code ready to be pulled to Bitcoin Core?
A lot of people consider Bitcoin Core to be the "gold standard" when it comes to Bitcoin clients. Developing a different client without allowing the options to be pulled into Bitcoin Core cleanly will only make the adoption of your client harder.

So, is your code ready to create a pull request to Bitcoin Core? Do you have a branch that is up-to-date with the latest commits to Core, or will you need to catch up? If you don't have these ready, it is almost inviting a network split, rather than working on keeping the network unified.

Will you be activating SegWit on your network?
There are some good use cases for off-chain transactions - will you be activating SegWit or other soft forks required to run off-chain transactions on your network anytime soon?

How are you planning to convince more exchanges to adopt Bitcoin Unlimited?
Some developers have sworn off BU completely - for example, BitGo (and thus indirectly - BitStamp, OKCoin, Kraken, etc.), while others might be on the fence. Do you have any plans on convincing them to start supporting your software?

Bitcoin Core devs:

Will you make your client opt-in compatible with Bitcoin Unlimited?
This question was originally asked by Gavin - since "Bitcoin Core does not want to and does not make decisions on Bitcoin’s consensus rules", is Bitcoin Core prepared to let the users op-in to be able to connect to the Bitcoin Unlimited network? It shouldn't be that much work to add a flag disabling the block size check at the very least.

Scenario 3 - Bitcoin Unlimited activates first, minority network gets attacked

In this scenario, Bitcoin Unlimited activates first, the network splits, but the minority chain gets attacked by miners in hopes of preserving only one side of the fork.

Bitcoin Core devs:

What is your contingency plan for such an attack?
As I understand, the current plan is to change the PoW algorithm in a hardfork. Is that hard fork already in the works? Is the new PoW algorithm decided on yet? Has the hardfork been tested? It is a large change - you don't want to be scrambling around trying to figure this out while an attack is ongoing. Do you have your legal side of things covered? Will you be coordinating actions with important Bitcoin players, such as exchanges?

Since hardforks don't come as often, are you planning on implementing any of the hardfork wishlist items while you're at it? Will the hardfork also include SegWit?

Bitcoin Unlimited devs:

What is your plan for such an outcome?
Will you be endorsing the attack, or will you be disowning it? Are you prepared for potential legal, community, etc. backlash you might receive if the attack takes place (even if it's not of your own doing)?

Conclusions

There are many important questions that need to be addressed early on before Bitcoin starts forking. While we might still have some time before either fork activates, it's better to mitigate the potential risks early on than to scramble when they actually take place. I'm looking forward to developers from either of the sides sharing their thoughts on the issues raised here.

Avoiding Bitfinex scenarios with Voting Pools

This week, a high-profile Bitcoin theft took place at the Bitfinex exchange. The attacker reportedly stole 119'756BTC, worth about 70.5M USD. Those funds were held at a 2-out-of-3 multisignature wallet - one key was held at Bitfinex's server, another was kept by BitGo, and a third was a backup key held offline by Bitfinex. From what the reports say, the hacker was able to get their hands on the first key, as well as the API credentials required to authorise BitGo to process the withdrawal. With no additional safeguards, they were able to drain the hot wallet and land themselves around the number 2 spot of the biggest Bitcoin theft to date, after MtGox.

The scenario is still unfolding, so there are a lot of theories still floating around as to why the situation was allowed to take place. Some have speculated Bitfinex was forced to keep all of their coins in a hot wallet due to CFTC's ruling (as Bitfinex was not a registered futures trading platform), although it seems that the change was made before the ruling. Bitfinex also unveiled a plan for a "bail in", wherein everyone's assets would be devalued by about 36% so the exchange could continue operating.

Since Bitcoin's past seems to be littered with theft, I would like to have a look at one possible solution to minimise such high-profile hacks:

Voting Pools

Voting Pools is an idea proposed by Open Transactions, a Crypto 2.0 platform focused on notaries issuing IOU tokens and other financial instruments. The main issue such systems have to cope with is securing the cryptos, currencies and commodities underlying the assets circulating on the platform - an USD IOU is only useful if you can redeem it for real USD at the end of the day.

The way Voting Pools help secure users' funds is through shared responsibility from competing actors. Multiple exchanges of similar size would group together in a pool and secure one another's funds through multisig and a legal agreement to share responsibility in an event of a loss (be it from theft or one of the exchanges trying to run off with everyone's money). The multisig would be distributed in such a way that any one actor would not be able to control even their own money, and the system being robust enough to handle a loss of some keys (2-of-3, 3-of-5, 4-of-5, etc.).

This setup would make sure that a critical failure of one actor would not compromise the system. Even if one of the exchanges would burn down, get hacked, or the owner would decide to run away with all of the private keys, they couldn't do anything. The other exchanges would take over the responsibility and secure all of the funds to be able to pay all of the failed exchange's customers without suffering a loss of their own funds.

More importantly, however, this solution also forces every participating company to not only police themselves and ensure they have the most adequate security practices in place, but also to look at one another. When your own money is on the line, you will make sure everyone is keeping up with the rest of the pack in terms of keeping the money safe. Since the exchanges would still be competing with one another, they would have every incentive to expose other actors in the voting pool that are compromising the security.

Beyond that the full implementation of Voting Pools also necessitate that the exchanges would open up their transaction logs to one another to make sure everyone knows how much every customer is owed in case of a database wipe or the exchange vanishing from the face of the earth. This is pretty much automatic when it comes to gateways on a public ledger like Ripple or some shared permissioned blockchain, and it shouldn't be too hard to accomplish if an exchange already creates a strict and timely Proof of Solvency. That being said, it is pretty much unheard of for a normal Bitcoin exchange to do that currently, which might make it more problematic.

Having access to a full, real-time set of transaction logs the participants in a voting pool have everything they need to not only be able to settle with every customer in case the exchange goes under, but they can also police the exchange in real-time and raise flags in case of discrepancy. If exchange's liabilities exceed their assets, all withdrawals can be automatically haled until the matter is resolved. Large withdrawals, sudden market crashes and balance changes could similarly raise a lot of flags (to avoid another MtGox scenario, wherein a hacker crashed the market to be able to bypass the $1000/day withdraw limit).

Conclusions

All in all, voting pools would force a strong degree of transparency on every actor and couple that with multiple security teams making sure the system is secured against a growing number of hacks. While the participating exchanges would sacrifice their business data secrecy to their direct competitors, security through obscurity is never a good approach.

Perfection or bust - the rise and fall of The DAO

Full disclosure - I own some ether and I have put some of it into The DAO presale. I don't think it coloured my view of the situation, but I feel it's better to be open about such things.

The DAO has made a lot of waves recently. First - last month when it became the largest crowdfunding project in history, at one point surpassing Star Citizen's 116M USD (although it might be partially due to ETH exchange rate fluctuations). Second time - earlier this week when the DAO was hacked. So lets start from the beginning and have a look at the rise and fall of The DAO.

DAOs, in general

DAO, or Decentralised Autonomous Organisations have been a fairly nebulous concept in the crypto space for awhile. They basically are computer programs that run as an organisation, using its code as law. They can hold digital assets and money that can be spend on various projects, services and other digital assets.

Some have proposed to use DAOs to create a rudimentary self-sustaining decentralised organisations. Such programs would actually use their resources to hire people to improve them. I've heard this concept described first during the 2013's Money2020 Ripple conference, and I would consider BitShares to be one of the first self-sustaining DAOs.

Of course, with the current level of cryptocurrency technology, the DAOs are very limited in scope. They can't be as sophisticated as modern AI running on supercomputers, and since code isn't lawfully binding - the various DAOs have to rely on humans to interface with the outside world.

In theory, DAOs could create a lot new jobs. As @aantonop put it though:

TheDAO will create many jobs. First for people like me who have to explain what the hell it is.

The DAO

The DAO (holding a very generic "temporary name", which it probably won't escape from), created by Christoph Jentzsch, the founder of Slock.it, was set out to be one of such self-sustaining DAOs. It was set up to be a quasi-venture-capitalist-fund. As with many token crowdsales, it was skirting the borders of the law - allowing anyone to invest, not doing any KYC, promising "benefits to the DAO Token Holders", without outright selling securities.

The project had support from a number of high-profile members of the Ethereum Foundation

The DAO started operations by selling its tokens for ETH. The promise was that later the ETH would be used to fund various projects and try to extract value from those projects to the DAO itself. The DAO also had a mechanism to upgrade itself to newer versions of the code. The entire process of both spending money and code upgrade would be governed by the token holders voting. Every vote would be proportional to the amount of tokens held.

By the end of the crowdsale, The DAO has raised 8.26M ETH, more than 10% of the total coin supply.

In theory, The DAO could've been a very strong player in the crypto space. Even if it would spend 10% of its funds just funding early stages companies, it could give out 100k USD to 100 different companies and probably have great ROI by the end.

However, there was a bug in the code...

The exploit

Around 2016-06-17, news broke that The DAO's balance was being drained. Quickly there was a call to all exchanges to stop trading the tokens and Ethers while the situation is being resolved.

As it turns out, The DAO had a small bug in it (discussion, technical overview). They managed to make a recursive call to a function and use that exploit to start draining The DAO of its ETH. Before the attack stopped, 3.6M ETH was extracted, worth about 50M USD give or take 20M due to wild price fluctuations.

The attack stopped around the time Vitalik released a blog post about how Ethereum will be handling the exploit. In the end it was decided that Ethereum will not roll back, instead creating a soft fork preventing the drained ETHs from being spent. The coins would also apparently be reimbursed and everyone that put their money into The DAO would be getting it back.

The following day, we actually got a statement from "The Attacker" about the issue, claiming that the draining of ETH was legal and in accordance to The DAO's rules ("code is law", therefore any execution of the code is always as intended). The Attacker also threatens legal action against any attempt to freeze the drained ETH. If such a case ever made it into a court, it would probably be the most important precedent for the future of decentralised organisations as a whole. Only time will tell where the story goes.

Other criticism

If The DAO has not been taken down by this exploit, it is entirely possible we might've seen a lot of other problems crop up in the future. Here are just some of the possible issues and other ideas that would need to be considered.

Setting a precedent for Ethereum. The way Ethereum handles this exploit may affect how similar future problems would have to be addressed. If they go through with the blacklisting, they might be required by law or asked by the community to do the same in the future for a lot of other things. This can open up a big can of worms. However, if they don't, then they might scare off any other similar projects from using the platform, along with some of their users. Damned if you do, damned if you don't.

Voter apathy. If The DAO would have a large amount of users sitting idly on their tokens rather than voting with their money, the software might have problems reaching the needed quorum to do anything. Apparently in Bitshares, only about 10% of stakeholders participate in voting. Perhaps switching to a Delegated Voting model might help alleviate the issue.

Unexplored legal area. The DAO seems to have aimed to exist in an unexplored legal area. It operates like a security or a venture fund without doing the due diligence. It technically cannot be sued, but people that put money into it might face legal repercussions. All in all, it probably would give any lawyer and government official a headache to try framing it in the existing rule of law.

Lack of KYC. While a lot of people in the crypto community want the government and regulations as far from their projects as possible, some oversight might deter attackers. If every investor in The DAO would be vetted by KYC first, and if only vetted individuals could hold the tokens, anyone attacking The DAO would have to be prepared to get sued and criminally charged for their actions. Right now the best we've got is to try tracing the ETHs they owned back to an exchange and possibly investigate some Ethreum / DAO short calls someone might have set up before the attack (similarly to the idea of "terrorist insider trading").

Rushed deployment. After The DAO has been released, there have been some concerns from people that the code should've been tested and vetted more to iron out any bugs. A code that holds so much money is a gold-filled pinata for any and every hacker that might try to break it 24/7. Some attack vectors have been published before the attack (description and mitigation). Since the contract is vulnerable right after it's released, rushing a release is not wise.

Any bug needs to be fixed immediately. With a smart contract running on a decentralised network, it is vulnerable to exploits all the time. Any new bug that is found needs to be fixed right away, especially if it is described publicly. With more centralised software, you can at least shut everything down until the bug is fixed, but such luxury would be harder to implement in a DAO.

One mistake and your money is gone. While this one applies to most cryptocurrencies, it also bears mentioning - any bug in the code that breaks the smart contract that holds actual money (in this case, ETH) can cost you everything. If you deploy such a piece of code and send money to it, it is gone and you won't be able to get it back.

There are no rollbacks with real coins. While any contract that issues and deals only in its own tokens can be rolled back to any point in time with a patched contract, the matter is not as simple when we're dealing with actual coins (in this case, ETH). As the native coins exist outside of the contract's controls, using such contracts to manage the coins is more dangerous than just dealing in tokens.

Putting all eggs in one basket. A contract holding over 100M USD is a disaster waiting to happen. At the very least some of that money should've been put in some deep cold storage until it is needed. Enter into some legally binding contract with 50 people if you need to to provide some multisig and keep the funds safe. It's like putting all of your coins into a hot wallet - you shouldn't do that.

Paradox of presales. Even if The DAO would function correctly, it might be a hard value proposition, similar to most other ITOs (Initial Token Offering). Unless you are an actual security / fund and building projects that funnel their earnings into the organisation, the projects that benefit The DAO holders rather than Ethereum as a whole might be inferior to the general use case. There is a lot that the Ethereum platform and anything on it could benefit from, but tying them into one smart contract might defeat the purpose. Since many DAOs want to avoid being labelled as a security, we might just get some weird projects in the end.

Relation to other projects

A few people have started comparing this bug to a few other things in the cryptocurrency space. Perhaps it is important to have a look at them and figure out how similar they are.

In the early days of Bitcoin, in mid-2010, someone found a way to create 184'467'440'737.09551616 BTC (almost 10k times more coins than would ever exist) out of thin air in a so called "Value overflow incident". The bug was fixed and the network was rolled back. The bug is similar - use an unexpected way the code works to get access to more tokens than one should be able to. However, this situation is different as it breaks the core functionality of the entire network, rather than a sub-part of it that is not governed by the protocol. Rolling back the network to before the bug was introduced is entirely justified - it is something that shouldn't have happened. With The DAO, the situation is a bit different - the core network functioned as intended, it is the final product that was at fault.

Another incident similar to this was the fall of MtGox allegedly caused by Transaction Malleability, and the attack on JustCoin with Ripple's Partial Payment Flag. In both cases, the software creators did not anticipate an obscure network behaviour that lead to their downfall. In neither cases did the network got rolled back - it functioned as intended, and to my knowledge neither of those companies got bailed out for the bugs in their code. This would probably be the closest analogy.

The decision to bail the contract out and refund the drained ETH might be either seen as the Ethereum Foundation trying to mitigate the damage to the network's reputation, or it might be due to many of the Foundation members lending their credibility to the project itself. One way or the other, I doubt we would see many similar DAOs in the future with such lineup of big name supporters to mitigate any similar damage in the future.

What is also worth noting is that because of Bitcoin's success, a lot of the cryptocurrency projects may "suffer" from an accelerated growth. There have been many incidents in the earlier days of Bitcoin of people losing their money and it wasn't that big of a deal - the coins were worth only so much. However, with networks such as Ethereum being worth a billion dollars less than a year after release, you have similar high profile bugs, but the coins themselves are worth a lot more a lot quicker. Perhaps we should try stalling the gold rush until a project has been vetted by early adopters hammering out all of the kinks and best practices? It's probably not going to happen unfortunately...

Lastly, if the Tau developers want to brag about how their platform is / will be much better than Ethereum since such bugs can't happen there, it is your time to prove yourself - deliver us your implementation of The DAO in a language of your choice so we can pick it apart and see if it breaks.

Conclusions

The DAO has been an interesting ride. It allowed the ETH to double in value and crash back down. A project of this scope if executed correctly would certainly be a game changer for any cryptocurrency network. Unfortunately, as many have made this joke before, it seems The DAO was DOA (dead on arrival). With DAOs, it's perfection or bust.

Spells of Genesis card for The DAO, reading

"Holding so much energy, the Colossus is able to withstand all threats"...

How Bitcoiners see the situation

Pondering Proof of Importance

Recently, I listened to a Let's Talk Bitcoin podcast discussing NEM (New Economy Movement), a new Crypto 2.0 system. So far, I was unable to receive any detailed overview of it for the Crypto Comparison Chart, but one feature that stands out as unique to NEM is their Proof of Importance mining algorithm. Lets have a look at how it holds up in comparison to what is already out there.

Proof of Importance

The detailed overview can be found in NEM's Technical Reference document. In general, it looks like a variation of Proof of Stake that gives extra weight to accounts that are actively transacting with a lot of other accounts. The actual equations as to how the weight is calculated and how it affects who will be selected as a miner is detailed over several pages of the document.

The downside of putting extra weight on transactions between accounts on the network is that the system can be easily gamed, at least until we solve the "one-identity-per-person" problem. Creating accounts and sending transactions around is trivial, and figuring out the exact method of getting the maximum return to game the algorithm is only a matter of time. Even the document itself demonstrated that an attacker performing a sybil attack can boost their importance by about 10% in comparison to someone that just holds onto their tokens:

So all in all, the system rewards those that hold the tokens moderately. Shared wallets, exchanges and payment processors would be examples of businesses that would receive proportionally more bang for their buck as it were, but a highly-optimized attacker can still beat out the quasi-random transactions of the above businesses by always performing the optimal transactions.

Conclusions

The sybil attack vulnerability of NEM reminds me of the old problem faced by Bitcoin mining pools back in 2011 - pool hopping. If a system allows any attacker to gain an advantage over honest players in the system, the algorithm needs to be changed.

As for the rest of the NEM system - I haven't yet had the time to explore it too deeply, but it also seems to suffer from the problem of being easy to front run by the miners (or harvesters as they appear to be called in NEM).

Fighting Bitcoin spam with Bitcoin Days Destroyed

As many of you might've noticed, the Bitcoin network has recently been flooded with a lot of spam transactions. While the problem is nothing new, essentially a plain old DOS attack, the Bitcoin network doesn't appear to have much in a ways of contingency attack if the attack is sustained. I would like to propose a possible solution to at least mitigate the attack somewhat using Bitcoin Days Destroyed.

For those of you who might not be familiar with the concept, Bitcoin Days Destroyed is an interesting metric for transactions. For every input, you multiply the coin age (when the transaction was included in a block) by the amount of coins being spent. You add up all of the results for the whole transaction Nd you get your BDDs. So, spending 1BTC a day after it was received gives you 1BDD. A week after it was received - 7BDD. 0.1BTC after a year has 36.5BDD and so on.

Now, if the order transactions are priorities for inclusion in a block was dependent on their BDDs as well as fees and size, it could limit the effectiveness of the spam attack - since the spammer relies on sending a lot of transactions often, unless they have a lot of coins, their transactions will have a very low BDD score. Standard users should have higher scores by default, provided they don't cycle their coins all the time.

Of course, this method only works if the mining pools would follow the rules. Seeing how many pools still mine blocks that aren't full gives one little hope the situation will be resolved quickly.

Side note - this solution isn't all that new either. I did write it down broad strokes in my master thesis (pages 42-43) back in 2011-2012 ;).

Mining versus Consensus algorithms in Crypto 2.0 systems

Recently, I had the pleasure of talking with David Schwartz, Chief Cryptographer at Ripple Labs about a topic that I haven't heard covered before - the implications of using a Consensus algorithm for ledger creation rather than a Mining approach, such as the one used in Bitcoin. This seemingly insignificant difference can affect the long-term viability of a Crypto 2.0 system as it turns out. But first, some theory...

Mining algorithms

As pretty much everyone knows, new Bitcoin blocks are created through a process called mining. Every miner on the network competes to produce the next Bitcoin block by the use of Proof of Work algorithm. If you find the solution first, you have successfully created the next block and thus get the block reward plus fees for included transactions - pretty simple.

There have been a lot of tweaks made to this simple algorithm in many altcoins out there. A number of different coins use different hashing functions for their Proof of Work, some networks introduce Proof of Stake or Distributed Proof of Stake and so on. What all of those algorithms have in common is that every block is created by a single entity - it might be a lone miner, or perhaps a mining pool aggregating a number of workers, but there is still a singular authority that dictates how a block looks.

Consensus algorithms

The Consensus algorithm as popularized by Ripple and also used in Stellar works on a different principle (some videos on this subject - 1, 2). Instead of performing any mining, a number of validators agree on which transactions should be included in the next ledger. Based on that agreement, every validator creates the same ledger.

While the way the validators are chosen can be a a difficult and important design decision, the result is similar - there is no single entity that creates the next ledger.

Malicious miners - what can they do?

While most people have heard about the dangers of a 51% attack and some are also aware of the Finney attack, today we would be talking about more benign things every miner can do to every block they create.

Any miner that creates a block can:

• Control which transactions are part of the block, if any
• They can prevent certain transactions from appearing in the block they mine
• They can include any number of valid transactions into the block. Even if fees are forced for any such transactions, the miner will earn those fees back
• If there are multiple conflicting transactions, the miners get to pick which are included in the block, thus invalidating their double-spend counterparts
• Control the order the transactions are included in the block
• Decide whether to release the block they created at all
• Set the various block parameters within some limits (they control the nonce and timestamp)

In the Bitcoin world, pretty much all of those things don't really affect the network performance all that much. Sure, the miners can censor some transactions for a block, but provided the network as a whole is not compromised, those transactions should eventually make it into someone's block. They can also spam the block with any number of their own transactions for free, but in the grand scheme of things it's just an extra megabyte of data that needs to be stored. All in all, due to Bitcoin's straightforward transaction nature and the fact that we're dealing with only one currency, a malicious miner can't really do much.

Now, lets consider the same scenario on a more sophisticated Crypto 2.0 platform, such as Ripple, BitShares, Ethereum, Omni or the like. The network not only handles their native currency, but also offers a lot of other features - derivative contracts, decentralized exchanges, smart contracts and so on. Suddenly, whether a transaction is included in a given block or a block after can start to matter a lot more.

If a malicious miner sees a big buy order coming into the market that would move the price significantly, they can engage in front running - the buy order could be pushed to the back of the queue or even left out until the next block, while the miner buys up all of the current stock and re-lists it at a higher price to turn a profit. Alternatively, when they see there is a high market pressure coming in, especially in systems that are inefficient by design, they can buy the orders up one by one by using their power to include any number of their own transactions into a block for free, and similarly re-list them for people to buy up.

When we enter into the smart contract world, we have a few more exploits.

Perhaps the system in question is relying on the miners to be smart oracles and report some price data. The miners can misrepresent the price in their favour - perhaps not so blatantly as to report different orders of magnitude, but one could use data that is a bit stale or fudged on the second or third significant digit without it looking too suspicious.

The miners could also try to influence some time-sensitive contracts - maybe someone tried to make a bet on some lottery during the last possible minute, or some contract deadline is about to come up and the miner stalls the transaction by one block? That could change the outcome of the contract.

Lastly, if some smart contracts implement gambling on the blockchain with the random number generator being influenced by the mined blocks, the miners could cheat that system by only releasing blocks favourable to their bets. Say, if we have a virtual coin flip that is heads if the block hash is even and tails if the hash is odd, if the miner stands to gain more by winning the bet rather than creating the next block, they can withhold the blocks that aren't favourable to them. Provided their computing power share in the network is greater than the house edge in the game, the miners would turn a profit in the long run.

All in all, there is a lot more a malicious miner can skew in their favour in a Crypto 2.0 system than they could do in a traditional system like Bitcoin.

Validators

In comparison to the miner-based approach, the consensus model based on validators solves the listed issues in most cases. Provided the validators are not colluding with each other to overtake the network, most of the above listed attacks are reduced if not eliminated altogether.

While a malicious validator might try to do some front-running, their transactions aren't more likely to be included into the next ledger than the transactions anyone else submits. Having multiple validators act as smart oracles could allow one to average out the answer and limit the influence of one malicious report. Time-sensitive contracts could be slightly influenced by trying to stall the consensus mechanism or vote against some transactions being included in a ledger, but since the system is designed to be fault-tolerant, one malicious entity shouldn't be able to do much.

Influencing the ledger hash is possible to some degree - the validator can try predicting what the next ledger will look like and adding which transaction could influence that hash in their favour, but everyone else can do the same. Since all parties are just as likely to influence the ledger hash, the result of this influence could make the outcome just as random as it ought to be, or at least make it very hard to predict whose influence will win in the end.

All in all, a validator-based approach to ledger generation reduces the number of exploits that can be performed in a Crypto 2.0 system.

Conclusions

One could compare the mining approach to block generation to a short-term dictatorship, while the validator approach is more akin to democracy. While both systems can be exploited or used for good (the Roman Republic elected their dictators in times of need, while democracy can spiral into mob rule), the democracy of validators requires more parties to be malicious before the system becomes compromised.

While in the Crypto 1.0 world a malicious miner can't do much to harm the system, in a Crypto 2.0 world there are a lot more exploits that need to be addressed.

As this is a topic I haven't seen properly discussed before, I would love to hear the input from the developers of various Crypto 2.0 systems - Omni, Ethereum, Counterparty, NXT, BitShares and so on as to how they view this issue potentially affecting their networks.