Imagine someone sending $100.000 of his hard earned money and from loans to pay for his daughter operation and this gets lost because of a bug and a developer in panic mode!
> That's why this tech it's still not safe to use.
For many cryptocurrency users, it's not intended to be "safe" - it's intended to be free.
Consider that running `rm -rf "/$APP_ROOT"` in a shell script is unsafe. People writing their own shell scripts are doing so for the power it offers them, and should be aware that this power enables them to shoot themselves in the foot. Likewise, if you choose to "be your own bank" cryptocurrencies give you the power to do that - and the power to shoot yourself in the foot.
> Imagine someone sending $100.000 of his hard earned money and from loans to pay for his daughter operation and this gets lost because of a bug and a developer in panic mode!
Imagine someone bringing $100k in cash to the hospital to pay for that operation, only to have their car catch on fire and consume the cash on the way. The specific mode of failure here is different for cryptocurrencies, sure, but this category of failure is not unique.
Most people would say that transporting $100,000 in cash in a normal car is a really, really bad idea. If that’s the analogy for cryptocurrency, it seems to be an unflattering one.
I think most technology starts out unsafe/unreliable and overtime as early adopters use it, they'll get to a point where it is reliable. This is a point-in-time, that will almost certainly change probably in the next 12+ months
But it is solved by the banking system: if the bank burns down, insurance will make you whole. If a distributed cryptosystem burns down, you have a lot of worthless bits.
TBH the real category of failure we see here is more like a Central Bank suddenly declaring half the money in the country is fake and worthless, and inadvertently wiping half of the existing bank accounts. It's the sort of thing that might happen once in a century, or less; cryptocurrencies seem to see one every few weeks.
Correct me if I'm wrong, but isn't that entirely different on account of not 'suddenly' declaring your money fake and worthless, but rather allowing people to bring their money to a bank for other notes?
I am not sure how your link disputes the title. A hard fork to a new currency still means that the past currency is unusable forever, and in the world of crypto, that means lost forever.
didn't they? People invest in hardware, pay electric bills, even purchase coins from stock exchanges to have them and suddenly - fork? of course they lost money.
No, it isn't, because the price can go back up in the future. In this case, there is no hope of recovery unless you count the entire network pretending this never happened as recovery. Ironically, the real stock market is more immutable in practice than Eth.
I think it's difficult for some people to truly understand the concept of currently. They don't realize that it's a fictitious thing that gets is value solely from others trusting it. So to them, a fork is just a fork. Ya know, some money here and some money there. What's the big deal right? What they don't seem to grasp is that this action kills the trust of the old currency. It has no value moving forward. It's dead and will quickly become useless.
People have developed this expectation for currency (a dollar being this thing that you can hold which always equals this amount printed on this price tag) without having any real understanding of what currency is really. This leads to odd assumptions.
Under the current implementation and rules of the Etherium system, they have lost their money. It may be possible for them to get it back, if they are lucky.
The funds may be locked away forever unless the Ethereum network "hard forks" by adding a consensus rule exception that specifically releases these funds.
It's built into the agreed upon protocol. Votes in the future may change this, but that would compromise the value proposition. I don't think we can say that until over a hundred years from now in 2140-2150 when the last block is mined and people scramble for alternate ways.
Rules were changed once already, why not again? Just because core developers are not involved? I really wonder what Vitalik is going to say on the topic.
I wish code was the law, but apparently, it's not. Same rules for everybody, please.
The way Ethereum, its programming language, as well as its "smart contracts" work effectively ensures there will be an infinite amount of such issues in Ethereum's future (assuming Ethereum also survives indefinitely, despite all of these issues).
If Ethereum is the "internet," then all of these incidents are kind of like "data breaches" that have happened and will continue to happen for the entire life of the internet/Ethereum network. And if the number of data breaches throughout the internet's life is any indication for what will happen on Ethereum, there will be a lot of "hard forks" in Ethereum's future, too.
Ethereum devs signed-up for this when they decided to make its smart contracts Turing complete.
My position on Ethereum is that it will never be a general-use currency for human beings. Logically rigid contracts are not a feature that people really want. We've built entire judicial systems around the idea that contracts are malleable and that judgments are often sought that take more into account than was known at the time of creation.
Ethereum may actually end up really shining as autonomous organizations become a real thing.
How about you give away 50% of tokens recovered to charity to incentive 51% of ethereum community to make hard fork? I see no reason why would whole ethereum community should care about what users of specific contract are doing.
The whole sales pitch of ETH is that the code is the contract. Thus the contract is literally the codified agreement of intent of the parties. There is no intent apart from the code.
There are no bugs. There is no theft. There are no accidents. There can be no need of a hard fork.
The point, then, is that it is the code that matters, even if one party later says "oh, this isn't what I meant". That's the _point_ of using a "hard" blockchain as opposed to transactions that can be subjected to the judgement of "soft" people even after they have taken place.
Indeed. Last time this happened, it was _almost_ funny how people argued (successfully) for an undoing of their mistake, even though their very own business proposal [0] stated as clear as it could possibly be stated that the exact code would set the rules, and come before any other interpretation:
> The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code. Any and all explanatory terms or descriptions are merely offered for educational purposes and do not supercede or modify the express terms of The DAO’s code set forth on the blockchain; to the extent you believe there to be any conflict or discrepancy between the descriptions offered here and the functionality of The DAO’s code at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413, The DAO’s code controls and sets forth all terms of The DAO Creation.
People who work with Law know that acts are not written into stone, because what matters is the stance of the greater society. An example are unlawful acts of rogue states. People have been sentenced to death because they followed acts by rote.
The idea that the code is the contract is therefore doomed to failure.
Can someone ELI5 if this is an issue with Ethereum in concept/execution or with Pairity and how they handle Eth?
Is this an issue that can be repeated on different wallet platforms/exchanges easily, or is there something uniquely wrong with Pairity wallet that caused this?
Parity made this particular bug; but the bug and impact raise questions about:
1) Whether the Ethereum/Solidity design and implementation is good enough, because it seems that bugs like this and not like this are far too common and far too easy to make, and a better design/implementation would make such incidents less common;
2) Whether the Ethereum concept/sales pitch of smart contracts that cannot be overridden is actually something that the community wants, and perhaps there does need to be some structured way/process on how flawed contracts can be altered; as the DAO incident is some evidence that we might want a way to alter contracts in certain conditions, but the previously used solution of ad-hoc hard fork isn't a good one. Perhaps we do want smart contracts that can't be overridden in any way whatsoever, but we have to acknowledge that this has a serious price - incidents such as this one.
This is comical. Anyone who tells you that currency was actually worth $300MM is out of their mind. This is an interesting experiment, but seems more like a pump-and-dump.
True value or Real Value are stabilized values in the market directly proportional to usefulness of the commodity or currency. If people wanted this much ETH, it would be worth that much, but saturating the market with that much more ETH would drive prices down. It's like the meteor that was made of Iron that swung by the earth "it's 5 quintillion dollars of iron ore!" well, with simple multiplication that may be so, but the assumption is that this material would be absorbed into an economy that can use it effectively. Nobody is actually going to hand you 5 quintillion dollars for the meteor.
Bug in a specific DB or HTTP server implementation exposes confidential data: Patch it or shut it down.
Bug in a specific service: Patch it or shut it down.
Ethereum is equivalent to those things. It is not equivalent to the Internet, that would be "blockchain technology" (quotes because it's such an ambiguous and ill-defined space right now).
Ethereum is buggy. Plain and simple. It is ill-designed, ill-scoped, and ill-managed (there never should have been a hard fork for the DAO fuckup).
I’d say it’s a bug in ethereum. A Contract has dependencies. Those dependencies can be shut down before the contract. The contract is now stuck, unable to be processed.
This is very much like the leftpad issue with node and npm. It’s a flaw in the design of the system that permits this behavior. The contract (wallet software) is also clearly buggy. But the bug is a consequence of the ill-designed foundations.
Actually, a lot of people have called for Equifax to be shut down as well. It's just a lot harder to kill a company, even ones that have engaged in wildly irresponsible or illegal activity, than it ought to be.
I think the community needs to develop a process ahead of time for determining how to deal with these issues. A good start might be:
Can the protocol be made more robust against this class of error?
Is the proposed protocol change victimless? (nobody has already spent forked funds, etc.)
Is the protocol change elegant? (If you were to start over would the implementation have included this change to begin with? e.g. no hard-coded addresses with special code paths)
75 comments
[ 3.5 ms ] story [ 129 ms ] threadImagine someone sending $100.000 of his hard earned money and from loans to pay for his daughter operation and this gets lost because of a bug and a developer in panic mode!
For many cryptocurrency users, it's not intended to be "safe" - it's intended to be free.
Consider that running `rm -rf "/$APP_ROOT"` in a shell script is unsafe. People writing their own shell scripts are doing so for the power it offers them, and should be aware that this power enables them to shoot themselves in the foot. Likewise, if you choose to "be your own bank" cryptocurrencies give you the power to do that - and the power to shoot yourself in the foot.
> Imagine someone sending $100.000 of his hard earned money and from loans to pay for his daughter operation and this gets lost because of a bug and a developer in panic mode!
Imagine someone bringing $100k in cash to the hospital to pay for that operation, only to have their car catch on fire and consume the cash on the way. The specific mode of failure here is different for cryptocurrencies, sure, but this category of failure is not unique.
But it is solved by the banking system: if the bank burns down, insurance will make you whole. If a distributed cryptosystem burns down, you have a lot of worthless bits.
TBH the real category of failure we see here is more like a Central Bank suddenly declaring half the money in the country is fake and worthless, and inadvertently wiping half of the existing bank accounts. It's the sort of thing that might happen once in a century, or less; cryptocurrencies seem to see one every few weeks.
https://en.m.wikipedia.org/wiki/2016_Indian_banknote_demonet...
They can do a hard fork and this money will re-appear.
When you invest in the stock market, and the market crashes, THAT money is lost forever. This is not that.
No, it isn't, because the price can go back up in the future. In this case, there is no hope of recovery unless you count the entire network pretending this never happened as recovery. Ironically, the real stock market is more immutable in practice than Eth.
People have developed this expectation for currency (a dollar being this thing that you can hold which always equals this amount printed on this price tag) without having any real understanding of what currency is really. This leads to odd assumptions.
Forget it, Jake. It’s just fake internet points.
I wish code was the law, but apparently, it's not. Same rules for everybody, please.
For the record, I did (do) not support that either.
If Ethereum is the "internet," then all of these incidents are kind of like "data breaches" that have happened and will continue to happen for the entire life of the internet/Ethereum network. And if the number of data breaches throughout the internet's life is any indication for what will happen on Ethereum, there will be a lot of "hard forks" in Ethereum's future, too.
Ethereum devs signed-up for this when they decided to make its smart contracts Turing complete.
Ethereum may actually end up really shining as autonomous organizations become a real thing.
Even your "autonomous organizations" will need to deal with e.g. the halting problem, for example.
http://cognet.mit.edu/book/heterogeneous-agent-systems [You want to read chapter 10.]
There are no bugs. There is no theft. There are no accidents. There can be no need of a hard fork.
Except that one time with the DAO.
> The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code. Any and all explanatory terms or descriptions are merely offered for educational purposes and do not supercede or modify the express terms of The DAO’s code set forth on the blockchain; to the extent you believe there to be any conflict or discrepancy between the descriptions offered here and the functionality of The DAO’s code at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413, The DAO’s code controls and sets forth all terms of The DAO Creation.
[0] https://web.archive.org/web/20160704190119/https://daohub.or...
The idea that the code is the contract is therefore doomed to failure.
Is this an issue that can be repeated on different wallet platforms/exchanges easily, or is there something uniquely wrong with Pairity wallet that caused this?
1) Whether the Ethereum/Solidity design and implementation is good enough, because it seems that bugs like this and not like this are far too common and far too easy to make, and a better design/implementation would make such incidents less common;
2) Whether the Ethereum concept/sales pitch of smart contracts that cannot be overridden is actually something that the community wants, and perhaps there does need to be some structured way/process on how flawed contracts can be altered; as the DAO incident is some evidence that we might want a way to alter contracts in certain conditions, but the previously used solution of ad-hoc hard fork isn't a good one. Perhaps we do want smart contracts that can't be overridden in any way whatsoever, but we have to acknowledge that this has a serious price - incidents such as this one.
Of course, like with any stock or commodity, the market price is the valuation of the good _for small amounts_ of the good.
Ethereum bug loses 500k eth: Shut it the fuck down it will never work.
People... get used to stuff.
Bug in a specific DB or HTTP server implementation exposes confidential data: Patch it or shut it down.
Bug in a specific service: Patch it or shut it down.
Ethereum is equivalent to those things. It is not equivalent to the Internet, that would be "blockchain technology" (quotes because it's such an ambiguous and ill-defined space right now).
Ethereum is buggy. Plain and simple. It is ill-designed, ill-scoped, and ill-managed (there never should have been a hard fork for the DAO fuckup).
This is very much like the leftpad issue with node and npm. It’s a flaw in the design of the system that permits this behavior. The contract (wallet software) is also clearly buggy. But the bug is a consequence of the ill-designed foundations.
Can the protocol be made more robust against this class of error?
Is the proposed protocol change victimless? (nobody has already spent forked funds, etc.)
Is the protocol change elegant? (If you were to start over would the implementation have included this change to begin with? e.g. no hard-coded addresses with special code paths)