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

Learn Ethereum smart contract programming

ethereumdev.io

Post reply on HN
Print view View original

131–140 of 244 posts

Re: Learn Ethereum smart contract programming

#131

Post by grey-area »

kbody wrote: post #109

The sad reality of Ethereum: 1. Bitcoin is slow and expensive, Ethereum is the future 2. Ethereum software has security hole, gets hacked 3. Ethereum fans say it's an experiment there are lots of things that will transform Ethereum (Casper/PoS, Raiden, zkSNARKs, Enterprise Alliance) 4. Low price getting pumped by Ethereum Foundation & big-holder affiliates 5. Back to #1 We've seen it happen again (DAO) and again (Par…

When it comes to contracts I think a more interesting idea is a limited formal expression of them and thus automatic production and evaluation/translation/summaries (would require a formal spec for each domain with very limited options), not a Turing complete expression of them which as you say leaves too many holes. Also tying all of this to a currency and payments makes zero sense and just expands the attack surface massively. Just fixing contract law with automated checks of contracts would be a huge opportunity/challenge.

Re: Learn Ethereum smart contract programming

#132

Post by roywiggins »

naasking wrote: post #116
staticelf wrote: post #17

The problem I see with Ethereum is that it is way too complex. I have read perhaps at least 10 times on their home page without even understanding what it does, what problems it solves etc. This is the sole reason why I don't think it will be successful in it's current state. With most successful tech or services or whatever the core idea is often super simple to grasp and you can instantly see the benefit. I don't s…

> Smart contracts is probably the key word but I don't understand how it works or how it will benefit me. I virtually guarantee you don't really understand how the regular monetary system works either, but you can still use it and have some idea of how it benefits you. Ethereum can be used to set up another monetary system whose currency flows are guarded by code-driven contracts that anyone can write. So imagine the…

> code-driven contracts that anyone can write

Anyone can write a contract, but only a handful of people seem to be able to write correct contracts. And an incorrect contract means your money is gone.

Re: Learn Ethereum smart contract programming

#133

Post by throwanem »

nerdponx wrote: post #127
dragonwriter wrote: post #121

Earlier quoted context omitted.

Well, the Ethereun fork itself reveals that there is some recourse. It may be less attractive recourse than exists with plain contracts for many potential participants, though.

Sort of, but it's also insane. Forking Ethereum because of the DAO hack is a bit like forking the US dollar after the crash of 1929.

Which is just my point. It's not that no means of recourse exists outside the contract code; it's that there exists no option between zero and global thermonuclear war. The broad range of subtleties that contract law has developed to answer complex situations, and the option to exercise judgment in those cases not yet captured by precedent, is completely absent in Ethereum, because the people who designed it saw no reason why any such thing should be needed.

Unfortunately, that they failed to see it doesn't mean it isn't so, and now every new conflict among blockchain participants is an exciting new opportunity to reinvent another piece of several hundred years' worth of too hastily discarded prior art.

Re: Learn Ethereum smart contract programming

#134

Post by roywiggins »

nerdponx wrote: post #127
dragonwriter wrote: post #121

Earlier quoted context omitted.

Well, the Ethereun fork itself reveals that there is some recourse. It may be less attractive recourse than exists with plain contracts for many potential participants, though.

Sort of, but it's also insane. Forking Ethereum because of the DAO hack is a bit like forking the US dollar after the crash of 1929.

We did devalue the dollar against the gold standard significantly in 1934. Not entirely unlike a "fork", since it's a declaration that, whoops, your dollars are now worth 40% less gold than you thought.

In 1931 Britain floated the pound, which arguably the US ought to have done too. Suddenly, your paper is no longer convertible to gold at a fixed rate. That's an even more dramatic change than the Ethereum fork.

Re: Learn Ethereum smart contract programming

#135

Post by hackermailman »

If you are considering writing a smart contract, you should read this first https://github.com/ConsenSys/smart-contract-best-practices for Solidity security pitfalls, and hopefully have some idea of invariants/contracts to verify expected properties of your smart contract https://www.cs.cmu.edu/~rjsimmon/15122-s16/lec/01-contracts.... and additionally hope the EVM doesn't have unexpected behavior.

Anybody know if the legality of exploiting leaky smart contracts has been tested? Since a lawyer can exploit a badly written contract I wonder if somebody who finds a flaw in a smart contract can legally just jack all the coins or alternatively, write purposely obfuscated contracts (underhanded Solidity contest) to run a scam.

Re: Learn Ethereum smart contract programming

#136

Post by mbrock »

merijnv wrote: post #130
mbrock wrote: post #119

Earlier quoted context omitted.

The belief that Turing machines aren't amenable to formal verification is a hobgoblin that shows up in every thread like this, but it's not real. Of course there are limited formalisms that make certain types of verification easier, but proving programs has been possible since, like, the 1960s. A multisig, for example, has a finite number of states when considered under symbolic execution. A model checker can rip thr…

Sure, you CAN verify Turing machines, but verifying languages that AREN'T Turing complete is sufficiently simpler. So why not make your verification work easier by using a total language? The only real argument against that would be "we can't do what we want in a total language". I don't buy the argument that what people want to do with smart contracts requires Turing-completeness. In fact, as time goes on I become m…

The real answer is probably that total languages are obscure and the Ethereum inventors didn't know about them so they chose a simple and ordinary stack machine.

But those total systems are, of course, subsets of Ethereum, which means that if you write your program in an obviously finite way, you can use the same inductive proofs you would use for a total language.

Turing completeness makes it hard to prove properties automatically about arbitrary programs, but you can still prove properties about specific programs.

I'm pretty sure that MOST research on program verification has been done in the context of Turing complete systems, from the work of Floyd and Hoare, to the symbolic execution of Deutsch and King, to temporal logic, TLA+, etc.

Re: Learn Ethereum smart contract programming

#137

Post by repomies691 »

PeterisP wrote: post #71
repomies691 wrote: post #45

Earlier quoted context omitted.

Everyone chooses risks that they take, and consider whether there exists enough benefits for the risks. It makes sense to take calculated risks. I'm opposing the viewpoint "there exist risks, therefore it shouldn't not be considered at all".

Come on, people are not saying that "risks exist", they are saying that the risks are very very likely . It's a near certainty that I won't get hit by a car tomorrow - people do get hit by a cars but most people don't get hit by cars most of the time. There is a risk (a fraction of percent), but it's acceptable. It's an even larger certainty that code will have bugs. As far as I've seen, all code will have bugs, as e…

Come on. Quote from original comment: "Until we have near-perfect code writing AIs every new smart contract is just a disaster waiting to happen."

If smart contracts are at all useful, they most definitely will be useful before we have near-perfect code writing AI's.

Re: Learn Ethereum smart contract programming

#138

Post by KirinDave »

kbody wrote: post #109

The sad reality of Ethereum: 1. Bitcoin is slow and expensive, Ethereum is the future 2. Ethereum software has security hole, gets hacked 3. Ethereum fans say it's an experiment there are lots of things that will transform Ethereum (Casper/PoS, Raiden, zkSNARKs, Enterprise Alliance) 4. Low price getting pumped by Ethereum Foundation & big-holder affiliates 5. Back to #1 We've seen it happen again (DAO) and again (Par…

The other sad thing is that Solidity, the language of Etherium, is a trainwreck. It has tons of bugs, properties that maximize the memory cost of the program, and until ~6 days ago had crazy double init bugs in constructors using "this".

Re: Learn Ethereum smart contract programming

#139

Post by gjem97 »

hackermailman wrote: post #135

If you are considering writing a smart contract, you should read this first https://github.com/ConsenSys/smart-contract-best-practices for Solidity security pitfalls, and hopefully have some idea of invariants/contracts to verify expected properties of your smart contract https://www.cs.cmu.edu/~rjsimmon/15122-s16/lec/01-contracts.... and additionally hope the EVM doesn't have unexpected behavior. Anybody know if the…

It is an interesting question. In addition to any common law covering contracts, there are also some statutes that specifically cover interactions on a computer, like the Computer Fraud and Abuse Act. These laws often refer to "intended use" or "exceeding authorized access". IANAL, but It seems complicated enough that we probably won't really know the answers until a few cases are litigated.

Re: Learn Ethereum smart contract programming

#140

Post by rdiddly »

Thread warning: I'm actively downvoting any argument that tries to address (read: not address) a cryptocurrency's flaws by changing the subject. Example:

Person A: Cryptocurrency X is insecure isn't it.

Person B: So is { the dollar | driving | flying | the internet | * }.

Post reply on HN