Learn Ethereum smart contract programming(ethereumdev.io)
ethereumdev.io
Learn Ethereum smart contract programming
https://ethereumdev.io/
243 comments
> 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 30 years. Samples:
- "Operators have different semantics depending on whether the operands are literals or not. For example, 1/2 is 0.5, but x/y for x==1 and y==2 is 0."
- "All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default"
- "Order of evaluation is not defined for expressions. This in a language that has value-returning mutating operators like ++!"
I wouldn't trust a Solidity smart contract with $100.
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 30 years. Samples:
- "Operators have different semantics depending on whether the operands are literals or not. For example, 1/2 is 0.5, but x/y for x==1 and y==2 is 0."
- "All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default"
- "Order of evaluation is not defined for expressions. This in a language that has value-returning mutating operators like ++!"
I wouldn't trust a Solidity smart contract with $100.
Does Solidity really matter, though? "How's the VM" is the real question. I haven't spent more then 10 minutes looking into it, but it seemed reasonable to me. No heap and 256(?)-bit addressing seem like good ideas to keep execution complexity down.
The VM is also fucked (or, at least it was in the recent past) because it turns out that their semantics are a mess. For example, exception handling is either implicit or explicit depending on how a method is invoked!
https://eprint.iacr.org/2016/633
https://eprint.iacr.org/2016/633
It does matter if the use of Solidity is being actively promoted. Sure, maybe you're smart and you'll pick safer options, but if a huge percentage of contracts are written in Solidity, it could still mean there are massive security holes everywhere.
This! ^^
Solidity code is horrible, especially after looking at concise, maintainable, provably correct code.
Solidity code is horrible, especially after looking at concise, maintainable, provably correct code.
Ugh that's... disconcerting to say the least.
[deleted]
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's also a commentary on how long it takes for devs to mind shift and incorporate new ideas.
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's also a commentary on how long it takes for devs to mind shift and incorporate new ideas.
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.
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.
[deleted]
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...
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...
> 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.
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.
Don't worry, they'll just do a fork and magic your money back. So much for avoiding the problems of central banking.
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.
How often do you hear of someone loosing thousands of dollars perminantly because of a banking error? Almost never, because if a bank did not reimburse people who lost money, their reputation would be destroyed. How often do you hear of people losing thousands of dollars because of a cryptocurrency? All the time, because no one is responsible for the lost money, so no one will replace it or work extra hard to ensure it is safe. Security doesn't matter when you have a central authority dedicated to ensuring you don't loose your money, and which had been successfully doing so for decades.
What does this first sentence even mean?
I translated it as "if there is a market opportunity for there being a private, ethereum-backed federal reserve, one will emerge."
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.
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 through it and prove whatever properties you want.
Is the Ethereum world right now full of buggy contracts that haven't been proven correct? Yes, absolutely. It's a disaster. But it's a disaster that points the way fairly straightforwardly.
Should Ethereum not have been launched until it had solid methods for auditing and proving? Maybe, but that's not how the world works, typically. Worse is better and all that.
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 through it and prove whatever properties you want.
Is the Ethereum world right now full of buggy contracts that haven't been proven correct? Yes, absolutely. It's a disaster. But it's a disaster that points the way fairly straightforwardly.
Should Ethereum not have been launched until it had solid methods for auditing and proving? Maybe, but that's not how the world works, typically. Worse is better and all that.
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 more and more convinced that Turing completeness is highly overrated. Almost all code wants to do finite and/or structurally inductive operations. The only case that doesn't fall in that are things like request loops where you want to "infinitely" wait, process request, loop back to waiting. But even those things can be done in total languages via co-induction, so exactly why do we want to make our analysis/verification work more difficult by using a non-total language for things like Ethereum?
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 more and more convinced that Turing completeness is highly overrated. Almost all code wants to do finite and/or structurally inductive operations. The only case that doesn't fall in that are things like request loops where you want to "infinitely" wait, process request, loop back to waiting. But even those things can be done in total languages via co-induction, so exactly why do we want to make our analysis/verification work more difficult by using a non-total language for things like Ethereum?
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.
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.
> 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 expensive computations have bad impacts on the network? Their "gas" system is their way of dealing with that and perhaps you would still need something similar even with a total language.
I can't think of program verification research where both termination and CPU cost is verified. I can think of some papers that deal with identifying Big Oh growth rates though.
Either way, smart contracts sound like one of the top tier areas where you want strong static typing that has a route to be formally verified.
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 expensive computations have bad impacts on the network? Their "gas" system is their way of dealing with that and perhaps you would still need something similar even with a total language.
I can't think of program verification research where both termination and CPU cost is verified. I can think of some papers that deal with identifying Big Oh growth rates though.
Either way, smart contracts sound like one of the top tier areas where you want strong static typing that has a route to be formally verified.
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 halts, period.
> 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 halts, period.
Exactly, knowing that the contract code will eventually halt is nice to know but knowing that it will halt after a reasonable CPU cost seems much more important in this case (which is really interesting).
From what I've seen from example contracts, it doesn't seem like the chance of infinite loops is that high. Personally, I find that in mainstream languages, if you accidentally write an infinite loop you find out very quickly on the first few runs and code that could be hiding an infinite loop stands out. The vast majority of loops just iterate from the start of a collection to the end.
Exactly, knowing that the contract code will eventually halt is nice to know but knowing that it will halt after a reasonable CPU cost seems much more important in this case (which is really interesting).
From what I've seen from example contracts, it doesn't seem like the chance of infinite loops is that high. Personally, I find that in mainstream languages, if you accidentally write an infinite loop you find out very quickly on the first few runs and code that could be hiding an infinite loop stands out. The vast majority of loops just iterate from the start of a collection to the end.
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.
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 newly deployed fixed multisigs are bug-free but how would you know?
Right now I'm working on tools for static analysis of bytecode and using such tools to verify the correctness of contracts written by hand in assembly, which I think makes a great deal of sense for the simple contracts that we need as utilities (multisigs, tokens, etc).
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?
Right now I'm working on tools for static analysis of bytecode and using such tools to verify the correctness of contracts written by hand in assembly, which I think makes a great deal of sense for the simple contracts that we need as utilities (multisigs, tokens, etc).
> 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!
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!
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.
Type checking can be represented as abstract interpretation. It is the mostly widely used kind of formal verification that exists.
What proof systems are you thinking about? Strong static types seem the most natural way to introduce formal verification into mainstream programming to me.
(Not the parent here.) ACL2 is a prominent example of a proof assistant without a strong static type system; its object language is a pure subset of Common Lisp. The lack of static types is one of the reasons I find proving in ACL2 to be painful, but others have done amazing stuff with it.
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.
General mathematical proofs? If you mean paper proofs they wouldn't be considered formal as they don't go down to the axiom level.
I guess that makes sense to count axioms as strongly typed.
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).
Corecursion and codata are cool, and I would trust Solidity vastly more if it were a "total" functional language with no mutable state and aggressive type checking. Or if it were something more like https://www.idris-lang.org/ , where I had abundant tools to rigorously prove that nobody could steal my money.
Basically, if I'm going to spend even 5 minutes playing with smart contracts, I want to feel like the language designers were incredibly paranoid and aware of just how good modern languages can be at provability and security.
Basically, if I'm going to spend even 5 minutes playing with smart contracts, I want to feel like the language designers were incredibly paranoid and aware of just how good modern languages can be at provability and security.
If you're competent with proofs in Idris, you can write your EVM programs as an Idris DSL.
But, I mean, there's no proof that the Idris compiler does what it's supposed to do, so you'd still have a huge trusted base.
But, I mean, there's no proof that the Idris compiler does what it's supposed to do, so you'd still have a huge trusted base.
> If you're competent with proofs in Idris, you can write your EVM programs as an Idris DSL.
Yeah, all my formal proof experience is with Coq, which is just a bit too idiosyncratic and difficult for this sort of thing. But I seem to remember that—especially if you're willing to certify specific results, and not necessarily the program in general—you can make your trusted computing base very small indeed.
I mean, if the CompCert C compiler can be as thoroughly verified as it is (http://compcert.inria.fr/compcert-C.html), there's no reason why it shouldn't be possible to verify smart contracts.
Yeah, all my formal proof experience is with Coq, which is just a bit too idiosyncratic and difficult for this sort of thing. But I seem to remember that—especially if you're willing to certify specific results, and not necessarily the program in general—you can make your trusted computing base very small indeed.
I mean, if the CompCert C compiler can be as thoroughly verified as it is (http://compcert.inria.fr/compcert-C.html), there's no reason why it shouldn't be possible to verify smart contracts.
> I mean, if the CompCert C compiler can be as thoroughly verified as it is (http://compcert.inria.fr/compcert-C.html), there's no reason why it shouldn't be possible to verify smart contracts.
Hmm, so from the smart contract examples I've seen, I would have thought writing them in something like Coq would be quite feasible. The code examples I've seen tend to only have simple loops if any, basic conditions and the code is short (e.g. compared to something like web development or mobile apps). Writing anything inside a theorem prover is very challenging though but it seems a compelling application.
If you were implementing a smart contract in something like Coq, I'd be interested to read about what kind of specifications you would typically want to verify. I guess properties like "the owner of this wallet cannot be changed" and "the owner of this wallet can only accept money but not give it away" would be good ones.
Hmm, so from the smart contract examples I've seen, I would have thought writing them in something like Coq would be quite feasible. The code examples I've seen tend to only have simple loops if any, basic conditions and the code is short (e.g. compared to something like web development or mobile apps). Writing anything inside a theorem prover is very challenging though but it seems a compelling application.
If you were implementing a smart contract in something like Coq, I'd be interested to read about what kind of specifications you would typically want to verify. I guess properties like "the owner of this wallet cannot be changed" and "the owner of this wallet can only accept money but not give it away" would be good ones.
Some pointers you might appreciate:
Jack Petterson and Robert Edström did a master's thesis about retargeting the Idris compiler to emit EVM code, with a custom effect type to express smart contract effects. They ended up modestly skeptical of functional programming as a paradigm for EVM, instead looking toward process calculi. https://publications.lib.chalmers.se/records/fulltext/234939...
Yoichi Hirai's summary of his research into Ethereum formal verification as a full-time formal methods researcher at the Foundation: https://github.com/pirapira/ethereum-formal-verification-ove...
See especially his formalization of the EVM as Hoare triples in Lem, which is usable from Isabelle: https://github.com/pirapira/eth-isabelle -- very cool stuff, although I have to say that the ostensible complexity and difficulty of his proof verifying an utterly simple wallet contract makes me a bit skeptical of this approach to smart contract correctness: https://github.com/pirapira/eth-isabelle/blob/master/example...
Jack Petterson and Robert Edström did a master's thesis about retargeting the Idris compiler to emit EVM code, with a custom effect type to express smart contract effects. They ended up modestly skeptical of functional programming as a paradigm for EVM, instead looking toward process calculi. https://publications.lib.chalmers.se/records/fulltext/234939...
Yoichi Hirai's summary of his research into Ethereum formal verification as a full-time formal methods researcher at the Foundation: https://github.com/pirapira/ethereum-formal-verification-ove...
See especially his formalization of the EVM as Hoare triples in Lem, which is usable from Isabelle: https://github.com/pirapira/eth-isabelle -- very cool stuff, although I have to say that the ostensible complexity and difficulty of his proof verifying an utterly simple wallet contract makes me a bit skeptical of this approach to smart contract correctness: https://github.com/pirapira/eth-isabelle/blob/master/example...
Etherium should have launched with a language that wasn't a high-school-extra-cirricular-level in terms of construction and consideration.
Solidity doesn't have a problem with formal verification of programs. Check their bug tracker: you can't even trust the runtime to do what it claims to do. On several levels.
Solidity doesn't have a problem with formal verification of programs. Check their bug tracker: you can't even trust the runtime to do what it claims to do. On several levels.
> It's a disaster. But it's a disaster that points the way fairly straightforwardly.
A disaster that could have been avoided if they had done a little more research on security and smart contract languages:
http://lambda-the-ultimate.org/node/5003
Solidity is still clearly focused on programming productivity instead of contract soundness. The built in dynamism is proof of this.
A disaster that could have been avoided if they had done a little more research on security and smart contract languages:
http://lambda-the-ultimate.org/node/5003
Solidity is still clearly focused on programming productivity instead of contract soundness. The built in dynamism is proof of this.
> Should Ethereum not have been launched until it had solid methods for auditing and proving? Maybe, but that's not how the world works, typically. Worse is better and all that.
As a platform for experimentation that's fine. As a platform for doing real things with meaningful amounts of money, it's madness.
As a platform for experimentation that's fine. As a platform for doing real things with meaningful amounts of money, it's madness.
Madness indeed. For better or for worse, silly experiments in this industry often turn out to win. According to the "Worse is Better" theory, that's partly because they ship much faster than the projects that want to get everything right, and they're also easier for most people to understand. You could put a team of Ph.D's on inventing a really amazing smart contract formalism based on higher-order zygomorphic type theory, but if only five people in the universe understood it, we wouldn't be talking about it.
This would be compelling were it to contain accurate information. However, likening the parity incident to a "hack of ethereum" is like saying the USD is flawed because wells fargo was broken into. The same thing is true for the DAO, although it is indeed more complex in that the _resolution_ of it was handled by Ethereum proper. I think that was questionable.
Literally no one within Ethereum calls it an experiment. You have to cherry-pick from population and then ascribe it to the whole for this to be even sensical.
Essentially every technology we can think of can be rooted back to the 90s, or really any period we want to look at since that is how knowledge works. If you've got a particular, say it...rather than just this poor, lazy attempt at a sort of character assassination by employee (fairly inaccurate) appeal to oldness.
It is thoroughly _without merit_ to suggest that the analogous components of ETH and BTC have BTC being more secure. In fact, the opposite is true by any reasonable measure. Further, there are indeed things that Ethereum tries to do that add complexity, but if they come with value we shouldn't then find ourselves saying things like you do that amount to a sort of "my abacus is more secure than quickbooks online" - different purposes, solving different problems and creating different sorts of value. Even beyond that BTC holds all records for security events and $ cost of them, coin-loss amounts of of them, and so on.
Literally no one within Ethereum calls it an experiment. You have to cherry-pick from population and then ascribe it to the whole for this to be even sensical.
Essentially every technology we can think of can be rooted back to the 90s, or really any period we want to look at since that is how knowledge works. If you've got a particular, say it...rather than just this poor, lazy attempt at a sort of character assassination by employee (fairly inaccurate) appeal to oldness.
It is thoroughly _without merit_ to suggest that the analogous components of ETH and BTC have BTC being more secure. In fact, the opposite is true by any reasonable measure. Further, there are indeed things that Ethereum tries to do that add complexity, but if they come with value we shouldn't then find ourselves saying things like you do that amount to a sort of "my abacus is more secure than quickbooks online" - different purposes, solving different problems and creating different sorts of value. Even beyond that BTC holds all records for security events and $ cost of them, coin-loss amounts of of them, and so on.
> the takeover-the-world echo-chambers of ethereum
You toss out this pejorative description, and then in the next paragraph:
> When talking about engineering on such a critical subject, people should be way more responsible.
This is absurd. How could it ever become critical without a lot of research and development first?
I've been holding a handful of Ethereum since there was a decent dip in the price. I haven't spent much time on it and I have no good leads for program ideas yet, but if the code is buggy and I get hacked and lose my investment, that's fine. A smart contract is a project, and it could fail like any other.
Don't put your retirement savings in a smart contract right now unless you're OK with losing it all. Maybe in the future Ethereum will move beyond this phase, and maybe not. All the drama is ridiculous, everyone needs to chill out.
You toss out this pejorative description, and then in the next paragraph:
> When talking about engineering on such a critical subject, people should be way more responsible.
This is absurd. How could it ever become critical without a lot of research and development first?
I've been holding a handful of Ethereum since there was a decent dip in the price. I haven't spent much time on it and I have no good leads for program ideas yet, but if the code is buggy and I get hacked and lose my investment, that's fine. A smart contract is a project, and it could fail like any other.
Don't put your retirement savings in a smart contract right now unless you're OK with losing it all. Maybe in the future Ethereum will move beyond this phase, and maybe not. All the drama is ridiculous, everyone needs to chill out.
>"I've been holding a handful of Ethereum since there was a decent dip in the price. I haven't spent much time on it and I have no good leads for program ideas yet, but if the code is buggy and I get hacked and lose my investment, that's fine. A smart contract is a project, and it could fail like any other.
Don't put your retirement savings in a smart contract right now unless you're OK with losing it all. Maybe in the future Ethereum will move beyond this phase, and maybe not. All the drama is ridiculous, everyone needs to chill out."
This is the exact spiel we're all sick of hearing.
This is the exact spiel we're all sick of hearing.
Why are you sick of hearing it? Why are you even in this thread? If ethereum is so dumb, why do you care so much?
because you're shilling for a pyramid scheme , and it's not even a secure pyramid scheme. the software its's built on is shit, from top to bottom.
The people writing programs on it are writing bad programs.. but even if they write them well the environment has vulnerability built into it .
>Why are you even in this thread?
Why are you here? it's one of the top posts on this site today.
The people writing programs on it are writing bad programs.. but even if they write them well the environment has vulnerability built into it .
>Why are you even in this thread?
Why are you here? it's one of the top posts on this site today.
Which part do you have a problem with?
>I've been holding a handful of Ethereum since there was a decent dip in the price.
You opened by explain how you clearly have an interest in this, you got in, and since you are saying you bought during a "decent dip" that means you only got in recently.
The rest of your post would be shilling only that you disclosed your interest.
You opened by explain how you clearly have an interest in this, you got in, and since you are saying you bought during a "decent dip" that means you only got in recently.
The rest of your post would be shilling only that you disclosed your interest.
> The rest of your post would be shilling only that you disclosed your interest.
So I would be shilling in a hypothetical scenario, and that's the problem?
OK, whatever. Have a nice day.
So I would be shilling in a hypothetical scenario, and that's the problem?
OK, whatever. Have a nice day.
That's the problem yes, you bought into a pyramid scheme and you need others to buy in if you want to get out with more money.
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".
Looking at Solidity's release log, the last update was 18 days ago. It fixed some minor bugs from the previous release three days prior, and none of the bugfixes mentioned in the previous release seem to fit your description. Do you have a link?
https://github.com/ethereum/solidity/releases
https://github.com/ethereum/solidity/releases
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.
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.
Solidity definitely has design warts; possibly Viper will end up the leading language, once it's production-ready.
Worth mentioning that there is at least one other language being built on top of the EVM:
https://github.com/pirapira/bamboo
This one takes a strict state machine approach, and aims to solve some of the tricky reentry and state tracking problems of Solidity.
https://github.com/pirapira/bamboo
This one takes a strict state machine approach, and aims to solve some of the tricky reentry and state tracking problems of Solidity.
"but the takeover-the-world echo-chambers of ethereum that don't focus at all on the real tech behind it and ignore everything negative is pretty disappointing"
i dont think this is a good representation of the ethereum community, most people on r/ethereum for example are quiet self conscious about the security issues. that is at least my impression from reading the threads there.
"90s cypherpunks that pioneered this ideas had considered Turing complete design and discarded it for cryptographic state-machines that allow for formal verification" - are you referring to Bitcoin?
Or some other ideas that aren't currently implemented?
Or some other ideas that aren't currently implemented?
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.
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 see this with Ethereum.
Even with bitcoin which is complex the benefits are instantaneous for the common man. Decentralized system, no single entity controls it. It is a fixed amount of bitcoins so like a mineral it's value is probably going to be stable in the long run and also each bitcoin will increase in value when more people get interested. It's easy to send coins to anyone in the world, at any time.
What does Ethereum do? Smart contracts is probably the key word but I don't understand how it works or how it will benefit me. Why bother?
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 see this with Ethereum.
Even with bitcoin which is complex the benefits are instantaneous for the common man. Decentralized system, no single entity controls it. It is a fixed amount of bitcoins so like a mineral it's value is probably going to be stable in the long run and also each bitcoin will increase in value when more people get interested. It's easy to send coins to anyone in the world, at any time.
What does Ethereum do? Smart contracts is probably the key word but I don't understand how it works or how it will benefit me. Why bother?
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 has become I think this is a mistake.
My guess is that Ethereum is only a couple of scandals away from being perceived as a fundamentally insecure platform. Bitcoin has its own problems and it may not survive either. Perhaps another cryoto currency can learn from the mistakes of both and deliver something better?
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 has become I think this is a mistake.
My guess is that Ethereum is only a couple of scandals away from being perceived as a fundamentally insecure platform. Bitcoin has its own problems and it may not survive either. Perhaps another cryoto currency can learn from the mistakes of both and deliver something better?
> Ethereum reminds me of what happened to the web: the desire to add code.
Also known as Zawinski's law: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
Also known as Zawinski's law: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
I actually think this is a great analogy, although not sure your conclusion follows. What happened after people added JavaScript to the web?
In my view what happened was usability and security suffered. See for example, https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=JavaScript
I have no problem with JavaScript itself, it allows developers to build some amazing web applications. What I object to is the default use of JS for every web site. I would rather see JS limited to a small set of trusted sites and HTML (with server side rendering if needed) for everyone else.
I have no problem with JavaScript itself, it allows developers to build some amazing web applications. What I object to is the default use of JS for every web site. I would rather see JS limited to a small set of trusted sites and HTML (with server side rendering if needed) for everyone else.
This! A money exchange platform can't be both distributed and unrealiable. If PayPal screws up, at least you can call them and get a refund.
You know Bitcoin is useful. One of the useful things in Bitcoin is that you can make a transaction conditional on a multiparty approval ("multisig"). This is used by many organizations to control funds in a safe way. Ethereum lets you construct even more interesting types of transactions. For example you can easily implement the logic of a crowdfunding (unless X is raised by time Y everyone is refunded). In that context, "smart contract" is just a way of saying that you're not relying on the promise of a third party to perform the refund—it's automatic.
> In that context, "smart contract" is just a way of saying that you're not relying on the promise of a third party to perform the refund—it's automatic
What if the code is malicious, and instead of auto refund it steals the money? I mean, not everyone would read the code to see what it really does, so what happens in that case?
What if the code is malicious, and instead of auto refund it steals the money? I mean, not everyone would read the code to see what it really does, so what happens in that case?
That is a very good question that is the subject of a lot of denial. You might want to read about the DAO hack and the Parity wallet hack. You will notice there are two different possible outcomes: in the first case, some of the Ethereum founders were major victims, and they used their influence to persuade a majority of the miners to implement a 'hard fork' to essentially roll back the blockchain. In the second case, the victims do not appear to be well-connected, and it seems their missing ~$30M of Eth is irretrievably lost (and it is not clear to me that a second hard fork would be feasible at this point, regardless of who the victims are.)
> I mean, not everyone would read the code to see what it really does, so what happens in that case?
This is true with real world contracts too, that's why people hire lawyers - they understand the "code" of contract law.
This is true with real world contracts too, that's why people hire lawyers - they understand the "code" of contract law.
Except that in real-world contract and criminal law, there are various mechanisms that attempt, with some degree of success, to dissuade fraudulent behavior and allow for some form of restitution. Blockchain currencies, on the other hand, have been promoted partly on the premise that they are free of this sort of governmental interference.
Promoters gonna promote. Governments gonna govern.
You can put anything in "real world" contracts (in a 'put words on the paper' sense), but there are things that would be considered illegal if brought to court. In a sense there are reasonable defaults. So if you sign without reading a contract that 'you sell your self as a slave to me' this contract would have no power because slavery is illegal.
But real world contracts are never 100% clear, and can be modified retroactively in court when their terms violate the law, are vague, or are otherwise deemed unenforceable.
So can "smart contracts".
Unless the attacker is careless enough to reveal his identity, or puts his ill-gotten gains at risk of being hacked back, or the victims are Ethereum foundation members, your chances of restoration are slim to none.
So I'm actually at a disadvantage here, compared to plain old contracts.
Yes. If one party makes a mistake, or does something underhanded/surreptitious, you have no recourse. This exact situation (a bug in the DAO contract leading to a malicious actor stealing from the DAO) led to the recent Ethereum fork: https://news.ycombinator.com/item?id=14819268
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.
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.
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.
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.
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.
More accurately - judges and lawyers interpret law, contract and otherwise. This sort of interpretation is explicitly ruled out in Ethereum's case, except when enough stakeholders decide it's not.
One approach is that contracts can be associated with their hash. It is a bit silly for everyone to be writing the same smart contract over and over, with some versions being erroneous or malicious. So instead of having to run a potentially malicious contract, you are given a hash that points to one of a few different smart contracts that are known to be safe. The community has "white listed" a bunch of these known contracts and their hashes, so you are relatively safe using any contracts in these lists. Most miners in various cryptocurrencies will only run code that is on their communities version of the whitelist. Of course this only helps with some issues, not all.
*edit: and this is not ethereum specific. This approach was one way bitcoin tried to solve the problem and it has spread to most other cryptocurrencies I believe.
*edit: and this is not ethereum specific. This approach was one way bitcoin tried to solve the problem and it has spread to most other cryptocurrencies I believe.
There's no good solution for that problem yet. It's still in some sense better than centralized trust, because you can in principle understand the contract code. But we need to develop much better tools for auditing. Fortunately that's a really fun and interesting problem to work on!
Ok but that raises a lot of technical questions. Do I myself host that logic or is the logic itself distributed? While creating a crowdfunding contract, I am the host in my mind so assuming that the smart contract is hosted on my machines this must mean that when people are sending Ethereum to my wallet the logic does it's thing?
Another version of that could be that the logic is sent out to all interested peers and they only actually send Ethereum to the correct wallet after the logic in the contract they got sent is executed.
This is the parts of Ethereum that is so very confusing. People are simply swinging around with words like "smart contracts" but there are little to no actual description on how it actually works.
Another version of that could be that the logic is sent out to all interested peers and they only actually send Ethereum to the correct wallet after the logic in the contract they got sent is executed.
This is the parts of Ethereum that is so very confusing. People are simply swinging around with words like "smart contracts" but there are little to no actual description on how it actually works.
The logic exists on the block chain. It is executed on each and every machine that follows the chain. This is how executions are verified, 'everyone' has to agree on the outcome.
Sorry for being so uninformed but what happens if there is an error in the logic? Doesn't that mean that it's not possible to update the smart contract?
There have already been multiple incidents involving bugs in "smart contract" code being exploited to steal funds, one within the past few days[1]. A particularly nasty case involved something called "the DAO", which was an attempt to do something like a distributed VC fund, but had a bug which allowed any participant to steal all funds contributed. That one got backed out by a hard fork of the Ethereum blockchain, but that's obviously not a stable or scalable solution to dealing with these types of situations going forward.
[1] https://www.theregister.co.uk/2017/07/20/us30_million_below_...
[1] https://www.theregister.co.uk/2017/07/20/us30_million_below_...
Basically yes, and this is reasonable from a security perspective, otherwise every smart contract would basically have a trusted administrator.
But in many cases you do want some ability to upgrade the code, and then you simply program in that ability by creating a repointable proxy with whatever authorization logic you want.
But in many cases you do want some ability to upgrade the code, and then you simply program in that ability by creating a repointable proxy with whatever authorization logic you want.
Yes the block chain is by definition immutable. So no means to update the contract the only way if it is a ENORMOUS mistake would be to fork it: read about DAO hack FYI
>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.
If you are a big name in the Ethereum community, they will soft fork Ethereum so that your mistake is rolled back.
Of course there are a lot of technical questions. To answer this one, the logic is distributed and executed on every full node. It's like one big distributed database where a transaction can also create a stored procedure.
No the smart contract is on the blockchain and executed by the nodes. Never on your specific host alone
When you write a smart contract, the natural route is to deploy it into the Ethereum public network. Otherwise, your contract is only accessible to your own private channel and uses your own tokens (as opposed to Ether), etc.
Some clarifications: Ethereum = the project or the foundation itself Ether = unit of (crypto)currency used in Ethereum
Some clarifications: Ethereum = the project or the foundation itself Ether = unit of (crypto)currency used in Ethereum
Just shifting the problem. Okay, so the money is raised... you still never get your vaporware product.
You could program a smart contract to say "unless greater than half of funders agree tbat the product was shipped, refund everyone's money"
It's a programmable decentralized escrow
It's a programmable decentralized escrow
What incentive do the funders have to agree that the product was shipped?
I mean, it's pretty obvious that such agreement on the part of the funders increases the likelihood that they will lose their money. So why agree?
I guess the person shipping the product could hope that the funders aren't assholes or theives and actually will agree that the product was shipped when it ships, but isn't the smart contract supposed to make such human signs of good will unnecessary? Otherwise, why have a smart contract (or any contract, really), as you can just rely on the good will of the participants?
I mean, it's pretty obvious that such agreement on the part of the funders increases the likelihood that they will lose their money. So why agree?
I guess the person shipping the product could hope that the funders aren't assholes or theives and actually will agree that the product was shipped when it ships, but isn't the smart contract supposed to make such human signs of good will unnecessary? Otherwise, why have a smart contract (or any contract, really), as you can just rely on the good will of the participants?
> 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 e-bay auction process as a smart contract that's controlled directly by the monetary framework, without involving Paypal or credit card companies, or any other centrally managed financial institutions.
The core idea behind Ethereum is sound and first envisioned a long time ago [1], but the current implementation leaves a lot to be desired. The Ethereum languages are being designed by programmers who try to address the needs one encounters in programming, like delegation patterns and some types of dynamism that makes extension and reuse easier.
Unfortunately, this is often the opposite of what you want for robust contracts, where writing the contract is not the important part, it's understanding all of the possible outcomes and what causes them. The dynamism makes static analysis hard, so understanding the behaviour of the complete system is too difficult, and vulnerabilities proving this point will continue to crop up.
[1] http://erights.org/smart-contracts/index.html
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 e-bay auction process as a smart contract that's controlled directly by the monetary framework, without involving Paypal or credit card companies, or any other centrally managed financial institutions.
The core idea behind Ethereum is sound and first envisioned a long time ago [1], but the current implementation leaves a lot to be desired. The Ethereum languages are being designed by programmers who try to address the needs one encounters in programming, like delegation patterns and some types of dynamism that makes extension and reuse easier.
Unfortunately, this is often the opposite of what you want for robust contracts, where writing the contract is not the important part, it's understanding all of the possible outcomes and what causes them. The dynamism makes static analysis hard, so understanding the behaviour of the complete system is too difficult, and vulnerabilities proving this point will continue to crop up.
[1] http://erights.org/smart-contracts/index.html
> 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.
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.
The question is why only a handful of people are able to write correct contracts. The answer is that Ethereum/Solidity didn't create a high-level smart contract language, they created a low-level procedural programming language with some smart contract abstractions. This type of language is already known to pose many difficulties.
If they had started with something like Nick Szabo's smart contract language, which is declarative, temporal and reactive, this would make smart contracts more intuitive and easier to get right. This sort of programming language has been empirically verified to be easier for most people to grasp.
If they had started with something like Nick Szabo's smart contract language, which is declarative, temporal and reactive, this would make smart contracts more intuitive and easier to get right. This sort of programming language has been empirically verified to be easier for most people to grasp.
The big thing that helped me was to understand that:
smart contract == program stored on the blockchain
The blockchain tracks the program's state and handles state transitions. Read-only functions are free to execute; functions that alter the program's state cost Ethereum to run.
That's it. It's quite powerful and conceptually simple, but the phrase "smart contract" seems to throw a lot of people off.
The blockchain tracks the program's state and handles state transitions. Read-only functions are free to execute; functions that alter the program's state cost Ethereum to run.
That's it. It's quite powerful and conceptually simple, but the phrase "smart contract" seems to throw a lot of people off.
I've got that now but that worries me even further. I don't trust myself to create bug-free programs and are in the belief that it's impossible.
The issue with the system is that you can't update the contract, which means it has to be perfect when it is distributed on the blockchain. 1 bad mistake away from loosing maybe the entire wallet and it seems to already have happened several times.
The main issue that it is a big incentive to find bugs since you can make a lot of money from it and the contracts are vulnerable since they can't be updated.
But people in favor of this system, Ethereum, seems to just wave shit like that off with fancy words. If some system handles my money, it better be damn secure and the only way to be secure IMO is constantly updating it.
The issue with the system is that you can't update the contract, which means it has to be perfect when it is distributed on the blockchain. 1 bad mistake away from loosing maybe the entire wallet and it seems to already have happened several times.
The main issue that it is a big incentive to find bugs since you can make a lot of money from it and the contracts are vulnerable since they can't be updated.
But people in favor of this system, Ethereum, seems to just wave shit like that off with fancy words. If some system handles my money, it better be damn secure and the only way to be secure IMO is constantly updating it.
>> "I don't trust myself to create bug-free programs and are in the belief that it's impossible."
And the recent hack exploited exactly this: a harmless-looking piece of code that turned out to have a serious bug allowing re-initialization of a wallet. The exploit allowed black hats to take control of certain unpatched wallets.
And the recent hack exploited exactly this: a harmless-looking piece of code that turned out to have a serious bug allowing re-initialization of a wallet. The exploit allowed black hats to take control of certain unpatched wallets.
If you understand Bitcoin benefits as: "decentralized no single entity controls"
Then, think of Etherium as: decentralized virtual slot machines no single entity controls
So visualize a slot machine: it advertises only the various ways you could win (in fact it never discloses the number of non winning combinations which are far greater in number) in other words manufacturers advertise only the possible upside to get you to put your money in. At best the thing being advertised happens at worst something else occurs which wasn't advertised, namely you lose your money.
The big difference between smart contracts and slot machines, is the ownership, in theory the casino owns the slot machines or at least leases the slot machine from the manufacturer, and so the casino gets the profits guaranteed by the code of the slot machine. Similarly smart contracts are crated/manufactured by an individual or groups of individuals, But here is where is gets tricky...instead of a casino hosting slot machines, smart contracts will live in perpetuity hosted on a blockchain. So whereas the slot machine directs funds that aren't wins to the casino, where do such funds in the smart contracts go? To wherever the smart contract tells the funds to go, even if it's an anonymous account (really owned by the smart contract creators) or the ability for any 3rd party to claim said funds. This little trick of anonymity allows the contract manufacturers to at least claim ignorance of the location of the funds.
There is one more thing to remember, Proponents of the smart contract somehow believe between the step the manufacturer creates the contract and releases said smart contract in the wild in perpetuity, by placing the smart contract on the blockchain, they somehow become indemnified legally (both civilly and criminally) from any damages the smart contract causes. In a most extreme example proponents i talk to believe you could build a bomb coded to go off upon a funding event, and once placed on the blockchain they would have no liability for the damage caused by the bomb because they claim the bomb was controlled/detonated by the code.
Then, think of Etherium as: decentralized virtual slot machines no single entity controls
So visualize a slot machine: it advertises only the various ways you could win (in fact it never discloses the number of non winning combinations which are far greater in number) in other words manufacturers advertise only the possible upside to get you to put your money in. At best the thing being advertised happens at worst something else occurs which wasn't advertised, namely you lose your money.
The big difference between smart contracts and slot machines, is the ownership, in theory the casino owns the slot machines or at least leases the slot machine from the manufacturer, and so the casino gets the profits guaranteed by the code of the slot machine. Similarly smart contracts are crated/manufactured by an individual or groups of individuals, But here is where is gets tricky...instead of a casino hosting slot machines, smart contracts will live in perpetuity hosted on a blockchain. So whereas the slot machine directs funds that aren't wins to the casino, where do such funds in the smart contracts go? To wherever the smart contract tells the funds to go, even if it's an anonymous account (really owned by the smart contract creators) or the ability for any 3rd party to claim said funds. This little trick of anonymity allows the contract manufacturers to at least claim ignorance of the location of the funds.
There is one more thing to remember, Proponents of the smart contract somehow believe between the step the manufacturer creates the contract and releases said smart contract in the wild in perpetuity, by placing the smart contract on the blockchain, they somehow become indemnified legally (both civilly and criminally) from any damages the smart contract causes. In a most extreme example proponents i talk to believe you could build a bomb coded to go off upon a funding event, and once placed on the blockchain they would have no liability for the damage caused by the bomb because they claim the bomb was controlled/detonated by the code.
I am assuming you have gone through the Ethereum whitepaper. It does lists some potential use cases which can be extrapolated. http://fermatslibrary.com/s/ethereum-a-next-generation-smart...
I have not.
Do you really think I should have to?
Do you really think I should have to?
No I don't think you need to do that to get interested in it. If you want to see it in action and spin up a playground really quickly, I suggest using Embark (https://github.com/iurimatias/embark-framework). (I contribute to this project)
This is a very interesting retort.
No you don't have to. You just have to trust that the community has provided you with a secure, usable tool.
It is unreasonable to expect you to understand the engineering that goes into this kind of thing, if you are not a computer science educated individual. That is not the point of participation though. Developers don't have an intrinsic right to participate.
The exclusion because of complexity is unfortunate, but necessary. Making something that is decentralised, distributed, trustless, useful, simple (in terms of contract execution) and secure is nearly impossible without technical feat.
But you don't need to understand the mechanics of Ethereum or the EVM. The minimum you need to understand is tha Ethereum is used like fuel to pay for contract execution (GAS).
Solidity is not a hard language to grasp. It has simple inputs and outputs. Why not try playing with solidity code on the testnet compiler if you don't want to read the whitepaper.
https://ethereum.github.io/browser-solidity/
Or do a Udemy course.
:)
No you don't have to. You just have to trust that the community has provided you with a secure, usable tool.
It is unreasonable to expect you to understand the engineering that goes into this kind of thing, if you are not a computer science educated individual. That is not the point of participation though. Developers don't have an intrinsic right to participate.
The exclusion because of complexity is unfortunate, but necessary. Making something that is decentralised, distributed, trustless, useful, simple (in terms of contract execution) and secure is nearly impossible without technical feat.
But you don't need to understand the mechanics of Ethereum or the EVM. The minimum you need to understand is tha Ethereum is used like fuel to pay for contract execution (GAS).
Solidity is not a hard language to grasp. It has simple inputs and outputs. Why not try playing with solidity code on the testnet compiler if you don't want to read the whitepaper.
https://ethereum.github.io/browser-solidity/
Or do a Udemy course.
:)
Judging by the frequency which which catastrophic bugs seem to appear within smart contracts, it appears that most users of the platform also don't grok the complexity of the Ethereum network and it's vulnerability to bugs.
This argument can get dangerously close to 'clever people have invested a lot of time and effort into this, so you should either invest the same amount of time and effort or trust that the whole thing is safe.'
Not sure this holds up, especially when increasingly people are being asked to trust Ethereum, but anything, like Parity, that interacts with it.
This argument can get dangerously close to 'clever people have invested a lot of time and effort into this, so you should either invest the same amount of time and effort or trust that the whole thing is safe.'
Not sure this holds up, especially when increasingly people are being asked to trust Ethereum, but anything, like Parity, that interacts with it.
It's true that abstractions require trust.
Have you flown anywhere lately? Inspected the plane before you took off?
It's true for the risk you take you must be assured that engineers are making things safe.
Lots of planes crashed before we got to the incredible safety record we have today, which is paid for by people having trust in airlines, who employ competent engineers.
The only difference here is that the organisation is a decentralised one. The engineers are not paid but are incentivised by the network.
It will take time to remove errors from the network and for best practices to emerge. As for novices making basic errors and losing money. The internet is littered with problems like that in all languages.
This is not a reason to not attempt to do something new.
Have you flown anywhere lately? Inspected the plane before you took off?
It's true for the risk you take you must be assured that engineers are making things safe.
Lots of planes crashed before we got to the incredible safety record we have today, which is paid for by people having trust in airlines, who employ competent engineers.
The only difference here is that the organisation is a decentralised one. The engineers are not paid but are incentivised by the network.
It will take time to remove errors from the network and for best practices to emerge. As for novices making basic errors and losing money. The internet is littered with problems like that in all languages.
This is not a reason to not attempt to do something new.
> Lots of planes crashed before we got to the incredible safety record we have today, which is paid for by people having trust in airlines, who employ competent engineers.
> The only difference here is that the organisation is a decentralised one. The engineers are not paid but are incentivised by the network.
ETH Engineers are also disincentivized from refactoring code / doing CD, as they have to pay a fee for every deploy. I'd imagine that the safety record for airlines would not look as it is today if engineers had to pay a small fee for every safety modification they wished to make.
The analogy with airlines is also faulty. There is no real financial incentive for a bad actor to find a software bug that is capable of crashing an airliner. There's nothing financially they can gain out of it. However, with the amount of money bound up in the ETH network even currently, any bug found by a bad actor could potentially land millions of dollars. Almost any amount of time spent pen-testing is trivial compared to that, so you will find a lot of bad actors actively seeking to find software vulnerabilities.
> The only difference here is that the organisation is a decentralised one. The engineers are not paid but are incentivised by the network.
ETH Engineers are also disincentivized from refactoring code / doing CD, as they have to pay a fee for every deploy. I'd imagine that the safety record for airlines would not look as it is today if engineers had to pay a small fee for every safety modification they wished to make.
The analogy with airlines is also faulty. There is no real financial incentive for a bad actor to find a software bug that is capable of crashing an airliner. There's nothing financially they can gain out of it. However, with the amount of money bound up in the ETH network even currently, any bug found by a bad actor could potentially land millions of dollars. Almost any amount of time spent pen-testing is trivial compared to that, so you will find a lot of bad actors actively seeking to find software vulnerabilities.
>There is no real financial incentive for a bad actor to find a software bug that is capable of crashing an airliner.
Not heard of plane hijacking?
ETH engineers are totally incentivised to write the most perfect code possible. With a world of people wanting disintermediation, the rewards for getting and keeping it right and safe are incredible. Partly because the penalties are too.
The compensation for running and maintaining good secure contracts is exactly the incentive needed. You should try and understand the workflow before blindly critiquing it. CD is not a real feature of blockchain technology, and neither should it be. Does NASA run CD on satellite software? Can you run CD on a plane in mid flight?
It is exactly the same thing as flight and space software. You get one chance to get it right. You get paid for doing good work - by the network.
I've never ever heard an ethereum developer complain about the cents they have to pay to deploy a contract, after having extensively tested it on the testnet for free.
Not heard of plane hijacking?
ETH engineers are totally incentivised to write the most perfect code possible. With a world of people wanting disintermediation, the rewards for getting and keeping it right and safe are incredible. Partly because the penalties are too.
The compensation for running and maintaining good secure contracts is exactly the incentive needed. You should try and understand the workflow before blindly critiquing it. CD is not a real feature of blockchain technology, and neither should it be. Does NASA run CD on satellite software? Can you run CD on a plane in mid flight?
It is exactly the same thing as flight and space software. You get one chance to get it right. You get paid for doing good work - by the network.
I've never ever heard an ethereum developer complain about the cents they have to pay to deploy a contract, after having extensively tested it on the testnet for free.
The issue with that is I don't trust it to be secure. If you make 1 mistake you can loose everything without a possibility to fix your mistake.
This is valid. Better systems of audit are already emerging to tackle this particular problem.
[deleted]
Yes...
Maybe if you actually used it you'd see the benefits of it... try transferring any amount of value with Bitcoin.. take note of how much it costs and how long it takes. Then do the same with Ethereum. You'll start to learn pretty quickly what some of the main differences are.
Regarding the 'fixed amount of Bitcoins' argument, I'd agree it's a nice simple marketing message but if you look in to what Ethereum is planning to do, issuance could well go to close to zero, zero or even below zero once proof of stake is introduced: https://twitter.com/VitalikButerin/status/879858608091144193
Regarding the 'fixed amount of Bitcoins' argument, I'd agree it's a nice simple marketing message but if you look in to what Ethereum is planning to do, issuance could well go to close to zero, zero or even below zero once proof of stake is introduced: https://twitter.com/VitalikButerin/status/879858608091144193
At this point, people could convert from btc and use any random shitcoin for value transfer, then convert back to USD
> Then do the same with Ethereum.
As long as you only ask him to do it, it will be fine. What if everybody using bitcoin did it though?
As long as you only ask him to do it, it will be fine. What if everybody using bitcoin did it though?
As of a couple months ago, Ethereum was averaging 50% of Bitcoin's transaction volume[1]. On June 11, Ethereum did more transactions than Bitcoin[2]. It managed this even though many of Ethereum's transactions are much more complex than Bitcoin's simple value transfers. According to the devs, the current version will top out around 10 to 12 tx/sec; Bitcoin has been stuck at 3.
So I think it's safe to say that Ethereum could easily absorb Bitcoin's transaction volume, even without Ethereum's planned scalability upgrades.
[1] http://www.trustnodes.com/2017/05/17/ethereum-reaches-50-bit...
[2] http://cryptoeconomy.info/2017/06/12/day-ethereum-processed-...
So I think it's safe to say that Ethereum could easily absorb Bitcoin's transaction volume, even without Ethereum's planned scalability upgrades.
[1] http://www.trustnodes.com/2017/05/17/ethereum-reaches-50-bit...
[2] http://cryptoeconomy.info/2017/06/12/day-ethereum-processed-...
[deleted]
Ethereum is like Bitcoin but with scripts that can store data, hold money, and send it to other accounts.
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.
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.
> I wonder if somebody who finds a flaw in a smart contract can legally just jack all the coins
One way to interpret this legally is to assume that smart contracts are in fact enforceable legal contracts. (Most promises about exchanging stuff are enforceable legal contracts, so this is plausible.) The general first-year-contracts answer is then that it depends on the expressed intent of the parties.
Take two extreme examples:
(1) I put an ether bounty in a smart contract and say anyone who can exploit the contract can have it. Definitely legal to exploit (and I can be held to the promise).
(2) I hire you to review my smart contract for exploitable flaws, and instead you exploit the flaws. Definite breach of contract.
The real situation is neither of those, but you can see how expressed intent matters.
So the question is what's the actual expressed exchange of promises between the parties to a given smart contract? And here I think some of the code-is-contract statements around Etherium tilt things toward my (1) example - the text advertisements for the DAO have a bunch of stuff to set the expectation that whatever the code says, goes. But that would be up for debate in court.
(And then there's lots of non-contract ways to slice this, from computer fraud to gambling law to securities law to...)
One way to interpret this legally is to assume that smart contracts are in fact enforceable legal contracts. (Most promises about exchanging stuff are enforceable legal contracts, so this is plausible.) The general first-year-contracts answer is then that it depends on the expressed intent of the parties.
Take two extreme examples:
(1) I put an ether bounty in a smart contract and say anyone who can exploit the contract can have it. Definitely legal to exploit (and I can be held to the promise).
(2) I hire you to review my smart contract for exploitable flaws, and instead you exploit the flaws. Definite breach of contract.
The real situation is neither of those, but you can see how expressed intent matters.
So the question is what's the actual expressed exchange of promises between the parties to a given smart contract? And here I think some of the code-is-contract statements around Etherium tilt things toward my (1) example - the text advertisements for the DAO have a bunch of stuff to set the expectation that whatever the code says, goes. But that would be up for debate in court.
(And then there's lots of non-contract ways to slice this, from computer fraud to gambling law to securities law to...)
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.
I didn't have high expectations for Solidity considering the recent vulnerabilities, but even these were disappointed. If some guy writes this kind of code at home, alright, but this as the alleged foundation for our future financial system? Frightening.
Just one example: "Our function EndLottery() must be only accessible by the owner of the lottery." [0]
function EndLottery() public { if (msg.sender == owner) { ... } }
What about code guards? Not to speak of decent typing, etc. etc.
[0] https://ethereumdev.io/managing-multiple-users-a-simple-lott...
Just one example: "Our function EndLottery() must be only accessible by the owner of the lottery." [0]
function EndLottery() public { if (msg.sender == owner) { ... } }
What about code guards? Not to speak of decent typing, etc. etc.
[0] https://ethereumdev.io/managing-multiple-users-a-simple-lott...
I understand the eth VM is pretty limited and limiting, but Solidity is just sad, it's like somebody saw Javascript and thought "ok that's a pretty terrible basis for writing contracts, but surely we can make it even worse?"
And then they succeeded at failing.
And then they succeeded at failing.
Can't remember where I read it, but someone put it best during the DAO fiasco last year when they wrote "Imagine Javascript but your bank account accessible through the Document Object Model."
Even that's only scratching the surface of how awful Solidity is. An example of minor security detail straight from the documentation is this:
for(var i=0; i<arr.length; ++i) {
Many issues with Solidity as a contract language were pointed out in a previous HN thread after the Parity multisig-incident: https://news.ycombinator.com/item?id=14810008
I'll do you one better, vulnerabilities directly associated with the dynamism of Solidity were predicted on LtU in 2014:
http://lambda-the-ultimate.org/node/5003
http://lambda-the-ultimate.org/node/5003
Have you read next article? https://ethereumdev.io/better-readability-with-modifiers/
You are right, they solved the particular problem I highlighted with Modifiers.
But the main question remains: Why don't they utilize the progess we made in decades of research for better programming languages?
The argument that Solidity should be useable by the average programmer doesn't hold, in fact, typing makes programming easier since it clarifies data structures that are implicit in languages like JS.
But the main question remains: Why don't they utilize the progess we made in decades of research for better programming languages?
The argument that Solidity should be useable by the average programmer doesn't hold, in fact, typing makes programming easier since it clarifies data structures that are implicit in languages like JS.
PL people often direct their "it should be functional and use strong typing" critique at the EVM rather than Solidity. Solidity is just one HLL (higher level language) that compiles to EVM bytecode.
A lot of the limitations of Solidity are due to constraints of the EVM, but the EVM is evolving. For instance, the next planned hard fork will enable the EVM to pass dynamically sized data (e.g. solidity arrays or strings) between call stacks. Previously arrays had to be fixed-size, so you'd have to define a fixed maximum size, then always return data of that size (usually a lot of empty elements). This feature, like many others, is somewhat challenging to design because every execution step of the EVM must be metered by a "gas fee"; the first version of the EVM kept it simple by only allowing return data to be a fixed size. See these issues for background https://github.com/ethereum/solidity/issues/164 https://github.com/ethereum/EIPs/pull/211
Also, the longer-term proposal is to adopt WebAssembly for EVM 2.0: https://github.com/ewasm/design. Then users can write contract code using any language with an llvm compiler (rust, ocaml, etc.).
A lot of the limitations of Solidity are due to constraints of the EVM, but the EVM is evolving. For instance, the next planned hard fork will enable the EVM to pass dynamically sized data (e.g. solidity arrays or strings) between call stacks. Previously arrays had to be fixed-size, so you'd have to define a fixed maximum size, then always return data of that size (usually a lot of empty elements). This feature, like many others, is somewhat challenging to design because every execution step of the EVM must be metered by a "gas fee"; the first version of the EVM kept it simple by only allowing return data to be a fixed size. See these issues for background https://github.com/ethereum/solidity/issues/164 https://github.com/ethereum/EIPs/pull/211
Also, the longer-term proposal is to adopt WebAssembly for EVM 2.0: https://github.com/ewasm/design. Then users can write contract code using any language with an llvm compiler (rust, ocaml, etc.).
I agree about typing but unfortunately I'm not a core dev. The compiler does a good job at warnings thought...
Maybe it's because I don't have a use for it yet, or at least don't know if I have a use for it. But, the whole Ethereum universe seems vague and seems like they could explain it more than they do. "Install Ethereum wallet, write a contract, ..., Profit!" ?? Is there a better source that might explain what it is, how it works (a glancing explanation not a full network inner workings)??
The use-cases for smart contracts seem to be quite low, so I wonder if it really is worth the investment to learn to develop smart contracts. Additionally, even the smart contracts written by the experienced ethereum developers have contained bugs, resulting to losses of tens of millions worth of ethereum. To me it sounds like it is much smarter to use some pre-existing smart contract which is used by many, instead of making your own. However if you really have a new idea for smart contract then you could learn the language.
"To me it sounds like it is much smarter to use some pre-existing smart contract which is used by many, instead of making your own." This is exactly how the last "big hacking" had happened https://qz.com/1034321/ethereum-hack-a-coding-error-led-to-3...
But as you said writing your own is also error prone.
But as you said writing your own is also error prone.
How about taking some existing smart contract, and also reviewing it also carefully? If it is used already by lots of users, people have already trusted it with their money.
I'm pretty sure that developing your own has much, much higher risk than using some pre-existing solution.
I'm pretty sure that developing your own has much, much higher risk than using some pre-existing solution.
I Am Not An Expert.
If I understand correctly, these are a way to automate the execution of the financial part of normal contracts without the need for undue trust between parties. Some simple examples that might help (and I invite correction):
• I and a few investors agree to buy into an enterprise in several installments. A contract can be written to the blockchain that automates these payments. Should a majority of the investors decide to withdraw support, the payments will cease, but while more than 50% wish to continue support, everyone will continue.
• I have an enterprise that I am highly confident will generate profit. I can establish a smart contact that guarantees my investors a minimum ROI at specific intervals; should the balance fail to grow by the agreed margin, all investors will instead be refunded (in full or part) based on a scheme agreed a priori to be fair — say, a function of shares owned for how long.
• I and several other Ethereum miners agree to develop a scheme built on top of Ethereum for, say, a specific method of interoperability between the Ethereum blockchain and traditional futures markets. We have a specific idea for this, but agree we need to ensure that there is momentum in the project, and want those participating to have 'skin in the game'. We build a tontine such that all of us invest a non-trivial amount, and any investor becomes ineligible for payout if their hash power abandons the protocol. If this falls below a certain threshold, remaining investors can vote to continue or divide the pot and abandon the project.
If I understand correctly, these are a way to automate the execution of the financial part of normal contracts without the need for undue trust between parties. Some simple examples that might help (and I invite correction):
• I and a few investors agree to buy into an enterprise in several installments. A contract can be written to the blockchain that automates these payments. Should a majority of the investors decide to withdraw support, the payments will cease, but while more than 50% wish to continue support, everyone will continue.
• I have an enterprise that I am highly confident will generate profit. I can establish a smart contact that guarantees my investors a minimum ROI at specific intervals; should the balance fail to grow by the agreed margin, all investors will instead be refunded (in full or part) based on a scheme agreed a priori to be fair — say, a function of shares owned for how long.
• I and several other Ethereum miners agree to develop a scheme built on top of Ethereum for, say, a specific method of interoperability between the Ethereum blockchain and traditional futures markets. We have a specific idea for this, but agree we need to ensure that there is momentum in the project, and want those participating to have 'skin in the game'. We build a tontine such that all of us invest a non-trivial amount, and any investor becomes ineligible for payout if their hash power abandons the protocol. If this falls below a certain threshold, remaining investors can vote to continue or divide the pot and abandon the project.
The problem with your first two examples is that the 'investment' locked up in the smart contract can't be spent, which means the investors are not bearing any risk, and therefore cannot enjoy a return. If the money could be spent on capital and operating expenses, then the smart contract wouldn't be able to refund it if the conditions of the investment failed.
It is possible to create a smart contract, like the DAO, which implements the rules of a joint stock company. But stockholders are not concerned about the risk that these rules will be broken. The risk is that the company fails and there is nothing to distribute according to the rules. Replacing the general meeting of stockholders with a smart contract doesn't change the economics of collective investment – it just adds the risk of losing everything to a bug in the contract.
It is possible to create a smart contract, like the DAO, which implements the rules of a joint stock company. But stockholders are not concerned about the risk that these rules will be broken. The risk is that the company fails and there is nothing to distribute according to the rules. Replacing the general meeting of stockholders with a smart contract doesn't change the economics of collective investment – it just adds the risk of losing everything to a bug in the contract.
without the need for undue trust between parties
Uses case are infinite..
You could also for example write transparent casinos system, transparent marketplace where every transactions would be certified by both parts, a banking system, some new money, ect..
Yeah people. Explain Ethereum without using the words "smart contract" please.
Ethereum is a cloud computing service. It has two advantages over other cloud computing services:
(1) it is extremely highly available
(2) the person who uploads a program cannot modify that program afterwards and has no special admin access over that program's data storage; furthermore all data stored including program code is publicly viewable.
Because the program author has no admin privileges, users don't have to worry about the service provider abusing their admin privilages to secretly modify the database (which may otherwise be a concern for high-value applications such as, e.g. vote-counting, e.g. a database that stores bank account balances, etc).
The disadvantages are (1) it is much more expensive compared to other cloud computing services, (2) since the uploader doesn't have admin access, they can't fix bugs, and since everything is transparent, it's hard to store secrets.
Because the program author has no admin privileges, users don't have to worry about the service provider abusing their admin privilages to secretly modify the database (which may otherwise be a concern for high-value applications such as, e.g. vote-counting, e.g. a database that stores bank account balances, etc).
The disadvantages are (1) it is much more expensive compared to other cloud computing services, (2) since the uploader doesn't have admin access, they can't fix bugs, and since everything is transparent, it's hard to store secrets.
It takes some time to wrap your head around the blockchain, first you have to understand Bitcoin , then you will have no issues understanding Ethereum. But I tell you one thing, once you understand it, you will not stop thinking about it.
https://www.youtube.com/watch?v=3RN8bnNe-Is
https://www.youtube.com/watch?v=3RN8bnNe-Is
Healthy young child discovers Ethereum, gets pumped with massive shot of many tokens, feels good and changes - AUTISM. Many such cases!
I dream about blockchains. Yeah it's true, not only the technology is interesting but also the community and all the ecosystem behind cryptocurrencies.
Does this not seem like the kind of area where you don't want people writing hacky, proof of concept code?
The idea of people coding up weekend projects on Ethereum, putting them behind flashy websites and encouraging large scale adoption terrifies me, to be honest.
The idea of people coding up weekend projects on Ethereum, putting them behind flashy websites and encouraging large scale adoption terrifies me, to be honest.
As the technology evolves you need more and more people fluent. Most people will never write live code involving million of dollars but it might help people understanding the techno and the code behind...
This is an introduction and as more and more article will be written the learners will be more skilled and aware of security and good practices
Just wait until artificial intelligence does it for us...
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 the traditional legal system) becoming recognized for their robustness and used for common operations.
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 the traditional legal system) becoming recognized for their robustness and used for common operations.
Legal contracts have a solution for bugs and loopholes, namely, the court system. I can write a three-line contract with the core terms on a napkin, sign it, and it will be okay, since everything not explicitly mentioned will be given reasonable defaults, and attempts to exploit stupid loopholes will be laughed out of the court. If someone defrauds me and gets me to sign a contract based on false information, they don't get to point to a loophole and figuratively take my firstborn, we have a process to void fraudulent contracts.
However, if you want contracts that cannot be overridden and are enforced by machines as written (not as intended, as in the legal system), then the bar becomes much higher, then you must get all the details explicitly right the first time and ensure that people don't sign fraudulent contracts, and I'm not sure if this is possible at all.
However, if you want contracts that cannot be overridden and are enforced by machines as written (not as intended, as in the legal system), then the bar becomes much higher, then you must get all the details explicitly right the first time and ensure that people don't sign fraudulent contracts, and I'm not sure if this is possible at all.
I think I'm going to end up pasting this link in all discussions surrounding Ethereum: https://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law
>When one obeys the letter of the law but not the spirit, one is obeying the literal interpretation of the words (the "letter") of the law, but not necessarily the intent of those who wrote the law. Conversely, when one obeys the spirit of the law but not the letter, one is doing what the authors of the law intended, though not necessarily adhering to the literal wording.
This is a very ancient concept and like all ancient concepts it's bound to be rediscovered every other decade on average.
"The code is law" is a wet dream for a dystopic authoritarian state and I don't understand why anybody, much less actual coders, would think that's a good idea.
"Thank you for subscribing to our contract for your $2 weekly subscription. By the way through a clever loophole obfuscated in our code the amount actually doubles every week. Freedom is Slavery, Ignorance is Strength, Code is Law. Have a good day sir".
In the real world you have a safety net for these types of things, in many case you can break an abusive contract because society has created regulations that ban certain tactics. Ethereum has no such thing. A single mistake or intentional deception and like that, you've lost all your money. The code is law, nothing we can do sir. How is that a feature exactly?
Look at how dumb the average spam is, and yet there's no shortage of people falling for them. Yet it seems like the ethereum crowd genuinely believes that my mother is suddenly going to be able to proof Solidity scripts, something I wouldn't even trust myself to do with decades of programming experience behind me. I don't know if Ethereum is an economic bubble but it definitely is an intellectual one.
>When one obeys the letter of the law but not the spirit, one is obeying the literal interpretation of the words (the "letter") of the law, but not necessarily the intent of those who wrote the law. Conversely, when one obeys the spirit of the law but not the letter, one is doing what the authors of the law intended, though not necessarily adhering to the literal wording.
This is a very ancient concept and like all ancient concepts it's bound to be rediscovered every other decade on average.
"The code is law" is a wet dream for a dystopic authoritarian state and I don't understand why anybody, much less actual coders, would think that's a good idea.
"Thank you for subscribing to our contract for your $2 weekly subscription. By the way through a clever loophole obfuscated in our code the amount actually doubles every week. Freedom is Slavery, Ignorance is Strength, Code is Law. Have a good day sir".
In the real world you have a safety net for these types of things, in many case you can break an abusive contract because society has created regulations that ban certain tactics. Ethereum has no such thing. A single mistake or intentional deception and like that, you've lost all your money. The code is law, nothing we can do sir. How is that a feature exactly?
Look at how dumb the average spam is, and yet there's no shortage of people falling for them. Yet it seems like the ethereum crowd genuinely believes that my mother is suddenly going to be able to proof Solidity scripts, something I wouldn't even trust myself to do with decades of programming experience behind me. I don't know if Ethereum is an economic bubble but it definitely is an intellectual one.
> "The code is law" is a wet dream for a dystopic authoritarian state and I don't understand why anybody, much less actual coders, would think that's a good idea.
How is that dystopic and authoritarian? Looks like you're throwing a bunch of buzz words for shock value with little argument to back it up. We already trust code as contract everyday every time you make a payment through SSL (anyone who lived through the 90's and early 2000's remembers how people were scared to death of online payment security and now it happens every millisecond). Ethereum is just a distributed version of that with no middle man, that is to say it can fail like SSL can when compromised but it doesn't mean we should throw it out the window just because it could sometimes fail. By that logic we should still be cavemen and forget about any technology ever.
> "Thank you for subscribing to our contract for your $2 weekly subscription. By the way through a clever loophole obfuscated in our code the amount actually doubles every week. "
I hope you're aware that the exact same thing happened with these indexed loans where people weren't aware that interests could fluctuate with time, right?
How is that dystopic and authoritarian? Looks like you're throwing a bunch of buzz words for shock value with little argument to back it up. We already trust code as contract everyday every time you make a payment through SSL (anyone who lived through the 90's and early 2000's remembers how people were scared to death of online payment security and now it happens every millisecond). Ethereum is just a distributed version of that with no middle man, that is to say it can fail like SSL can when compromised but it doesn't mean we should throw it out the window just because it could sometimes fail. By that logic we should still be cavemen and forget about any technology ever.
> "Thank you for subscribing to our contract for your $2 weekly subscription. By the way through a clever loophole obfuscated in our code the amount actually doubles every week. "
I hope you're aware that the exact same thing happened with these indexed loans where people weren't aware that interests could fluctuate with time, right?
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. It's just a mean to secure a transaction and that's it. There's no contract involved. It's a tunnel for some data. A more apt comparison would be to say that I trust, say, Amazon's website to do the right thing when I give them my credit card infos. But the truth is that I don't even trust them that much, if they abuse it or get compromised I'll just notify my bank (if they don't notice it before I do) and I'm good to go.
If I buy a laptop on amazon and they sneakily bill me for two tons of whole grain rice flour and when I complain they said "but it was in the terms and conditions", do you think it would hold up in court?
>I hope you're aware that the exact same thing happened with these indexed loans where people weren't aware that interests could fluctuate with time, right?
Ah, and it's clearly something we aim to emulate, right?
If anything that's a very good example about how the average person can be tricked into accepting a terrible contract if they don't know any better. Do you think it would've worked better if the loan was expressed in Solidity code?
SSL is hardly related. It's just a mean to secure a transaction and that's it. There's no contract involved. It's a tunnel for some data. A more apt comparison would be to say that I trust, say, Amazon's website to do the right thing when I give them my credit card infos. But the truth is that I don't even trust them that much, if they abuse it or get compromised I'll just notify my bank (if they don't notice it before I do) and I'm good to go.
If I buy a laptop on amazon and they sneakily bill me for two tons of whole grain rice flour and when I complain they said "but it was in the terms and conditions", do you think it would hold up in court?
>I hope you're aware that the exact same thing happened with these indexed loans where people weren't aware that interests could fluctuate with time, right?
Ah, and it's clearly something we aim to emulate, right?
If anything that's a very good example about how the average person can be tricked into accepting a terrible contract if they don't know any better. Do you think it would've worked better if the loan was expressed in Solidity code?
> 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 code on the server hosting the SSL cert and authority server. So, it's just code involved here.
> If I buy a laptop on amazon and they sneakily bill me for two tons of whole grain rice flour and when I complain they said "but it was in the terms and conditions", do you think it would hold up in court
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.
> Ah, and it's clearly something we aim to emulate, right?
No it is not, my point is that bad things happen no matter who's involved (humans or code) and just because some bad things may happen doesn't mean we should stop using it, but we should go with the most efficient and secure one, which for now is probably humans of course. See also plane crashes.
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 code on the server hosting the SSL cert and authority server. So, it's just code involved here.
> If I buy a laptop on amazon and they sneakily bill me for two tons of whole grain rice flour and when I complain they said "but it was in the terms and conditions", do you think it would hold up in court
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.
> Ah, and it's clearly something we aim to emulate, right?
No it is not, my point is that bad things happen no matter who's involved (humans or code) and just because some bad things may happen doesn't mean we should stop using it, but we should go with the most efficient and secure one, which for now is probably humans of course. See also plane crashes.
>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?
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?
> 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).
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).
One could argue that legal contracts are less binding than smart contracts. There is a distinction made between the 'letter and spirit of the law'.
Furthermore, a contract, or at least a clause, will become invalid if it goes against existing law in a country (at least this applies to the EU). E.g, I cannot sign a contract in which I sell my kidney to you, as commercial organ trading is outlawed in many countries.
Is a smart contract able to make this distinction? I suppose as soon as it develops a moral consciousness it does.
Furthermore, a contract, or at least a clause, will become invalid if it goes against existing law in a country (at least this applies to the EU). E.g, I cannot sign a contract in which I sell my kidney to you, as commercial organ trading is outlawed in many countries.
Is a smart contract able to make this distinction? I suppose as soon as it develops a moral consciousness it does.
Most "real life" contracts have bugs too. The difference is: the visibility of these contracts is very limited such that these bugs cannot be exploited by random hackers. And any exploit can be challenged in court. Ethereum takes away both - opening you up to be challenge by everybody with no recourse.
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.
> That world does not exist yet
With a big emphasis on "yet". Serious question: are the "halting problem" and the "yet" in your sentence dependent on each other? I.e., don't we need to first solve the halting problem before we can manage to write 100% bug-free programs?
With a big emphasis on "yet". Serious question: are the "halting problem" and the "yet" in your sentence dependent on each other? I.e., don't we need to first solve the halting problem before we can manage to write 100% bug-free programs?
There is no need to solve halting problem in general case. We can have heuristics that do not accept programs they are not sure about and it is programmer's job to make correctness more obvious.
My understanding is that the halting problem does not prevent formal proofs of Ethereum contract correctness because Ethereum contracts have gas limits that make them terminating.
And the entire concept of 'gas' to me seems to be a hacky work-around in order to implement a Turing-Complete language on the blockchain.
I'm not even sure it is needed -- the whole 'Turing-Complete' aspect of the EVM seems to be an engineering solution in search of a problem. And 'gas' is certainly not intuitive as a metaphor for end-users of Ethereum who would use it as a currency (how does a financial transaction "run out of gas", exactly?)
I'm not even sure it is needed -- the whole 'Turing-Complete' aspect of the EVM seems to be an engineering solution in search of a problem. And 'gas' is certainly not intuitive as a metaphor for end-users of Ethereum who would use it as a currency (how does a financial transaction "run out of gas", exactly?)
Gas is analogous to cycles of the EVM that the contracts uses when it executes. Someone suggested 'gas' should have been called 'cycles' to more clearly convey its meaning and avoid a lot of confusion. Anyway, gas/cycles must be limited given there are no access controls on use of the EVM. It's an effective DoS control. It's also orthogonal to Turing Completeness.
I don't see how you can "solve" the halting problem. But there are lots of ways to tiptoe around it and have some kind of formal verification of software.
We put our lives in the hands of code written by humans every day, e.g. cars, planes, trains, etc.
Perhaps the permanence of executing solidity contracts will at least motivate some safer, more secure practises, in the same way that the permanence of death does when programming vehicles that carry human lives.
It would be cool to see APIs for compiling Solidity contracts from safer languages with more concise type systems like Idris[1]. That said, I haven't had a proper dig into Solidity myself yet so it could very well offer some of these features. I'd love to hear some experiences from devs who have written a significant amount of code in it.
[1]: https://www.idris-lang.org/
Perhaps the permanence of executing solidity contracts will at least motivate some safer, more secure practises, in the same way that the permanence of death does when programming vehicles that carry human lives.
It would be cool to see APIs for compiling Solidity contracts from safer languages with more concise type systems like Idris[1]. That said, I haven't had a proper dig into Solidity myself yet so it could very well offer some of these features. I'd love to hear some experiences from devs who have written a significant amount of code in it.
[1]: https://www.idris-lang.org/
> We put our lives in the hands of code written by humans every day, e.g. cars, planes, trains, etc.
Except that code is regulated and tested to the degree average eth enthusiast making this point either not aware of, or intentionally omits.
Except that code is regulated and tested to the degree average eth enthusiast making this point either not aware of, or intentionally omits.
Not only is it regulated and tested, the question of liability is easy to answer: Product Liability is regulated by countless national and international laws.
But in the case of Ethereum Smart Contracts, who is liable in the real world?
But in the case of Ethereum Smart Contracts, who is liable in the real world?
That's why you need to get a good education and accessible education on the subject...
You might appreciate https://news.ycombinator.com/item?id=14835977#14839943
It's possible to write provably correct code, though. At least then you reduce the problem to the issue of correctly specifying what the code is supposed to do. Certain classes of contracts might be small enough to do that.
Granted, the requirement for NASA-level code correctness would make smart contracts expensive to develop and put them out of reach of average developers.
Granted, the requirement for NASA-level code correctness would make smart contracts expensive to develop and put them out of reach of average developers.
> issue of correctly specifying what the code is supposed to do.
also the intent of the programmer, right?
also the intent of the programmer, right?
They might still be a good idea, you just have to live with that risk. World is full of risks anyway and you might die tomorrow in a traffic accident. Sometimes risks are worth taking, such as leaving your apartment and risk walking under a car.
Not that I have mathematical proof, but I'd be happy to bet that the chance of buggy code being written is higher than the risks you outlined above :)
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 experience shows, even security oriented code carefully made and reviewed by experts tends to have bugs, but it is possible (though not as likely) that a small piece of carefully audited code will be bug-free. That's a bit different than the risk of getting hit by a car; it might be more fair to say that you have a "risk" of being bug-free comparable to the "risk" of winning a lottery.
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 experience shows, even security oriented code carefully made and reviewed by experts tends to have bugs, but it is possible (though not as likely) that a small piece of carefully audited code will be bug-free. That's a bit different than the risk of getting hit by a car; it might be more fair to say that you have a "risk" of being bug-free comparable to the "risk" of winning a lottery.
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.
If smart contracts are at all useful, they most definitely will be useful before we have near-perfect code writing AI's.
It is possible that with sufficient investment in tools for writing safer code, unoverridable smart contracts will become useful enough to outweigh the risks.
It's also possible (and I feel that this will be the case) that in the end the risks will be too large anyway for large adoption, so we'll collectively decide that for most use cases smart contracts are useful only with a "social" mechanism for overriding them, contrary to the current "code is law" policy of Ethereum.
It's also possible (and I feel that this will be the case) that in the end the risks will be too large anyway for large adoption, so we'll collectively decide that for most use cases smart contracts are useful only with a "social" mechanism for overriding them, contrary to the current "code is law" policy of Ethereum.
Give all your money to me, and I'll return it million fold in a year. I know it's risky, but you can die tomorrow in an accident anyways, so why not.
Before you write a comment with "why not", apply that to eth first.
Before you write a comment with "why not", apply that to eth first.
The problem with crypto coins is some have bought in and thus are vested making balanced discussion impossible. We see even with something as trivial as choice of programming language some can become very religious in their support. When money becomes involved expecting rational discussion is perhaps naive.
Money is a social construct that needs societal consent and a framework to manage it that is accountable to the societies rules and regulations. So a random person can't just create money or value out of thin air. There is no value being created here.
They can make a private coin, and convince others to use it between themselves, there were and still exist many such private arrangements in traditional economies, but the value only exists for those who choose to trust this system, and can never hope to replace the main economic currency.
Bitcoin and other coins exists in this space of a private coin based on mutual trust and of no real value to the main economy. Holders of such coins would of course love for it to become a real currency and continue making outlandishly self serving arguments about the economy so they can gain something out of nothing. But that begins to resemble a pyramid scheme powered exclusively by greed and self interest to the exclusion of that society's interests.
Money is a social construct that needs societal consent and a framework to manage it that is accountable to the societies rules and regulations. So a random person can't just create money or value out of thin air. There is no value being created here.
They can make a private coin, and convince others to use it between themselves, there were and still exist many such private arrangements in traditional economies, but the value only exists for those who choose to trust this system, and can never hope to replace the main economic currency.
Bitcoin and other coins exists in this space of a private coin based on mutual trust and of no real value to the main economy. Holders of such coins would of course love for it to become a real currency and continue making outlandishly self serving arguments about the economy so they can gain something out of nothing. But that begins to resemble a pyramid scheme powered exclusively by greed and self interest to the exclusion of that society's interests.
Not only is it a social construct, but the concept of money took thousands of years to evolve, with fits and starts, to what it is today. No matter what, some new technology isn't going to just show up all of a sudden and completely revolutionize what is an intrinsic component of human civilization. To think otherwise is to be taken in by scammers.
I know that current money systems have flaws and are manipulated by the elites. Crypto won't end up being any different in that regard, however. Inflation is a tactic utilized within the current flawed system to move wealth to the top without your bank balance displaying the change. Cryptos will end up having their own flaws to be exploited.
I know that current money systems have flaws and are manipulated by the elites. Crypto won't end up being any different in that regard, however. Inflation is a tactic utilized within the current flawed system to move wealth to the top without your bank balance displaying the change. Cryptos will end up having their own flaws to be exploited.
I think you're underestimating the impact of a durable and formal consensus mechanism that can be run by machines and can operate efficiently at a global scale by utilising telecommunication networks. This is orders of magnitude more efficient than traditional governing structures and will displace several core industries over the next few decades in my opinion.
I agree with this view.
I know this might sound like a joke, but it is not: how about documenting how to actually test and debug smart contracts? Is there even a way to do so? How about fuzzying?
The best tool for debugging is http://remix.ethereum.org/. It lets you step through the compiled EVM bytecode, while highlighting the solidity source mapping.
They are frameworks for supporting development with testing (not covered it yet) for example http://truffleframework.com/
[deleted]
Am I misreading the code? Isn't the EndLottery function completely broken? It looks like it finds the first user who bet less than the winning number. So, in order to win you should play ASAP and bet epsilon > 0, right?.
yeah, it's completely broken. which normally you would fix, but oh look too late!
Thanks for your comment and it's fixed thanks to a hard fork ;)
right on, the tutorial was interesting (even for someone with little interest in all things blockchain :)
Here is a cool application - https://predictiontoken.github.io/#TRMP. It lets people bet on outcomes and bets be settled in a decentralized manner. There is a video in the link if you want to understand how it is accomplished.
Are you familiar with Assassination Politics?
I think we need an Etudes for Ethereum contract development and best practices; there are like 4 different "make a smart contract that juggles millions of assets on the shutter" tokens and sites, but few that focus on security and how to vigorously remind people that mistakes are worth millions of dollars
Is there any other crypto platform allow to write dApps for blockchain?
RSK [0] is already in beta and EOS [1] will launch a dev testnet in Q3-Q4 IIRC. RSK uses the ethereum VM so the smart contracts and dApps will be compatible/portable.
[0] http://www.rsk.co/
[1] https://eos.io/
[0] http://www.rsk.co/
[1] https://eos.io/
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.
EOS is the likely successor in my opinion.
(eos.io)
In development now, but a development environment will be up and running by the end of the summer; testnet coming in the fall. Full release next summer.
(eos.io)
In development now, but a development environment will be up and running by the end of the summer; testnet coming in the fall. Full release next summer.
Yeah sure, check this version of the lottery https://github.com/renasboy/ETHLottery
They talk about storing money in the contract.
Does this mean I will be "charged" right in the moment I "store" money in the contract?
Or does it mean I'll be charged when the contract gets "destroyed" and the money "in the contract" is sent to some address?
I'm asking because both sides have problems.
If I don't get charged when storing money in the cotract, I could spend it elsewhere until the contract resolves.
If I get charged when storing money, someone could write contracts that never resolve to purge money.
Does this mean I will be "charged" right in the moment I "store" money in the contract?
Or does it mean I'll be charged when the contract gets "destroyed" and the money "in the contract" is sent to some address?
I'm asking because both sides have problems.
If I don't get charged when storing money in the cotract, I could spend it elsewhere until the contract resolves.
If I get charged when storing money, someone could write contracts that never resolve to purge money.
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 destroyed by stupidity.
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 destroyed by stupidity.
I see, thank you :)
Stupidity? Doesn't Ethereum want to prevent all money getting locked up somewhere?
Stupidity? Doesn't Ethereum want to prevent all money getting locked up somewhere?
I believe there are times when it is favorable to "burn" ether or another cryptocurrency, i.e. lock up the money in an unowned account. For example, the decentralized market place OpenBazaar discusses proof-of-burn to establish a user's reputation (https://blog.openbazaar.org/proof-of-burn-and-reputation-ple...). Burning coins allows a user to show they are invested in their reputation on the platform, without being forced to pay money to a central party.
Just as much as people want to solve the halting problem.
I took a glance at the lottery example [1] and I wonder: isn't the owner of the lottery able to change the outcome so the winningNumber is always in his favor?
[1]: https://ethereumdev.io/managing-multiple-users-a-simple-lott...
[1]: https://ethereumdev.io/managing-multiple-users-a-simple-lott...
the lottery code is so broken it isn't even funny. actually it is hilarious! the first bet will almost always win, especially if it's a very small bet!
Yes, but the author does point to [1] for a better way of generating randomness for such a contract using commitments.
[1]: https://ethereum.stackexchange.com/questions/191/how-can-i-s...
[1]: https://ethereum.stackexchange.com/questions/191/how-can-i-s...
Could you explain more how would it be possible?
In the example code used, the random number which determines the winner is derived from the previous block hash. Since the lottery-owner determines when the function is run, they could call the function when the previous block hash favors their own bet, or else modify their bet before calling the function.
Yep that is why there is a notice and link about random number generation in the tutorial.
try this lottery code instead https://github.com/renasboy/ETHLottery
Is it correct that the betted value doesn't influence any winning chances?
Also, is the last byte of the blockhash function return value guaranteed to be equidistributed?
Also, is the last byte of the blockhash function return value guaranteed to be equidistributed?
Please, enough with the JavaScript already; there are thousands of saner means of expression already existing or waiting to be discovered. Writing flawless, verifiable contracts is the worst use-case ever for that stinking pile of a language. I wonder how many missing bazillions it's going to take for the world to wake up and move on.
There needs to be a separation of the underlying technological fundamentals of ETH and its economic reality -- which is, like anything else, likely to go through bubble phases.
Pretty much sums up the state of Ethereum/Solidity development right now;
Step 1, install wallet. Step 2, deploy contract. Step 3, learn about Solidity. ... Testing? Nah.
Step 1, install wallet. Step 2, deploy contract. Step 3, learn about Solidity. ... Testing? Nah.
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 | * }.
Person A: Cryptocurrency X is insecure isn't it.
Person B: So is { the dollar | driving | flying | the internet | * }.
We've seen it happen again (DAO) and again (Parity) and it will keep happening, because it's broken by design. 90s cypherpunks that pioneered this ideas had considered Turing complete design and discarded it for cryptographic state-machines that allow for formal verification.
I appreciate the experimentation, but the takeover-the-world echo-chambers of ethereum that don't focus at all on the real tech behind it and ignore everything negative is pretty disappointing. Especially because we keep getting new people buying this and becoming the greater fools.
When talking about engineering on such a critical subject, people should be way more responsible. If Bitcoin had the same attitude regarding security like Ethereum does, we wouldn't be here and cryptocurrencies would be a joke.
Lazy engineering comes at great cost as time goes by and the illusion of security is unveiled.