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.
You're being thoroughly downvoted, but I don't see anything wrong with your argument. The person who pulled off this "hack" was following all the rules. In fact, I could even see the argument that by undoing this transaction, the people who started the DAO are in fact going back on their word. They promised that they would build a system which would obey certain rules. By undoing this transaction, they are no longer following those rules. Now, obviously there's a strong argument for rolling back the transactions, but at this point ethereum has lost any claim to objectivity or decentralization.
The apparent typo is odd, IMO. I don't know the language in which that program is written, but looking at that snippet, "Transfer" takes 3 arguments whereas the "transfer" function takes 2 arguments. Isn't there any code review involved when this makes into the codebase. Assuming there was some code review and the reviewer just missed it (which is very much possible), a basic unit test case would have easily caught this bug, isn't it? After all, the test case would have checked for the balance etc... after execution of these functions. Aren't there any test cases around this?
I think after sleeping on it that I agree with you, this is more likely the outcome of bad refactoring. You can read the code commits on github if you like; I don't have them handy, unfortunately.
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.
I couldn't follow that Transfer vs transfer call either; the number of arguments don't match, and I don't know where 'amount_' comes from.
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.
This is what I wanted to ask about. I don't even know what language this is. Is Transfer even a legit function, and if not, does this language just keep on chugging for non-existant function calls?
Case sensitivity in any programming language is crazy. I can't for the life of me see a valid engineering principal that accepts IsTheOne() and istheone() being different bits of code. Oh sure at a technical level the computer has no problem with... the problem is restricted to those oh so error prone humans.
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!!!
I couldn't agree more with this sentiment. I haven't spent too much time on Ethereum contracts but this is such a ridiculous language/platform design issue.
Are we sure that case sensitivity is the culprit? As others have noted, the function being called takes (and is given) 3 arguments but the function that is supposed to be called takes only 2.
For any language that allows non-ASCII identifiers, trying to define "case insensitive" is a minefield best avoided. For example, with general Unicode characters, "case-insensitive" comparison doesn't give you an equivalence relation on identifiers because transitivity fails.
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...
What a shitshow. These people don't need "advanced static analysis tools" [1], they need a big old bag of clue.
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.
Bored computer scientists: analyze contracts that are less popular but still have money attached to them and see if you can locate a bug. Apparently you can get the money legally and the only way to stop you is to hard fork the entire currency.
It reads like the debugging that you've done a million times if you are working with ordinary, mutable, C-family code.
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.
It looks like this is a typo. The question is, "does that matter?" It seems to me that either the code means what it says, or it doesn't. If a cabal of humans are able to overrule the machines, then what is the point of Etherium? Wouldn't we just be trading one group of authorities for another?
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.
I'm curious, are there no tests for the code running this? It seems like some of these bugs would be caught with them (especially the typo). And it seems like insanity to not have them.
So, this review makes me wonder: Will the hard fork of the ethereum blockchain be of any use at all? The DAO appears to be fundamentally flawed, are all the coins there simply lost? What prevents an attacker from exploiting the DAO after the hard fork? Or will they simply invalidate all the transactions that went to the address of the DAO?
This function will reduce user balances, before the vulnerable withdraw function is called. So, instead of the logging function, we should have:
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.
The biggest problem I see with the code at https://github.com/slockit/DAO/ is absense of the unit tests. The code looks complex, how the hell can you make sure that it's right?
The Solidity wiki doesn't have a single entry on testing either:
I don't get how the transfer vs Transfer typo is supposed to have enabled a larger attack. The token balance is zeroed in the splitDAO function anyway, and presumably the sanity checks in transfer are also redundant, or else there would have been no need for recursion.
if you could 100% accurately and reliably model a contractual understanding in any kind of language, it would have been done eons ago. human language (i'm fond of english in particular), is extremely expressive.
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.
Modelling financial contracts in an imperative event-driven paradigm just seems like an accident waiting to happen.
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.
In addition to this the language is not explicit enough. Even standard Haskell wouldn't be safe enough for a program that manages $250MM directly without safe guards.
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.
```
// 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
```
And the whole function 'splitDao' should have a type annotation that completely captures the possible actions it might encompass, and pre- and postconditions that at the very least constrain the result of the function to not corrupt the accounting of the DAO (i.e. it should still have as many tokens as it believes it has).
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.
I know I'll get napalmed for saying this, but why is this all over HN? Why are people obsessed with cryptocurrencies?
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 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.
I think maybe you're a bit confused about what HN is, it is a community that gathers and discusses news that is relevant to people who are starting or funding new companies, mostly in the information technology sector.
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.
>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.
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?
That is extraordinarily pessimistic and rather short-sighted, to be blunt. The point of cryptosystem-based financial tools is that they're more... raw than the normal financial tools we have access to historically. They work by a much stricter set of rules. This means it's easier to mess up and lose money, but it also means they're more efficient, predictable, and equitable.
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.
Because it is an insanely interesting problem to try and solve technically.
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.
Even though I disagree with some of your conclusions, I personally have no problem with your comment except for the very first and very last sentences. I generally downvote people who complain about submissions or about their comments being downvoted, which I view as unproductive.
I don't participate in virtual currencies because I am not smart enough to understand all the nuances, or at least I don't take the time to try and understand them. Plus, I don't have money to throw away. However I find the discussions about the DAO fascinating because of the intersection of technology, law, ethics, morality and government.
I agree that greed is a world wide problem.
But even when we trade in goods services and coins it doesn't change the fact that a lot of people are greedy.
This is on HN because this story is interesting from a technical point of view.
It's a very interesting combination of a lot of HN related subjects. Like networking, cryptoanarchism, decentralisation , computer science and scaling problems, cryptographic solutions and finance platforms.
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
I do not denounce your assertion(s), but, I would like to read how you apply them to Ethereum. To me, the literature seems very much to be attempting to prevent from baking in our (human) duplicitous nature, opting instead for an almost forced virtue. Please suffer a fool and expound/expand for me?
I'm sorry for violating an HN guideline by saying "I know I'll get napalmed for saying this". I was not aware of that guideline, and have been in the HN community for about nine years now.
[+] [-] RobertoG|9 years ago|reply
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.
[+] [-] wyager|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] winteriscoming|9 years ago|reply
[+] [-] vessenes|9 years ago|reply
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.
[+] [-] rrradical|9 years ago|reply
The idea of writing financial software without taking every available precaution to verify correctness is insane to me.
[+] [-] niftich|9 years ago|reply
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.
[+] [-] vatotemking|9 years ago|reply
[+] [-] legohead|9 years ago|reply
[+] [-] jacquesm|9 years ago|reply
Major fuck-up there.
That should have never passed the concept stage, nor the review stage.
Function names should describe what a function does.
[+] [-] rbobby|9 years ago|reply
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!!!
[+] [-] buttershakes|9 years ago|reply
[+] [-] draw_down|9 years ago|reply
[+] [-] charonn0|9 years ago|reply
[+] [-] bzbarsky|9 years ago|reply
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...
[+] [-] _pdp_|9 years ago|reply
[+] [-] revelation|9 years ago|reply
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.
[+] [-] seibelj|9 years ago|reply
[+] [-] lordnacho|9 years ago|reply
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.
[+] [-] tdaltonc|9 years ago|reply
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.
[+] [-] harmegido|9 years ago|reply
[+] [-] jcfrei|9 years ago|reply
[+] [-] winteriscoming|9 years ago|reply
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.
[+] [-] amaks|9 years ago|reply
The Solidity wiki doesn't have a single entry on testing either:
https://github.com/ethereum/wiki/wiki/The-Solidity-Programmi...
[+] [-] htns|9 years ago|reply
[+] [-] altern8tif|9 years ago|reply
(I'm a cryptocurrency noob... Some of technical stuff just went over my head)
[+] [-] beachstartup|9 years ago|reply
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.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] willtim|9 years ago|reply
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.
[+] [-] tinco|9 years ago|reply
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:
Should have looked like this: And the whole function 'splitDao' should have a type annotation that completely captures the possible actions it might encompass, and pre- and postconditions that at the very least constrain the result of the function to not corrupt the accounting of the DAO (i.e. it should still have as many tokens as it believes it has).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.
[+] [-] fabled_giraffe|9 years ago|reply
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.
[+] [-] jacquesm|9 years ago|reply
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.
[+] [-] tinco|9 years ago|reply
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.
[+] [-] martinko|9 years ago|reply
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?
[+] [-] wyager|9 years ago|reply
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.
[+] [-] TazeTSchnitzel|9 years ago|reply
Because the DAO's failure is interesting.
[+] [-] irln|9 years ago|reply
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.
[+] [-] xenophonf|9 years ago|reply
[+] [-] yankoff|9 years ago|reply
[+] [-] TruthAndDare|9 years ago|reply
Who is getting ripped off?
[+] [-] ghamrick|9 years ago|reply
[+] [-] huuu|9 years ago|reply
This is on HN because this story is interesting from a technical point of view.
[+] [-] jhildings|9 years ago|reply
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
[+] [-] Atwood|9 years ago|reply
[+] [-] verroq|9 years ago|reply
Search your feelings, you know it to be true.
[+] [-] fabled_giraffe|9 years ago|reply
[+] [-] waxmiguel|9 years ago|reply
[deleted]
[+] [-] homero|9 years ago|reply