Deconstructing the DAO Attack: A Brief Code Tour
vessenes.com
vessenes.com
It's this an attack?
It's not the problem that those technologies try to solve, to get rid of subjectivity?. In a way, this could be interpreted as trying to be free of politics.
If my understanding of what they are trying to accomplish here is correct, if the system allow it, then, by definition, it's legal.
If you require a framework where something allowed by the code but with unexpected consequences is illegal, you are again where you started.
Absolutely not. Such an act would entirely destroy the credibility of the entire system and its future. If not rolling this back is detrimental to the system, then it has already failed and should be dismantled. Who would continue to use a blockchain that permits such a thing? It completely defeats the purpose.
The code is exceedingly painful to read, and makes me wish I had been involved in this effort before it made the news. I can't help but think, lack of unit tests aside, is this the first time they're running this code? What sorts of decision-making led to this outcome? I want Hanlon's razor to apply but given the amount of money involved, I am not entirely convinced.
There are 2 repos which I looked at:
https://github.com/slockit/DAO
https://github.com/TheDAO/DAO-1.0
I don't know which one is the authoritative one. But the interesting bit is both these repos still have that same typo in the master branch:
https://github.com/TheDAO/DAO-1.0/blob/master/DAO.sol#L666
(the other repo) https://github.com/slockit/DAO/blob/develop/DAO.sol#L685
The slockit account repo has a commit which was made 6 days back, with the commit message "Protect against recursive withdrawRewardFor attack" https://github.com/slockit/DAO/commit/f01f3bd8df5e1e222dde62... but it doesn't fix the typo and there aren't any more commit in there after that one.
Does this mean, the upstream repos containing the typo haven't yet been fixed? Or am I just looking at the wrong repos/branches? Or did this typo get known only a few hours back?
IIUC, once an Ethereum program is started, it cannot be killed or fixed. If so, updating the gitbub repo would be pointless at this time.
Certainly one of the challenges for the project is implementation and security issues in the Turing-complete language they decided to create for the purpose of smart contracts. Postscript and ActionScript have probably averaged a security flaw a month for the last decade; I can't imagine getting Solidity correct from the start.
transfer is a very poorly named function, of that there is no doubt. And Transfer is badly named as well.
transferAndLockTokens vs LogTransfer would be much, much better.
The idea of writing financial software without taking every available precaution to verify correctness is insane to me.
Major fuck-up there.
That should have never passed the concept stage, nor the review stage.
Function names should describe what a function does.
1: Developers, cryptographers and computer scientists should note that any high-level tools (including IDEs, formal verification, debuggers, symbolic execution) that make it easy to write safe smart contracts on Ethereum are prime candidates for DevGrants, Blockchain Labs grants and String’s autonomous finance grants.
I feel like without weird blood we'd only ever get enterprise-approved spreadsheet software.
PS: Caveat. Personally, of course I'd never use stuff like that for mission critical deployments until it's been battle tested.
It's a very bad thing to not be able to trust that your money can't be trivially stolen.
Can anyone here honestly say that if they were doing a code review they'd agree that solely a difference in case would get their approval?
And don't even get me started on filenames that only differ by case. If that's a good idea then I think trailing whitespace should be significant too!!!
from https://en.wikipedia.org/wiki/Case_sensitivity
Some computer languages are case-sensitive for their identifiers (C, C++, Java, C#, Verilog, Ruby and XML). Others are case-insensitive (i.e., not case-sensitive), such as Ada, most BASICs (an exception being BBC BASIC), Fortran, SQL and Pascal.
I upvoted you.
I don't think there was ever a case when I was tempted to name two functions with different cases, but if I ever had to write a modest-sized 1-maintainer system in which many functions came in exactly two different flavors, I might be tempted. (Perhaps threadsafe locked vs. raw? or some C++-like distinction between raw functions and closure-like class instances which can be used in a function-call context? or raw functions vs. wrappers with the extra plumbing required to let them be invoked from a scripting language?)
afterthought: And now that I think of it, in old C code I think I vaguely remember working with macro vs. function implementations of the same operation distinguished by capitalizing the name, and I don't think the name convention was an urgent problem. C macros can breed various errors, but I think bitbang_macro vs. bitbang would breed pretty much the same errors as BITBANG vs. bitbang.
The bigger point is that while you can come up with creative ways to take advantage of case-sensitivity, it's not that you would have missed it if the language was case-insensitive. From that point of view, case-sensitivity has no benefit, but only a cost: leads to irritating errors from the compiler, or runtime errors in dynamically typed languages.
If something has no benefit, and only a cost, we should get rid of it.
Next week's stupid but expensive typo will be received() instead of receive(). What will you demand then? That the compiler refuses names based on the Levenshtein distance?
It's the job of a style checking tool, not the job of the compiler.
Saying it's the programmer's fault is another circular argument. It is, only in languages that make it the programmer's fault, but I would say that it's actually the language designers' fault.
Linux has a notoriously case sensitive file system, with trailing significant spaces (they are not special characters). Mac and Windows also have case sensitive file systems but that feature is turned off by default.
Of course you can define things to be case-insensitive only in the ASCII range, and treat your non-ASCII stuff as second-class citizens...
To start off with, you think you're developing a valuable skill in being able to follow a call stack along with a bunch of variables. It certainly has its uses, but after a while you come to wonder why it always ends up this way. Sure, you can understand every bug eventually, but surely there's some reason why you're constantly reasoning about the state of the variables and the order of the function calls. You can write unit tests, but of course you can't think of all the undesired behaviours beforehand.
The author does mention that something functional with strong types is necessary. Probably a good idea.
As for the split function, there's a question of whether it is really necessary. I wouldn't have thought an investment fund would need a split function. An ordinary fund doesn't; if you're in, you're in for whatever proportion that you've put in. Why not just make a second fund with the same (reduced) code if you have some other group of investors? More functions = bigger attack surface.
I want to see Etherium work, and it is extremely unfortunate that basically THE first high profile smart contract has gone sideways. But I'm not sure if I want there to be anything we can do about it. The whole point of this project is that the blockchain is supposed to be like an indifferent force of nature.
The ability of a core of developers and miner to exercise their will over the system like this is alarming though.
https://blog.ethereum.org/2016/06/17/critical-update-re-dao-...
if (!transfer(0 , balances[msg.sender])) { throw; }
This would <snip>.... also reduce the tokens available to the user later on
The more I think of the typo and the explanation about it in that article, the more unclear I am about that whole code.
Keeping aside this hack, for a moment, if that is indeed a typo and instead it should have called the lower case transfer method to really reduce the user tokens, then does this mean that all these DAO contracts (or whatever the right term is) that have been executed till date have been affected by this and as such the entire eco-system state was already messed up before this hack?
Nothing in that article suggests that this code flow, where this apparent typo is present, is applicable only for this specific hack.
totalSupply -= balances[msg.sender];
balances[msg.sender] = 0;
paidOut[msg.sender] = 0;
In fact, to me it doesn't look like there's a typo at all there - the call to Transfer() was fully intended just to log the burning of the tokens that will be accomplished by the later lines setting the balance to zero. The bug is simply that the balance isn't adjusted before the attacker gets a chance to execute code.
The Solidity wiki doesn't have a single entry on testing either:
https://github.com/ethereum/wiki/wiki/The-Solidity-Programmi...
You can't really unit-test contracts at the moment.
(I'm a cryptocurrency noob... Some of technical stuff just went over my head)
but there's a reason we still have courts and judges. it's because language is the tool through which humans express their desires and fears (computer language included, because it is written by humans, so far), it's not a machine.
The question that's playing out right now is "is there human judge behind the code." If a set of humans (miners and developers) successfully overrule the code, this will seriously undermine the whole premise of this project.
EDIT: To the downvoters, if you disagree, I would very much like to understand why, please reply with a comment.
EDIT2: My position is that it is very difficult to reason about correctness and maintain invariants in a highly imperative setting. IMHO, it would be more desirable to use a declarative, or functional language. There are many successful commercial applications of functional programming to financial contracts, e.g. Lexifi, which is based on a subset of OCaml and various in-house solutions developed by banks. Using a functional programming language would also mean the code is far more amenable to formal methods and static verification. One new startup I was very impressed with, aestheticintegration.com, has had success rewriting financial algorithms in a functional programming language in order to prove and verify numerous correctness properties about them. It is a huge shame that folk do not reach straight for the functional programming toolbox when faced with these types of problems.
That it's imperative code is something that I don't think is damning by itself but all the side-effects (including side effects based on a single bit in the name of a function) really do warrant the 'accident waiting to happen'.
Are you saying that function names should be case-insensitive?
Some language features you best not exploit if you want to write reliable and bug-free (to whatever extent possible) code.
This is not a typo so much as it is a very poor choice of naming convention.
If you think otherwise, in what situation would it make sense to have two functions with names differing only in case? No upside, only a downside.
In many other domains, a suboptimal choice of language paradigm would just add some extra friction but in the domain of smart contracts it can lead to catastrophic failures. Many people claim that the cause of the present disaster is just a faulty contract and that the Etherum system is working correctly. Some even say that the present case shows how well the technology is working. But willtim's comment makes it clear that there may be a fundamental problem with Ethereum. I wonder whether the imparative paradigm was a conscious design choice or something that just happened because the developers didn't even realize that it was a design choice.
Edit: I wrote this before willtim's added his edit 2.
Ensuring correctness -- i.e. conformance to a specification -- is, in general, a task that requires effort -- by man and/or machine -- proportional only to the complexity of the algorithm verified (i.e., the number of states reachable by a TM implementing it) and almost not at all to some linguistic properties. That is not to say that languages cannot prevent local errors that may be catastrophic, but the difference between the best of languages and the worst of languages when it comes to verifying spec-compliance is not that big.
> Using a functional programming language would also mean the code is far more amenable to formal methods and static verification
That is not true. If anything, imperative languages have better formal verification tools than functional ones. And besides, for global program "correctness" properties, the choice of a language more or less amenable to formal reasoning may make a difference that is surprisingly small.
The Ethereum model is "imperative" anyway, so a functional DSL would probably end up looking like some kind of monad.
That said, it seems interesting to use a language like Agda for writing a DSL to EVM compiler, regardless of the exact nature of that DSL. Then you can have machine checked compiler correction proofs and also prove theorems about DSL programs.
First of all, end-to-end verification is something very unique. CompCert is a great accomplishment, but it is only a medium-sized program, it required a world-expert to write, and even then it tool a lot of effort and still he skimped on the termination proofs.
Imperative tools, OTOH, are used every day by thousands of engineers to write verified software of various kinds (e.g., [1]). So the answer to your question is: except for end-to-end verification, which is extremely costly with any approach, they can do better. In fact, as promising as FP approaches may be, they are still very much in the lab with nearly negligible industry use (and in the one or two cases Coq has been used in the industry, it was always done jointly with academics).
Also, I'm a bit puzzled because you specifically mentioned OCaml, which is an imperative functional language.
In fact, while the difference between programming language in terms of general amenability to formal methods is not great, there are certainly large differences in amenability to model checking. This is why a language like SCADE (based on Esterel and the FRP-ish Lustre) is a fairly widely used tool in aviation software. If anything, a synchronous language like Esterel or the modern Céu[2] are a better choice if you want your verification to be as automatic as possible and run in a resource-constrained environment (that's killing two birds with one stone).
> As far as Europe is concerned, FP does appear to be the future of formal verification.
Even if you look at INRIA, the most European of institutions and the birthplace of Coq, you'll see that they dedicate significant verification research to other approaches[3]. At Max Planck, FP is a clear minority[4].
And if you look at the academic community at large without artificially restricting it to Europe (which certainly has a linguistic bias), you'll see that the verification community is certainly not betting on FP (although they are certainly exploring it). Don't get me wrong: FP and linguistic approaches is certainly one avenue among several showing promise in verification. But it is downright false to say that this approach is recognized as "the future of verification".
[1]: https://verificationinstitute.org/wp-content/uploads/sites/2...
Oh, sorry.
> we appear to be less commercially influenced
I don't think this has anything to do with commercial influence -- just academic tradition and maybe even philosophical influences: I think you'll get different answers to the question, "does an algorithm or a computation exist outside its description in a language, and if so, in what way?" This may be tied to actual philosophies, Derrida in France vs. Kripke in the US[1] (to prove the connection, a "Kripke structure" is a very common mathematical structure denoting an "abstract" computation, which is used commonly in non-language-based verification). I've been told that the study of program semantics tries to reconcile the two.
As to Haskell vs. Python, first, MIT used to teach Scheme; they have explained their reasons for switching to Python. Second, this difference is more indicative of the competition between "theory A" and "theory B". Theory A studies algorithms and complexity (and Haskell is not the best first pedagogical choice for that), while theory B studies logic and semantics (and language). Theory B is relatively small, but it does have a stronger presence in Europe. Although, even within theory B there seem to be those who prefer linguistic approaches (semantics) and those who prefer conceptual approaches (Kripke structures, abstract machines).
[1]: Not that Britain is too fond of French philosophy, but the Brits had Robin Milner, who is as close to a CS deconstructionist as you could find.
When are Turing machines ever involved? Verification tools often make use of abstract state machines as the subject of their study. I am not aware of a single one that deals with Turing machines (nor am I aware of a single TM programming language being used in the industry). TMs serve an important role in theoretical computer science, in automata theory and complexity theory, but not in verification or PL.
> This is essentially functional programming as far as I'm concerned.
It isn't. Logic was applied to programs long before FP was in vogue.
> The advantage of the dependant-type approaches like Coq and Agda, is that the language of proof and implementation is now one of the same,
Two things. First, you can implement a system in Isabelle, too. Second, that advantage -- if it is one -- is rather theoretical at this point. Dependently typed languages have never been used outside of the lab, and have never been used in a large project. The approach, BTW, has plenty of disadvantages. First, the languages are very hard to learn, and require some very exotic, obscure math; second, some very important properties like time and space complexity -- that are often just as essential as logical correctness for those application where correctness matters most -- are hard to express, and there's no consensus yet on how to best reason about them. In short, dependent type approaches may one day be useful, but in general, we're not sure exactly how to use them yet.
> a total functional program can serve as both an executable specification and a logic with which one can derive proofs from
That is absolutely true, but this has some very severe disadvantages as well.
> so watch this space...
I have no doubt. But you should be aware that FP approaches to verification are just some of the many avenues in verification research these days, and are not generally accepted to be the most promising ones. In addition, unlike other approaches, they have pretty much never been put to the test outside the lab. Finally, SMT solvers are successfully used to verify Java programs (with JML specifications), and in the research world, Microsoft's Dafny[1] -- an imperative, non-functional (I think) language -- is a very popular choice in verification challenges (alongside tools like KIV[2] and Why3[3]). They also, I think, serve as the core proof method of SPARK Ada, a heavy duty verifiable language, with a good track record over many years in the industry.
[1]: http://research.microsoft.com/en-us/projects/dafny/
[2]: http://www.isse.uni-augsburg.de/en/software/kiv/
[3]: http://why3.lri.fr/
Most software is written in imperative Turing equivalent languages, so Turing Machines are involved all the time. The fact that most verification software is not capable of dealing with them, demonstrates a language issue. Which is the point I have been trying to make.
> It isn't. Logic was applied to programs long before FP was in vogue.
I'm advocating modelling contracts with Logic, instead of Turing Machines as used by Ethereum. I didn't mean to create a tribal boundary by using the term FP.
I don't understand what that means. Everything is "Turing equivalent" in some sense[0]. It's like saying that since every language can be compiled to C, then C is "involved all the time". That would even be more accurate, because our programs are most certainly not TM-equivalent. Proof: the asymptotic complexity of a real program and that of a Turing machine for most algorithms differs by a power of 2 or 3. Therefore, programs and TMs cannot possibly be equivalent. If you had said RAM machines at least you would have been somewhere in the ballpark, and RAM machines are not Turing machines (see https://en.wikipedia.org/wiki/Random-access_machine).
> The fact that most verification software is not capable of dealing with them, demonstrates a language issue.
But that is not a fact, because 99% of the thousands of very real, verified production systems being constantly worked on are written in imperative languages, and roughly 0-1% is written in functional languages. Quite the contrary, verification software handles imperative programs better than functional programs. You don't have to take my word for it. See what one Xavier Leroy (author of CompCert) says on the issue here[1] and here[2]. So far, verification in functional languages requires inordinate effort.
The question of how much verification is tied to language is very much an open question.
> I'm advocating modelling contracts with Logic, instead of Turing Machines as used by Ethereum.
I wonder what you'd say about temporal logic, which is not only the most popular logic in software verification but one that models state machines.
As to Turing machines, I don't think you understand what they are. A Turing machine is one particular automaton, a particular instance of an abstract state machine, and a universal computational model, which is usually applied directly only in computational complexity theory, where it serves as a common cost model. The lambda calculus is a rewriting system (typed versions of which can be tied to one particular kind of logical reasoning via the C-H correspondence), another universal model of computation, and -- guess what -- another instance of an (ND) abstract state machine!
In short there are many concepts here that you mix up. Turing machines, however, are one concept that is completely absent from both PLs and software verification (where it tends to turn up only in the marketing speech of some FP advocates). No one programs Turing machines. Program logics most certainly apply to imperative languages, and in fact, this is -- to date -- where they are most used, and quite successfully.
[0]: And if you're referring to total languages then you're confusing things further. Totality has little effect on verification; it is required in order to not introduce logical inconsistencies in typed lambda calculus, and is only relevant when dependently typed languages are used to prove general mathematical theorems -- not verify programs.
[1]: http://events.inf.ed.ac.uk/Milner2012/X_Leroy-html5-mp4.html
[2]: http://events.inf.ed.ac.uk/Milner2012/Monday_Panel-html5-mp4...
> Everything is "Turing equivalent"
This doesn't make any sense. As you say, there are less powerful automatons. A programming language does not need to support universal computation, for example Unix RegEx.
I cannot disagree that imperative programming is more popular, but again that is no proof that we are better of using them is we want to easily build correct software.
No, again -- you are confusing specific machines (like TMs) with abstract state machines. Abstract state machines are a super-set of Turing machines (some are equivalently powerful in terms of computability, albeit "faster" wrt time complexity -- e.g. lambda calculus or RAM machines; others are less powerful). But Ethereum is not a Turing machine, just like Haskell isn't. Turing machines are a very specific thing, like x86 assembly. Ethereum is not based on x86 assembly, just like it isn't based on Turing machines.
> but again that is no proof that we are better of using them is we want to easily build correct software.
I agree; I didn't say they're any better. But you claimed that FP is better, and there's certainly no evidence to support that. Some extremely powerful formal verification tools, however, currently have no good, production-quality applications for FP.
[1]: The difference, therefore, between verification of Turing-complete programs and total programs is that the cost of verifying the former in the general case is infinite, while the cost of the other grows like some function that is larger than any function we can ever compute. From the perspective of computing power, both are equally beyond reach.
Given the sums of money involved I think it might also be worthwhile to have a formal semantics and a logic for proving safety properties of these blockchain programs (beyond type safety).
Not every application would require that kind of rigour but if the participation and value of a given currency/contract/program is determined largely by trust then it seems natural to want more serious guarantees.
Examples:
* Agda (http://wiki.portal.chalmers.se/agda/pmwiki.php)
* Coq (https://coq.inria.fr)
* Idris (http://www.idris-lang.org)
If you write bad code, you will eventually get bitten. If you use bad code to build a financial institution with great claims, it will also cost you money and reputation.
Bad engineering has consequences.
Sending should always succeed immediately and if anything needs to be automatically triggered in response, the trigger should be executed asynchronously.
A great way to immediately see the problem is, for anyone with Rust experience, to think of this as a function taking an &mut self being somehow reentered without that &mut self being passed out by the function itself.
In addition to typesafety, it would have to be both explicitly typed at the lowest possible granularity and annotated with pre and post conditions.
Not only did this code allow a bunch of tokens be transferred without compensation, it left the whole accounting system in a corrupted state! One that could have easily been detected and verified at any point.
This line:
```
Transfer(msg.sender, 0, balances[msg.sender]);
```
```
// postcondition: balances[msg.sender] == 0
Transfer(msg.sender, 0, balances[msg.sender]) :: Action<Transfer>;
// Compiler result:
// # Error 1: line XX expected type Action<Transfer> but instead got type Transfer
// # Error 2: line XX violates postcondition, expected balances[msg.sender] == 0, got balances[msg.sender] != 0
```
It's nice that Vitalik Buterin is a genius, but it shows that this guy is only 22 and dropped out of university because anyone with a degree in computer science knows about this stuff and its importance in high reliability systems. He should have known the contract language should have had typechecked side effect and he should have known proper pre- postconditions would have been the least he should have done.
Edit: apparently the thefts so far are "only" 45 million.
Just kidding; bad joke; I just couldn't resist.
Those are currently not the issues that require attention.
You can make it as fast and as large as you want, if it is broken at the root that's all pointless. First walk, then run. I'd be more impressed with a much smaller system without sharding and massive scaling properties if it was bullet proof.
Ethereum itself is more bullet proof, as there are multiple implementations and the description of the protocol better defined and has proofs inside.
That's the whole problem in a nutshell. I highly doubt that is the road to a viable solution but I'm patient enough to be proven wrong in the longer term. But anything that is Turing complete automatically implies that anything layered on top of it will incorporate such niceties as being impossible to formally verify due to the halting problem.
In other words: the only way to establish whether or not the code will try anything funny is to run it.
Whenever you want any guarantees about anything you implement a very restricted[1] subset of what a TM can do... at least if you're allowing users to input arbirtrary programs[2]. If you don't restrict to a non-TC language... you're -- in so many words -- fucked. (Hence the "hack".)
[1] Preferably using a statically typed PL, for obvious reasons. There's actually a thing these days where non-TC languages can actually "do things". My favorite moniker for this is "pacman-complete" (coined by Edwin Brady, I believe.)
[2] Having looked at a few .sol files earlier, they at least look TC, having general recursion and all.
Not sure I follow here... You can certainly run a non-turing-complete language on top of a turing-complete one and anything in that language could potentially be verifiable.
This is what happens when one does not do that. :)
Personal attacks, which this crosses into, are not ok on Hacker News. Please edit such stuff out of your comments here.
We detached this subthread from https://news.ycombinator.com/item?id=11928562 and marked it off-topic.
I guess I felt the need to accuse someone as I felt frustrated. News like this really smears not only cryptocurrencies but software engineering in general. A single typo cost these people $50M is what they claim, but the reality is that the whole system was recklessly engineered. I guess I'm also saddened that so much money was put behind something that was so clearly recklessly engineered.
Would it been a crazy idea just to invest a million or two of the $250M to pay a Formal Methods team at any university in the world to give the language a quick do-over?
If it was phrased as "person XYZ is an asshole!" then I would agree that it's a personal attack.
I wouldn't be so hard on the kid. Now, the due diligence that should have been performed by the corporations that sank millions in to this project, who actually do hire plenty of people who are well educated and should have known better is another matter.
But I suppose jumping in early in to the tulip craze and riding it for all its worth is more important than taking the time and effort to make sure the system is reliable and robust before it goes live.
I have been told he's not big on functional / richly typed systems, but I don't have any actual knowledge.
It's bad enough that those with sufficient computing speed/power can already rip off the stock market; why does the world need another way for people to rip each other off?
Since we've determined over history that some people will take advantage of weakness for their own gain, no matter what system you create to transfer goods, resources, services or value representing those, it will be exploited. So- why even spend time on it?
If everyone who cares to maintains their own accounting data does so, regardless of what technologies we are using, we really could just trade in goods, services, and coin and completely get rid of all virtual currency. Investments could go back to literally to providing coins, goods, resources, or services to those that we'd like to support possibly in exchange for reciprocity.
Since that won't happen right away, if you really want to secure your financial future, major S&P 500 index tracking funds have been one of the smartest things over its history to invest in: http://finance.yahoo.com/echarts?s=%5EGSPC+Interactive#symbo...
While some of you made money on bitcoin, many lost. Now the same game has been played again with people believing that someone can write code to replace our currency system and if they get in early enough, they'll be kings or queens. Well- again, it didn't happen. What really is to gain from this fantasy world of cryptocurrencies? It is harming more than it is helping, from what I see.
And if you downvote this, tell me why, otherwise I'll just assume you are with those that want to exploit me and others.
Because the DAO's failure is interesting.
Just imagine if you will if all members of the site created similar comments constantly. That would hide all of the discussion relevant to the topics being discussed.
But, I agree with what you said- I don't like it when people enjoy suffering either. I just think that possibly the best way to handle it would be to just ignore those posts, as you might elicit more response from them.
Is that all you see?
Decentralized currencies, ethereum and DAOs are fascinating from a technological standpoint. This is major news in the field of smart contracts, which are related to both programming and technology. How could this not be posted here?
Because they are interesting in a theoretical way and because real world implementations are even more interesting, they show us what the future might look like.
> It's bad enough that those with sufficient computing speed/power can already rip off the stock market; why does the world need another way for people to rip each other off?
That's not the intent.
> Since we've determined over history that some people will take advantage of weaknesses for their own gain, we should assume that as a given until proven otherwise.
Agreed.
> No matter what system you create to transfer goods, resources, services or value representing those, it will be exploited.
That remains to be seen. There is an outside chance that it is possible to create something solid, my guess is that it will have to be something extremely simple.
> So- why even spend time on it?
Just like it took a while to map the globe, mapping this 'space' takes time - and effort - and funds. I'm fine with it, it isn't my time, my effort or my funds and I end up learning just as much as those that put forward their resources. Think of it as free education on someone else's dime. That's a pretty cynical view but to date I have not seen any system that appears to be solid enough to warrant backing.
> If everyone who cares to maintains their own accounting data does so, regardless of what technologies we are using, we really could just trade in goods, services, and coin and completely get rid of all virtual currency.
That would severely limit the amount and kinds of trade possible. On the other hand, a really strong cryptocurrency has risks all its own and it is worthwhile to consider the downsides with the upsides.
Isn't this a somewhat meaningless statement? Is it possible to prove that "no matter what system you create to transfer goods, resources, services or value representing those, it will be exploited"? Is it possible to prove the contrary (that there is or could be such a system)?
It will never be seen because we will never know for sure one way or the other. Best we can do is to make educated guesses based on past experiences.
So until these systems reach reliability parity with 'ordinary' banking we'll see reduced trust. But once a system gets launched that has staying power and that appears to have made the right decisions in the founding phase you can expect more and more commerce to ride on them.
When more commerce is involved the 'bounty' on finding a flaw increases and so any system that carries a substantial amount of commerce and that keeps on standing can be presumed audited to that level.
So it really remains to be seen, which group comes up with a system solid enough to carry a substantial fraction of the worlds commerce. Bitcoin is interesting because even after a couple of years it is still standing, which all by itself is impressive.
Will we ever know for sure? I suspect we will not because this is akin to proving a negative, just like you can never be 100% sure that you've found the last bug in a system. But at some point the premium will be so high that failure to exploit the system should give good confidence that all avenues for exploitation have been exhausted and that even if the system still contains flaws those flaws may not be exploitable. It's an asymptotic curve.
This is on HN because this story is interesting from a technical point of view.
That is, a medium of exchange is essential to a modern economy and yet how to objectively regulate the supply of that medium of exchange without exploitation can be considered somewhat of a paradox. The quest is to solve the paradox via ever evolving technological solutions.
There's your problem. Such grandiose visions might have passed for a 1930s-era technocrat, but are laughable today.
I think you misunderstood...regulate as in increase or decrease the creation of the medium of exchange through technology, not government entity.
Who is getting ripped off?
Search your feelings, you know it to be true.
Cryptocurrencies attract money and spawn companies, there are YC funded startups that are based around cryptocurrencies. If you're looking for refuge from them, you've gone to the wrong place, this is basically the lions den. If there's money to be made with technology, this is where it'll be discussed, no matter over whose back.
Just that it's on HN doesn't mean HN or even YC supports it. If everyone on HN would support ETH, BTC or the DAO, it'd be worth even more. It's just interesting technology with relevance to business and finance.
Been here since 2007 off and on. Usually don't use same user because I quit HN periodically due to philosophical differences, and I don't care about HN user karma or the ability to downvote.
It's been my experience that people here have many interests, and debates of we should be exploring certain avenues and why we obsess over things are just as valid as any other.
> I know I'll get napalmed for saying this
> And if you downvote this, tell me why, otherwise I'll just assume you are with those that want to exploit me and others.
Please reread the HN guidelines, particularly the last two: https://news.ycombinator.com/newsguidelines.html. If you're going to comment here, please follow them.
The "why is this on HN" genre is also pretty lame.
Here are some you might be unfamiliar with:
'When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."'
'Please don't submit comments complaining that a submission is inappropriate for the site. If you think a story is spam or off-topic, flag it by clicking on its 'flag' link. If you think a comment is egregious, click on its timestamp to go to its page, then click 'flag' at the top. (Not all users see flag links; there's a small karma threshold.)'
Thanks.
The existing financial system is inextricably entwined with our political and legal system. This is both good and bad. Bitcoin, ethereum, etc. are efforts to make financial systems that are independent of politics and central management. In my opinion, Bitcoin has done a much better job, because it's actually reasonably decentralized and they don't change the rules whenever people get their money stolen.
What not to like about reading about news and opinions about this ? I find the current obsession with deep learning/AI here much more uninteresting
And also, just read the first word of the name. HACKER news, which is very self explanatory