Live data from Hacker News

Learn Ethereum smart contract programming

ethereumdev.io

201–210 of 244 posts

Re: Learn Ethereum smart contract programming

#201

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…

Ethereum reminds me of what happened to the web: the desire to add code. The blockchain by itself wasn't good enough so Ethereum added code to it, just like HTML wasn't good enough so people added applets, Flash, and JavaScript. I understand why they would want to do this but I think it gets the priorities wrong. It prioritizes features and functionality over security and reliability. Given how hostile the Internet h…

I actually think this is a great analogy, although not sure your conclusion follows. What happened after people added JavaScript to the web?

Re: Learn Ethereum smart contract programming

#202
post #151
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…

> 2. Ethereum software has security hole, gets hacked The last time this was discussed on Hacker News, I found this comment particularly instructive: https://news.ycombinator.com/item?id=14810008 It points out a great many fundamental issues with the Solidity contract language. Basically, the language design sounds extremely amateurish and it appears to have ignored everything we've learned about security in the last…

You wouldn't trust a bank with an SQL-injection vulnerability or a hospital running on an old version of Windows either but that doesn't mean all banks and hospitals are not trustworthy

A new monetary system created 3 years ago and is highly demanded might have some growing pains

You hold $0 of Ether but suggest on how to spend it, you wouldn't send ether to a contract that was coded poorly or vulnerable so the language is not as important as you make it seem.

Ethereum has a great bug bounty program so contracts that are vulnerable get exposed fast. Each new smart contract should learn lessons for previous contracts and the software will improve over time, imagine that...

Re: Learn Ethereum smart contract programming

#203
post #197

Earlier quoted context omitted.

The gas limit is one reason I think it's weird that people insist on calling the EVM "Turing complete", since one of the most prominent features of the system is that every program is guaranteed to terminate in a finite and low number of steps (via the gas mechanism). Turing complete programs are supposed to be problematic because of the halting problem, but in the EVM, the halting problem is trivial: every program h…

> The gas limit is one reason I think it's weird that people insist on calling the EVM "Turing complete", since one of the most prominent features of the system is that every program is guaranteed to terminate in a finite and low number of steps (via the gas mechanism). Turing complete programs are supposed to be problematic because of the halting problem, but in the EVM, the halting problem is trivial: every program…

The contract coders I work with try as much as possible to avoid loops altogether, because even if they're correct, they'll still have a linear cost, and that's usually not what you want. Almost all contract operations should be O(1). Sometimes we've made fairly large system design changes to avoid a loop in a function.

Re: Learn Ethereum smart contract programming

#204
post #151

Earlier quoted context omitted.

> 2. Ethereum software has security hole, gets hacked The last time this was discussed on Hacker News, I found this comment particularly instructive: https://news.ycombinator.com/item?id=14810008 It points out a great many fundamental issues with the Solidity contract language. Basically, the language design sounds extremely amateurish and it appears to have ignored everything we've learned about security in the last…

I hate immutable variables because I'm lazy but I would definitely use them as a feature in a system like this. Maybe I should reconsider using erlang or my position on immutble variables... Nope that's enough self discovery for today... Carry on. Edit: And again erlang people can't take a joke. I'm literally making fun of myself for having an invalid bias and erlang folks take it as an attachment on the language. It…

There are two distinct features: immutability and single-assignment. Erlang is famous for single-assignment, and also happens to have largely immutable values, but they are not the same thing.

Immutability prevents things like in-place appending to an array, or in-place modification of a string.

Single-assigment means that the value bound to "someVariable" cannot be changed. E.g. `someVariable = new String("hello"); someVariable = new String("goodbye");` is illegal. But it still may be possible to mutate the value `someVariable.substitute("hello", "goodbye")` if the language allows mutation.

Re: Learn Ethereum smart contract programming

#205
post #124

Earlier quoted context omitted.

Not out yet, but Filecoin: https://filecoin.io/ . It's like Ethereum but with file storage capabilities + built-in bridges to other cryptocurrencies.

Filecoin doesn't have any smart contracts as far as I'm aware, so it's limited to use as a decentralized storage network. I believe it would be possible to build something very similar to Filecoin on the Ethereum platform. Storj ( https://storj.io/ ) may be trying to do that.

Edit: Filecoin does mention smart contracts in its white paper.

Re: Learn Ethereum smart contract programming

#206
post #202
post #151

Earlier quoted context omitted.

> 2. Ethereum software has security hole, gets hacked The last time this was discussed on Hacker News, I found this comment particularly instructive: https://news.ycombinator.com/item?id=14810008 It points out a great many fundamental issues with the Solidity contract language. Basically, the language design sounds extremely amateurish and it appears to have ignored everything we've learned about security in the last…

You wouldn't trust a bank with an SQL-injection vulnerability or a hospital running on an old version of Windows either but that doesn't mean all banks and hospitals are not trustworthy A new monetary system created 3 years ago and is highly demanded might have some growing pains You hold $0 of Ether but suggest on how to spend it, you wouldn't send ether to a contract that was coded poorly or vulnerable so the langu…

