I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them call a withdraw function.)
Is there any form of auditing that contracts can go through to not have these pitfalls?
I wonder how many of them are still undiscovered...
People are realizing that this needs to be developed like safety-critical software, not like fast-moving startup websites. But I would say it's not as scary as, say, developing software for aerospace or medical applications.
And what really helps is that you can do a lot with very little code. I think all of my contracts are under five pages. I don't think we're ready for big complicated contracts, but there's a lot we can do with simple little contracts.
Yup. I find it interesting how everyone only thinks it's these couple of issues. I wouldn't do anything beyond experiments with it at this point.
Even though the coding experience seems pretty poor, it doesn't appear to be particularly dangerous as bad contracts can just be rolled back.
Actually, it's a bit more nuanced than that. If you have methods that make external calls--even if it's the last thing they do--you still have to ensure that all your externally-callable methods do not share state with the methods that make external calls. Restricting where and how often you do your external calls isn't sufficient, since that last external call at the end of your method can turn around and call other methods in your contract (which can alter the contract's state, if you're not careful).
EDIT: clarification
if (_recipient.call.value(_amount)()) { // vulnerable
Etherium's "Solidity" suffers from the desire to have it be a general-purpose computer. It should have been if-then rules, or a logic tree, or a decision logic table - a finite representation of business logic subject to exhaustive case analysis. Contract executions should have been atomic transactions - either everything commits, or everything gets rolled back. Stack overflow and running-out-of-gas terminations are inherently trouble.
Etherium needs to go back into the shop for a redesign. At least we found out early that this isn't going to work.
Whereas the cryptocurrency space is a startup environment: there's huge pressure to launch first so that you can get the money that people are begging to throw into untested speculative finance systems. And the refusal to countenance human control or any of the normal forms of accountability - these things are designed out of the system deliberately - means that there's going to be a long, slow, expensive period of designing them back in.
I got a good chuckle out of that one.
$US150M later isn't early
No it doesn't, no it's not. It affects contracts that use this functionality with arbitrary untrusted contracts (which is a bad idea), and most contracts just don't use this functionality at all.
It's an issue with Solidity because it doesn't even do static analysis to give the programmar a warning.
It's not that programmers actively avoid doing this or are explicitly warned to not do it. When real money is at stake the language design needs to be a lot more careful.
Even if you wrote all the contracts that are interacting like this yourself, this is an immense source for bugs. As anyone with some experience in concurrent programming or OOP can tell you.
Communication between contracts should have been defined and done via channels.
When I discovered ethereum a couple of years ago I thought it was a good idea. Partly because I was turning similar ideas in my head at the time.
But what I read now sounds like amateurs designed & implemented it. Sorry.
The answer to this is that mutation needs to be kept under control. Immutable data structures in mutable buckets. Locking around the data that mustn't change. Deep copy all state before calling out. And so forth.
This is basically an understood problem and I'm a bit appalled that Ethereum didn't build protection against it into their design.
One easy solution is to have just one external call per method, and always put it at the end of the method. Another is to use a single mutex for all public functions of the contract, so any callbacks fail.
Well, all of Ethereum smart contracts which are written in Solidity and which use a "call construct" in a certain way.
Even something as trivial as betting on sports requires deference to a trusted authority to say "this team won". What advantages does an ethereum smart contract provide over, say, some kind of trusted bitcoin escrow site?
I don't know anything about Ethereum, but if functions rely on external shared state then they aren't pure functions, are they?
On a pedantic level, you're absolutely correct, but real-world usage generally makes 'function' equivalent to 'subroutine', hence why we have the specific term pure function to disambiguate.
Moreover, there is a staggering amount of precedence for using "function" without implying purity, so even if Solidity did call them functions, that would be entirely normal terminology.
And, well, the entire point of invoking a contract is to effect some change to the state of the blockchain, so it would be strange to expect that Solidity methods were pure functions.
You are talking about referential transparency. Even functions that are not pure can be referentially transparent.
As for the question you actually asked, how did I? Emoji keyboard from iOS 10b1 on an iPhone 6s Plus in Safari.
Calling a callback at the end of a method avoids interfering with the caller's state but ignores the state of the caller's caller.
An ethereum contract will only be tractably analyzable if it avoids dynamically invoking arbitrary callbacks.
Pretty much this: http://www.thespanner.co.uk/2011/05/30/json-hijacking/
There's an optimization problem not yet sorted out here. If I were king of ethereum, (happily I'm not), I'd make a very cheap mutex support part of the eth vm and encourage solidity and serpent devs to use it as needed.
These really are solved problems.
The more I read about ethereum's technical details, the more it sounds like a joke to me.
But if you're setting up a situation where server after server is constantly compromised because of hard to discern reasons, then yes, that is a bad idea. Having an internet is something as obviously good as electrical wiring and highway bridges. Having a badly implemented internet is as obviously bad as faulty wiring and badly engineered highway bridges.
This stuff is making Ethereum sound like it was written by people as unqualified to make such a system as a dev who would use eval in nodejs code on a user supplied string is to implement an ecommerce site.
Letting programs call arbitrary function on each other is a fundamental design-flaw in every concurrent system.
Gotta love unexplained acronyms!
We also merged the comments from https://news.ycombinator.com/item?id=11934472 here, since there weren't that many of them and they were about the same post.
The original article discussed a bunch of other things as well -- everyone should read it to understand the details.
"Who are these people[1] and what credentials do they have to build and run a cryptocurrency platform?" [1] https://angel.co/ethereum-1
Today, not a single cryptographer, mathematician, or anyone with software security experience is listed on the Ethereum Foundation member list[2]. I am not attacking any individuals by themselves, but as a group this says a lot.
For the record, what I see listed online today is a: consultant, magazine founder, a programmer, and a lawyer. On the advisory board a sales person, a psychologist, a leveraged debt consultant. On the "special advisors" list, which I have no idea what this means, maybe someone who answered a phone call a few times, one person with a bunch of business credentials, something "fintech" related with little explanation, and a tech CEO.
Maybe the Ethereum Foundation doesn't need anyone with deep experience in cryptography and security?
It is theoretically possible to call out to another contract that has the ability to make further calls safely... but how can you be sure you've done it safely?
This isn't a unique problem. It arises in imperative-based programming all the time. But what in Javascript may be a bit of a coding error that means the next page of search results didn't load this time, in Solidity it means you may lose your shirt.
Also, I'd suggest that after-the-fact "static analysis" tools don't help. It's basically the same situation that real-world computer security is in, and right now, that world is massively advantage attacker, with generally far less direct incentive to attack than a blockchain functioning directly as money does. If the static analysis tool is open enough for "everyone" to use, the attackers get to use it too, and they can use it on all contracts at once because they're all open, and they have all the motivation to do so before the proper contract owners have time to fix their contracts. Every time the static analysis tools release a new check, it's an advantage-attacker race between exploiting the new check and fixing the contracts. The attackers are going to win big, repeatedly.
A Turing-complete blockchain needs to come out of the gate nearly 100% correct on this front, just as it needs to come out of the gate nearly 100% correct on the encryption security.
If what you say is true then Ethereum is DOA, which seems unlikely to me. (I don't own any ETH.) I totally agree that it would be great to have more language based security and I've started dabbling with some stuff myself (playing with verified byte code compilation in Agda) but my basic attitude is that worse is better, these hacks are unfortunate but educational, and now we're going to see way more care in contract construction and let's hope it works out.
It might be that Solidity is going to be replaced, and it's super interesting what will come. A bunch of people are insisting that some variant of functional programming with types is necessary for correct contracts but I'm skeptical until I see an actual proposal...
For those contracts that do, at least you're reducing the third-party trust to "provide accurate data" instead of "hold my funds without stealing them." To reduce trust in a single entity you can use various schemes that allow multiple independent parties to provide the data.
Can you go into more details about this?
> blind auctions
Or this? How does the contract ensure that the winner of the auction receives what they have purchased?
> crowdfunding
In what respects beyond simply collecting funds? How does the contract judge that the terms of the funding are adhered to or ensure that the crowdfunders receive whatever it is they are entitled to as funders?
> person-to-person gambling
Any examples? In my post I gave the example of betting on a sports game but this requires a trusted 3rd party to officiate the outcome of the game.
> currencies, exchanges
These are vague descriptions and these things have already been done by bitcoin.
I'm not trying to nitpick, but I'm looking for specific practical examples that demonstrates the potential utility of ethereum.
- a multisignature wallet, that requires more than one person to sign off on a transaction before it can happen.
- payment schedules or any kind of transaction that does not function exactly like a one time, full size payment (payments, debt, etc).
- more ambitious ideas, like the Slock.it ones, involve smart locks that hold funds while granting use to a resource, and only return them after access has been revoked
In all of the above the inputs are contained in the blockchain and therefore have no need for trusted oracles.
This is possible with bitcoin isn't it? What does the added complexity of ethereum bring to the table?
> payment schedules or any kind of transaction that does not function exactly like a one time, full size payment
This also seems possible with bitcoin, but it's also a problem that has already been solved better by the traditional payment system (e.g. netflix debits my credit card every month, why would I use a cryptocurrency solution instead?)
> more ambitious ideas, like the Slock.it ones, involve smart locks that hold funds while granting use to a resource, and only return them after access has been revoked
Can you go into specifics here? I'm not really understanding. It sounds like you're describing a kind of autonomous collateral system, but I can't really think of any practical examples where this would be useful (without bringing human judgement into the mix).
Yes, its not 100% trustless, but its far more trustless than the alternative.
It's usually used as a common term ("I'm creating a DAO"), but these guys called theirs "The DAO". This attacker exploited "The DAO".
Given that, I would even say that the name "Decentralized Autonomous Organization" is a deliberate, almost satirical, obfuscation.
But new efforts like this won't call themselves "a DAO" anymore than a new airship would be called "a hindenburg".
Imagine a publicly owned company. It has a CEO, COO, CFO, board, and shareholders. Most decisions are made by the chief officers of the company, and these officers are kept in check by the board of directors. Some shareholders can vote on certain decisions as well if they have the right kind of stock, but for the most part, consensus isn't really needed for most decisions. Day to day operations are handled by the COO, finances are handled by the CFO, and the CEO sort of steers the company as a whole. Most of the time, the board is hand picked to make sure that this centralization of power remains intact. In most companies, shareholders exist primarily to cash in on their own stake in the company either through dividends or by eventually selling their stock. They don't really have to make decisions most of the time, they just provide the capital. The board is there to make sure that their best interests are being catered to basically.
The DAO is almost as if you got rid of management entirely. With the DAO, you have a distributed consensus platform for all shareholders to participate in. Decisions are made democratically through a proposal system ("Should we invest x amount of Ether into y?"), and regulated semi-autonomously by Ethereum contracts. I say semi-autonomously because there is a sort of "board of directors" that takes proposals and filters them out to make sure that a) there aren't too many proposals to be voting on, and b) all the proposals to be voted on are reasonable. You can also split off your stake in the DAO into a smaller DAO if you feel your voice isn't being heard or you don't like the direction the current DAO is going. This is what was attacked the first time IIRC.
There's a whole lot more to it of course, but that's basically how I understand it.
Here, I googled it for you https://daohub.org/
Based on that, I feel like they are in tight competition with helena.co . http://gawker.com/i-have-no-idea-what-this-startup-does-and-...
https://twitter.com/IOHK_Charles/status/463794004492951552
https://twitter.com/ethereumproject/status/43337626144945766...
Of course, I haven't seen anything other than those two tweets to indicate their involvement....
Could the solidity programming language have some more features to protect inexperience smart contract programmers from themselves? Certainly, nobody is disputing that.
"Aha, no security background!" is wrong.
As somebody working with a lot os startups, having somebody with 30 years of a specific core competency on the founding team is a huge red flag.
Such beliefs lead to the Appeal to Authority fallacy, and others.
Tor and Ethereum have ample access to experts via academic research, security auditors and academic consultants.
Tor worked hard to build up this pattern by encouraging a robust outsider community to form around Tor. Ethereum has done the same from the get go.
https://www.torproject.org/about/board.html.en
granted a few people with the right background, but also a bunch with backgrounds like those you listed.
Note that this covers most other cryptocurrencies as well.
http://publications.lib.chalmers.se/records/fulltext/234939/...
This functionality is there because it allows contracts to interact with each other. This allows a million different type of applications, e.g you could create a crowdfund using a gold token hold by a multisgn.
The contracts are usually trusted and their addresses set from beginning, so this is never an issue (unlike what the article implies). The DAO however allowed an arbitrary address to be used as the contract to talk to. This is flexible because it allows contracts to be update themselves, or update who they talk to, but if the contract is malicious and there is a reentrancy, then that's the issue, but again, it's the contracts fault, not the whole platform.
The platform is being shown to be superhumanly difficult to write secure contracts for. That's a platform issue.
And this goes for all of commerce, which is an important realization: security is not an all-or-nothing proposition, it is an economic affair. Whatever you wish to secure, you can expect to expend a reasonably constant fraction of that on the act of securing it. So if you wish to secure $100M you will have to do a much better job than if you wish to secure $10M or $1M, just like you're going to spend more money on the lock for a $1k bike than a $25 junker.
When DOA ended up being over-subscribed they should have immediately yanked the emergency brake because whatever plans they had would end up being moot by virtue of storing more money in the bucket than they originally planned.
Their security measures would by definition not have been up to the task because they had planned to secure a much smaller amount. Either that or they were ridiculously over-confident.
At least when they're wrong, they usually don't lose millions of dollars. (But only... usually.)
I think some people are mentally modeling Ethereum as a sort of hobby thing in their head when they say things like that. I mean, who cares if my hobby static-rendering blog platform has a few bugs in it, right? But Ethereum aspires to be the foundation of an economy. Real foundations of economies have billions of dollars worth of effort poured into them. While a small set of particularly brilliant people may produce something that can run in this environment, Ethereum isn't what it would look like if they did.
I also think that people don't realize that the usual fate of a cryptocurrency is to die. Bitcoin isn't the first cryptocurrency by a long shot. Cryptocurrencies in general are not strong, robust things. I think something like Ethereum is quite likely, but there's no particular reason to believe we aren't three or four more major fully independent stabs at the problem away from a stable solution. Ethereum makes Bitcoin look like a homework problem in comparison; it would almost be beyond belief that we'd get it right the first time.
I also think the EVM itself allows for other paradigms than Solidity that might make it easy to create certain kinds of contracts.
And I think worse is better is very powerful, so it wouldn't surprise me if Ethereum sticks along for a long time, like Bitcoin seems to be doing despite its flaws.
But that still means that, for example, when I'm trying to implement a new variant on crowdfunding, I can write the whole backend in several pages of code and just publish it, instead of renting servers, administering databases, signing up with a payment provider and having to comply with its terms of service.
An example of a vault is this scheme: http://hackingdistributed.com/2016/02/26/how-to-implement-se...
...which some researchers proposed for Bitcoin, saying it'd be "easy" to implement with a hard fork adding a new opcode. I implemented the same scheme in a smart contract and it took 20 minutes.
Sports betting needs third-party data, but casino games don't.
Solidify is a new language, specifically designed for Ethereum. If the response to contract issues like this is "but that's a known failure mode, don't do that", then that signals a problem with the language, not just the contract code.
It also signals a problem with the culture, with respect to the perceived amount of rigor required by the problem domain.
Five pages is an outside estimate, for something like a currency exchange. My crowdfunding contract is about two pages, and the vault is one.
If the point is to be an alternative to normal, "dumb" contracts, than that is exactly what it needs to be comparable to.
Yes,
but,
English
is
not
commonly
written
with
conventional
programming
whitespace and indentation
practices.And how much software would you have to write in addition to that? On Ethereum the back-end software and the "contract" are the same thing, since the software enforces the terms.
Please don't be uncivil. It's damaging to collegial conversation, and it's against the rules (https://news.ycombinator.com/newsguidelines.html). Please edit such stuff out of your comments here.
The ethereum foundation didn't do this, the slock.it team is a separate group responsible for this bug.
Presumably you trust Netflix enough to give them your credit card details, and you trust your credit card company enough to pay them when they present you with a list of transactions they claim you made.
That's fine for such big, entrenched players; presumably you wouldn't put as much trust in some unknown, anonymous online entity. (Although presumably trust in Ethereum isn't exactly high right now)
Basically the equivalent of a credit card collateral on a rental, minus the credit card company.
I just don't see how a smart contract is helpful here since you're still relying on the owner of the resource to relinquish your funds when they are satisfied that you have returned their property in the condition they rented it to you. Whether you use cash, credit card, bitcoins or eth the power dynamics remain the same because it's ultimately up to the owner to say "ok, everything looks good, you can have your deposit back now".
It sounds like a security deposit, of a type. For example, I had to leave one of my shoes at the front counter of a store that hosted a small gaming LAN in the back.
What if you were unable to accept cash (for example, you are on vacation)?
Wouldn't it be useful to make a deposit on a car, right before you use it?
What hasn't been explained here, are what guarantees the depositor receives.
I don't want to sound like a hater, and I think as a developer it seems pretty cool that you can start receiving funds on the web without relying on a 3rd party gatekeeper, but it seems like smart contracts have pretty limited uses (not that they are useless, just very specialized)
There is also no need for collateral or a smart contract in this scenario.
> Public bikes in many big cities don't have that problem either (i.e. there's no assessment of the returned bike).
How does a smart contract improve over the current system?
> A smart car doesn't have to have it either (sensors in the car could detect crashes, for example, and interiors could be built to be tough, like many public cars already - see Paris' AutoLib)
How does a smart contract help?
In all of your examples a smart contract doesn't add anything to the equation because the merchant (or the merchant's automated centralized systems) already have the authority and capability to relinquish deposited funds.
http://bw-2e2c4bf7ceaa4712a72dd5ee136dc9a8-bwcore.s3.amazona...
If this is not the type of device you're talking about please be more specific.
Admittedly, I don't really understand the distinction of a "smart contract". I am only describing the function of the system that there was some confusion over.
A machine (like the one I linked above) can accept money and dispense money at the discretion of the business rules that determine the appropriate criteria for these operations (via car sensors or whatever).
Shouldn't I be able to just leave the car anywhere in a city?
Of course not. Do it exactly like how rentals work today except in an app instead of in person. Put in your bank card info, a hold is placed on your card, when the vehicle is returned the hold is released and the service fee is charged.
