Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ethereum Contracts Are Going to Be Candy for Hackers

vessenes.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#51

Post by vessenes »

eggy wrote: post #45

>>industry average bugs per 1000 lines of code at 15-50 and Microsoft released code at 0.5 per 1000, and 0(!) defects in 500,000 lines of code for NASA Does anybody know how useful this metric is? I have read NASA uses C, C++, Java and Ada, of which the last three have a lot boilerplate. Heavily commented C can be verbose too. I realize there is probably a lot of review, commenting and redundancy built-in, and that a…

I had the same difficulty looking at the code. Do we count import lines and variable defs? Seems sort of lame.

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

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#52

Post by vessenes »

Bromskloss wrote: post #22
vessenes wrote: post #15

Earlier quoted context omitted.

From my review of some of these contracts, even fairly obvious flaws are not being exploited (yet). 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 pa…

What are the fairly obvious flaws?

Check out some contracts and see for yourself!

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#53

Post by olalonde »

kneel wrote: post #3

Running a machine on a blockchain (Ethereum) is much more complex and error prone then recording transactions on a blockchain (bitcoin) The Ethereum virtual machine has to be completely error free if any sane person is going to put their money into it. I just don't see that happening. I do see a lot of glitzy websites using blockchain buzzwords, but there isn't much going on besides fundraising. This should be a conc…

> The Ethereum virtual machine has to be completely error free if any sane person is going to put their money into it. I just don't see that happening.

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).

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#54

Post by chx »

jerf wrote: post #17
pessimizer wrote: post #14

Don't lawyers do this to real-life contracts?

First, let me acknowledge that this is a fair question. A bit cynical, perhaps, but fair. 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…

> about contract clauses interacting unexpectedly and screwing some party or other.

At the same, there's https://en.wikipedia.org/wiki/Scrivener#Doctrine_of_.22scriv... and https://en.wikipedia.org/wiki/Reasonable_person .

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#55

Post by vessenes »

ChemicalWarfare wrote: post #50
vessenes wrote: post #13

Earlier quoted context omitted.

Right, but for a ponzi scheme contract, that's not a great outcome. Or, say, a crypto-currency, one of the sample apps in Ethereum documentation. Either way, you have a trust problem -- who shall be trusted to transfer out all the value the contract holds?

I would imagine that would be something the contract identifies explicitly along the lines of Bitcoin multisig.

That's one conversation I'm hoping to get launched soon. The sample 'make your own digital currency' code from Ethereum has no such provisions right now.

To my mind, it's a little like K&R C showing you how to walk through a string in the 1980s -- adversarial data was not a big concern at the time.

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#57

Post by pipermerriam »

swordswinger12 wrote: post #56

The IC3 research group at Cornell, and especially Elaine Shi's group, has been thinking about this recently. They are (I think) working on some kind of program analysis framework using deep PL techniques to formally verify smart contracts.

There is actually already fledgling support for this in Solidity (the prevailing language that Ethereum developers use to write smart contracts).

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

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#58

Post by pipermerriam »

joosters wrote: post #41

The much-hyped 'DAO' that has crowd-funded over $100 million dollars worth of ether, is based upon one of the largest contract code seen so far. Even if it has been code reviewed, it's almost certain that bugs remain in there. All it takes is one hacker to find a flaw and $100 million will be gone in an instant

As a developer in the Ethereum space this idea has actually been something I've thought about a lot. It's on a list of things that I'm looking out for because they will inevitably happen.

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.

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#59

Post by eggy »

vessenes wrote: post #51
eggy wrote: post #45

>>industry average bugs per 1000 lines of code at 15-50 and Microsoft released code at 0.5 per 1000, and 0(!) defects in 500,000 lines of code for NASA Does anybody know how useful this metric is? I have read NASA uses C, C++, Java and Ada, of which the last three have a lot boilerplate. Heavily commented C can be verbose too. I realize there is probably a lot of review, commenting and redundancy built-in, and that a…

I had the same difficulty looking at the code. Do we count import lines and variable defs? Seems sort of lame. J of course has a different problem; only a handful of people can even parse it, much less opine on correctness.

Handful is a bit extreme ;) But seriously, it is easy to troubleshoot due to the interative nature of development in the REPL, the similiarity with mathematical formula and their layout. A PhD student wrote his thesis in 2008 about parallelization, FPGAs, ASICS and arrays, and was fully intending to write it in J, but his advisor suggested something more known, so he wrote it in Haskell. I'll put in the reference when I find it.

There is a table in the paper that shows the math formula, the Haskell and then J. Pretty interesting comparison.

To me, if you are not using a prover, then it is mainly going over 10K LOC 1 to 3 times vs. 100 LOC 10 times, 30K LOC reviewed vs. 1K LOC reviewed for errors and correctness.

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#60

Post by astrodust »

rtpg wrote: post #43
aab0 wrote: post #28

Earlier quoted context omitted.

The security history of the JVM suggests that one shouldn't be optimistic there either.

counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)

JavaScript has several mature, thoroughly scrutinized implementations. Ethereum has one brand new implementation.

To put it mildly: There will be blood.

Post reply on HN