Ethereum Contracts Are Going to Be Candy for Hackers

It seems to me to be much easier to reason about a very limited set of actions than the virtually unlimited ones Ethereum offers.

On the other hand, it's incredibly fast to spec out and deploy one of these contracts, which is pretty amazing to me. Lots of interesting things coming.

Your fear seems to stem from misunderstanding how Ethereum works or what it even is.

Most likely, Ethereum itself (the "engine") will be effectively error-free - probably as good as the Linux kernel - once it reaches 1.0. And smart contracts can be as simple or complex as you like. If you're afraid of bugs, don't put money into any complex smart contracts. If there's a lot of money involved, then spend some money/time reviewing the smart contract.

Also, contracts can set precedent once they are in the ecosystem. If a contract has been heavily used prior to your desire to use it, you can copy it, and be relatively confident that it will be secure for you to use.

Bitcoin also has a mini VM and scripting language (transactions are verified by "concatenating" the script of an output with the script of an input and running it). One big difference is that Bitcoin's scripting language isn't turing complete (e.g. you can't have loops or recursion) and there are other limitations like a per block limit on expensive operations (signature operations to be precise).

I'm sure the Ethereum team does the same but then when it comes to DAPPs and Contracts running on their VMs and potentially trying to compromise the underlying system things are way too fuzzy for now.

Are you aware of the $155M USD people have sent to https://daohub.org using (depending on) Ethereum?

The early days of Bitcoin had many of these same business models, although with much worse security and trust models.

Getting security and secure practices together is going to be a large effort, and a simple post like mine is just a way of throwing my hat in the ring and getting some conversation going.

1. Like you said, a bug will cause the "effective" theft of a huge amount of funds.

2. Someone will make a contract that unexpectedly makes a huge amount of money. That contract however will have absolutely no mechanism for extracting this money, forever locking the money it makes away beyond reach of anyone.

3. Someone will make a contract that the American government has deemed illegal. That contract will have been made such that there is no off switch. The only possible way for them to stop it would be to convince the majority of the network to remove it via a protocol update. I expect they will not be able to get this majority and thus we have an unstoppable force meets immovable object situation.

4. Ethereum will have it's `npm` left-pad moment when a contract that is used widely is suddenly suicided. The number of down stream effects will be enormous. Most of them will be unfixable.

So, flaws will become known, and presumably there will be ratings and trust ratings and so on eventually. In the interim, though, some of the flawed contracts moved well over $100k in their first week of existence. That seems worth paying attention to.

I would propose flaws like these are unavoidable, unless you can pay what NASA paid. And remediation techniques should be developed urgently, not at some later date.

Market is small so competition won't be strong; customers aren't professional security reviewers, so have no idea about flaws. What's most likely to happen is people putting money in and then losing it when an attacker discovers the flaw. That will put people off the whole smart contracts concept.

https://forum.ethereum.org/discussion/3779/formal-verificati...

J of course has a different problem; only a handful of people can even parse it, much less opine on correctness.

To answer it, no, not like this. Contract law has a lot of humans in it. You are certainly able to sign some contracts with combinations of clauses that can get you, and I've read horror stories at the mega-corp levels about contract clauses interacting unexpectedly and screwing some party or other. But even in those cases, the way they got screwed was by a collection of individually-sensible clauses.

A computer running a contract is by contrast blitheringly stupid. If you write a logic error into your contract that lets a participant suddenly claim all the contracted value by simply, say, sending a bid of 0 as many times as there are participants or something, there's nobody and nothing that will prevent that. If you try that in a human contract, it will be invalidated by some human judge.

Sure, lawyers may write complicated contracts in an attempt to screw the other signatory and they may play complicated games with the clauses, but running contracts as otherwise-unsupervised programs is a whole new level.

Furthermore, just having had a quick scan over the language documentation, it looks to me like a bog-standard imperative mutable language. One that is very young, and with few if any features designed for being used in a high-security environment. It appears to be based on raw event-based programming, a style of programming very easy to mess up and hard to declare and preserve invariants in. It looks like a very dangerous programming language to be trying to write financial contracts in. At least it's not dynamically typed, does seem to avoid excessive coercion, and should be memory safe; it could certainly be worse. But it could be better, too.

2) I'm not an expert on the registrar situation by any means. But, I do not believe that updating a registrar pointer changes the balances at each contract (the old and new), so while it may be useful for some cases, those which involve balances may be more troublesome if you haven't thought ahead.

It does sketch out a new world for grey and black hats, when the attacks can be pretty easily separated out from an IP since they're submitted over the ethereum network.

In Ethereum is more encourage to write smart weird custom contracts, so many people write a custom contract with only one pair of eyes to review it, so it's more probable to find errors.