> You wouldn't trust a bank with an SQL-injection vulnerability or a hospital running on an old version of Windows either but that doesn't mean all banks and hospitals are not trustworthy

I would and do, because that's the reality of things. You're discounting the fact that if my bank has a SQL-injection exploit used against it and my account is drained, the federal government will reimburse me up to $250,000.

That type of peace of mind does not come with Ethereum; in fact it's billed as a feature.

Re: Learn Ethereum smart contract programming

#207
post #203

Earlier quoted context omitted.

> The gas limit is one reason I think it's weird that people insist on calling the EVM "Turing complete", since one of the most prominent features of the system is that every program is guaranteed to terminate in a finite and low number of steps (via the gas mechanism). Turing complete programs are supposed to be problematic because of the halting problem, but in the EVM, the halting problem is trivial: every program…

The contract coders I work with try as much as possible to avoid loops altogether, because even if they're correct, they'll still have a linear cost, and that's usually not what you want. Almost all contract operations should be O(1). Sometimes we've made fairly large system design changes to avoid a loop in a function.

Interesting. So what's your view about the most practical language for writing contracts in then?

For what I've read, having the sender setting gas limits seems really awkward especially when the limit is exceeded. Are there practical alternatives? Even with O(1) you'd need to limit the computation time.

Re: Learn Ethereum smart contract programming

#208
post #206
post #202

Earlier quoted context omitted.

You wouldn't trust a bank with an SQL-injection vulnerability or a hospital running on an old version of Windows either but that doesn't mean all banks and hospitals are not trustworthy A new monetary system created 3 years ago and is highly demanded might have some growing pains You hold $0 of Ether but suggest on how to spend it, you wouldn't send ether to a contract that was coded poorly or vulnerable so the langu…

> You wouldn't trust a bank with an SQL-injection vulnerability or a hospital running on an old version of Windows either but that doesn't mean all banks and hospitals are not trustworthy I would and do, because that's the reality of things. You're discounting the fact that if my bank has a SQL-injection exploit used against it and my account is drained, the federal government will reimburse me up to $250,000. That t…

it is because the federal government mints and controls the currency of dollars, with Ethereum you can create an arbitrary token and mint this token to any amount, essentially be your own federal reserve, Ethereum is an interesting software platform. Coinbase is fully insured all their digital currency is backed if a breach was to happen the customers will be refunded. So I suggest you keep your $250000 in there.

Re: Learn Ethereum smart contract programming

#209
post #102

Earlier quoted context omitted.

I would suggest you read the white paper ( https://github.com/ethereum/wiki/wiki/White-Paper ) The short answer is contracts are accounts. Just like your normal ethereum accounts. When you invoke a method marked as payment, you are essentially transferring some ether from your account to the contract. If someone wrote contract from which you can't withdraw and you send ether to it, thats stupidity - even fiat can be…

I see, thank you :) Stupidity? Doesn't Ethereum want to prevent all money getting locked up somewhere?

Just as much as people want to solve the halting problem.

Re: Learn Ethereum smart contract programming

#210
post #164

Earlier quoted context omitted.

I gave some examples (that you quickly dismissed). Having a recourse through an other, hopefully compassionate and empathetic human being is not something I'm willing to give up on. If things go awry to the point where I could go bankrupt because of a small lapse in judgment I want to have recourses. That's why we have we have consumer laws. That's why we have the notion of abusive contracts. SSL is hardly related. I…

> hopefully compassionate and empathetic human Hopefully after said compassionate human had their lunch break. http://blogs.discovermagazine.com/notrocketscience/2011/04/1... > That's why we have we have consumer laws. That's why we have the notion of abusive contracts. That could still exist with Ethereum. > SSL is hardly related. It's just a mean to secure a transaction and that's it. Your browser's code trust the…

>Your browser's code trust the code on the server hosting the SSL cert and authority server. So, it's just code involved here.

Yes, but "there" is only a small part of the full story. When I make a payment over SSL I don't make an immutable, untraceable and irreversible transaction. In order to be able to receive the payment the other party has to register with a bank and other legal entities etc... Putting money to an ethereum contract is closer to sending cash in an envelope to some PO box in a foreign country. Good luck getting it back if something goes wrong.

>Hopefully after said compassionate human had their lunch break.

Humans make mistakes, humans are unreliable. That's why we have a bunch of checks and balances in any decent justice systems to avoid miscarriages of justice. They're still possible, doesn't mean that the right solution is to get rid of it altogether.

>Again, you could also sue someone for tricking you into a bad ethereum contract and it would not hold in court either. Not sure what your point is here.

So code isn't law, law is law? I think my point is perfectly clear, you just keep moving the goalpost. My point is that those "smart" contracts are great for thieves but of dubious values

Regardless, do you think those people whose wallet was compromised because of the faulty contract will manage to get their money back? Who are they suing, the thieves? The wallet company who wrote the faulty contract? How you do get the money back? Can you freeze the account? Reverse the transactions? Blacklist the coins? The whole cryptocurrency system is designed to make those things impractical, if not downright impossible.

Again, great for thieves and black market sellers but if I just want to buy a laptop on amazon why would I ever bother with this? What's the use case?

Post reply on HN