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

221–230 of 244 posts

Re: Learn Ethereum smart contract programming

#221

Post by ojr »

airza wrote: post #217
ojr wrote: post #208

Earlier quoted context omitted.

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.

What does this first sentence even mean?

the federal government can reimburse the person I was replying to because they control and mint dollars. With Ethereum you can control and mint your own currency, I didn't want to use the word currency earlier, it is more of a digital asset or app credits.

Re: Learn Ethereum smart contract programming

#222

Post by Cybiote »

grogenaut wrote: post #187
seanwilson wrote: post #175

Earlier quoted context omitted.

> 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. I'm not an expert on Ethereum, but even if they did pick a total language, how would you deal with bounding the CPU cost of complex contracts? Even if you could formally verify a loop would eventually terminate, wouldn't long running loops or those with ex…

I'm not sure static typing is tied to formal verification. In fact if you think about it most proofs are basically typeless I a lot of cases.

Dependent or even refinement type systems are where a great deal of research into proof carrying code is done (for refinement types, since systems are restricted to decidability, the proofs are automatic but more limited).

Re: Learn Ethereum smart contract programming

#223

Post by patrickaljord »

simias wrote: post #210
patrickaljord wrote: post #173

Earlier quoted context omitted.

> 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…

> 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

This shows either little understanding of smart contracts or little imagination. Retailers could make each of their sells contract a 3 party multi-sig contract where the three parties would be you, the retailer and your bank and if you complain to your bank and your bank accepts your request after reviewing the retailer's claim then the money would go back to your account. There could also be other legal entities in the multi-sig contracts such as insurances or others.

> My point is that those "smart" contracts are great for thieves but of dubious values

See my previous point and why this is not correct.

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

They won't get their money back because they didn't pay for an insurance. Coinbase for example guaranties US$ 100k in case of theft. If Ethereum becomes a thing, there would be a whole market of insurances offering what Visa or Coinbase or your local bank offers today.

Last but not least, you're getting robbed every day with fiat money with inflation policies, only you don't see it but it is happening. Inflation lowers the value of your fiat money and that's like robbing you a part of your money without your consent. And you pay a fee for that insurance you mention every time you use your credit card, so not free either and again, any ethereum or bitcoin provider could offer the same insurance for a fee (and coinbase already does to some extend).

Re: Learn Ethereum smart contract programming

#224

Post by KirinDave »

DennisP wrote: post #196
amouat wrote: post #185

Earlier quoted context omitted.

A look at the recent commits would suggest they are correct: https://github.com/ethereum/solidity/commit/e506129aee5745e2...

That's just an added warning, not a bug fix.

Indeed, I mistook the added warning and ticket close for the real fix.

I'm sorry, 18 days, not ~6. I said 1/3rd the real duration. Since Solidity has only been around about 800 days, 12 days is a non-trivial error.

Still: my complaint that the language is poorly architected and dubiously implemented and tested stands.

Re: Learn Ethereum smart contract programming

#225

Post by na85 »

Diti wrote: post #76
na85 wrote: post #61

Earlier quoted context omitted.

>what happens if there is an error in the logic? If you are a big name in the Ethereum community, they will soft fork Ethereum so that your mistake is rolled back.

That isn’t true. Nowadays you can’t fork Ethereum like that by fear of losing legitimate transactions.

>That isn’t true

Precedent seems to indicate otherwise.

Re: Learn Ethereum smart contract programming

#226

Post by omarforgotpwd »

halflings wrote: post #25
omarforgotpwd wrote: post #16

Programmable smart contracts are a great idea in a world where programmers write bug free code. That world does not exist yet. Until we have near-perfect code writing AIs every new smart contract is just a disaster waiting to happen.

That's like saying legal contracts are a disaster because we do not live in an ideal world where lawyers don't do mistakes, and there are no legal loopholes. Granted, bugs are much more common than legal loopholes, but in the same way an operating system's APIs and constraints are tested until it becomes reliable enough for other people to rely on it, I can see some standard types of contracts (in the same way as in…

Legal contracts are enforced by courts, which are run by humans. Humans do not take things 100% literally and there is always an opportunity to change the law. For example someone would not be forced to empty their entire bank account and give it to some random person just because that person discovered a typo in the EULA.

Re: Learn Ethereum smart contract programming

#227

Post by DennisP »

KirinDave wrote: post #224
DennisP wrote: post #196

Earlier quoted context omitted.

That's just an added warning, not a bug fix.

Indeed, I mistook the added warning and ticket close for the real fix. I'm sorry, 18 days, not ~6. I said 1/3rd the real duration. Since Solidity has only been around about 800 days, 12 days is a non-trivial error. Still: my complaint that the language is poorly architected and dubiously implemented and tested stands.

I still don't see a bugfix that matches your complaint. The warning is about the compiler behaving as designed; it's for programmers who are probably using that behavior incorrectly.

Solidity definitely has design warts; possibly Viper will end up the leading language, once it's production-ready.

Re: Learn Ethereum smart contract programming

#228

Post by aeriklawson »

ekidd wrote: post #151
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…

> 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…

Ugh that's... disconcerting to say the least.

Re: Learn Ethereum smart contract programming

#229

Post by seanwilson »

mbrock wrote: post #213
seanwilson wrote: post #207

Earlier quoted context omitted.

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.

I don't have a fully formed view yet, but I think Solidity is a pretty good prototyping language, disregarding all marketing hype that it's an "easy" language. While developing, you'd also be working on a specification of exactly how the contract shall behahve, and trying very hard to simplify ruthlessly. The Parity multisig contract is very complex and I wouldn't and didn't trust any funds with it. I hope that the n…

> The Parity multisig contract is very complex and I wouldn't and didn't trust any funds with it. I hope that the newly deployed fixed multisigs are bug-free but how would you know?

Yeah...any ideas why they didn't go with a language that had an easier route for formal verification? It seems like an ideal application and the contract specifications seem like they would be fairly straightforward to prove (compared to what you'd see in most journal papers for instance). I'm guessing the designers just weren't aware of theorem provers but I'm puzzled why they didn't go with a language with strong static typing where private access and immutability are the defaults plus avoiding anything to do with the mechanism they have for picking default handling functions when a message isn't understood. Great experiment to watch though!

Re: Learn Ethereum smart contract programming

#230

Post by seanwilson »

grogenaut wrote: post #220
seanwilson wrote: post #198

Earlier quoted context omitted.

What proof systems are you thinking about? Strong static types seem the most natural way to introduce formal verification into mainstream programming to me.

Well general mathmatecial proofs or TLA+... or would it be better to define "integer" as a strong type which I'm willing to concede.

I don't feel there's much difference between e.g. the Coq way where types are used to bake specifications + proofs into the program and the Isabelle way where you write a program with less complex types and prove properties about the program after the fact.

General mathematical proofs? If you mean paper proofs they wouldn't be considered formal as they don't go down to the axiom level.

Post reply on HN