It means it's gone, if the contract is followed. But a hardfork of Ethereum could change the rules to recover the coins.
A similar recovery already happened once, after somebody exploited a bug in The DAO, resulting in a fork into Ethereum and Ethereum Classic, which rejected changing the rules to bail out bugged but too-big-to-fail smart contracts.
> In May of 2016, a venture capital fund called The DAO built on Ethereum raised around $168 million, with the intention of investing in projects using smart contracts. In the same month a paper was released detailing security vulnerabilities with The DAO that could allow ether to be stolen. In June, 3.6 million Ether (approximately $50 million USD) was taken from accounts in The DAO and moved to another account without the owners' consent, exploiting one of the vulnerabilities that had been raised in May. Members of The DAO and the Ethereum community debated what actions, if any, should occur to resolve the situation. A vote occurred and in July 2016 it was decided to implement a hard fork in the Ethereum code and to move the Ether taken in the exploit to a new smart contract through which it would be restored to the owners from whom it had been taken.
> Ethereum Classic came into existence when some members of the Ethereum community rejected the hard fork on the grounds of "immutability", the principle that the blockchain cannot be changed, and decided to keep using the unforked version of Ethereum.
> This means that currently no funds can be moved out of the multi-sig wallets.
Wait, am I reading this right? All multi-sig wallets are frozen due to this? This is surely concerning, as I've seen others recommend multi-sig wallets as a security best practice.
Can anyone comment on the method in which they might revert this? Would it require a hard fork.. again?
All multi-sig Ethereum wallets created by Parity (or using the Parity contract code).
> Can anyone comment on the method in which they might revert this? Would it require a hard fork.. again?
So far, it doesn't look like you can do anything about it. Of course you can change everything with a hard fork but as this time it doesn't compromise the move to PoS, I don't think a hard fork will be the favored solution.
But this time, there is no deadline, so it can be discussed thoroughly.
I am wondering what exactly has been the point of having this code separated in this "library" in the first place, instead of just duplicating the code for each owner of a multisig wallet. It can't be to ease the update process of the core multisig code (since the library is just as non-updatable as any other contract), which otherwise is a typical reason for separating stuff into shared libraries.
Has this extra layer of complexity really been injected just to save some bytes on the blockchain?
it is a way to save on gas. Imagine all those functionality being deployed everytime someone creates a multisig. I read somewhere that the savings are in 90%? In absolute terms though I think it is very minimal and people just got way too cute with shared libraries. Again, I wouldn't trust >1M on a couple of lines of code.
The code is immutable, but Ethereum has a functionality called "suicide" by which a contract can, well, commit suicide. It is kind of like a deletion, in that the code can't be executed anymore afterwards, but of course the blockchain still contains the contract in its original, unmodified form.
AFAIK this feature was introduced to make owners capable of deactivating contracts which contain known security bugs (so at least nobody can accidentially send any more money to those contracts). And because that's the intended purpose, a suicide is non-revokable, so a dead contract remains dead forever.
A library apparently can be nuked because Ethereum does not explicitly have a concept of "libraries". They are after all just contracts, with the only difference being that they are intended to be called by other contracts instead of humans.
I see the next controversial, but eventually Vitalik-blessed hard fork incoming...
> A library apparently can be nuked because Ethereum does not explicitly have a concept of "libraries". They are after all just contracts, with the only difference being that they are intended to be called by other contracts instead of humans.
That's not correct. There is a construct "library" that is different from a normal contract. But the code in question didn't use that (for whatever reason).
> I see the next controversial, but eventually Vitalik-blessed hard fork incoming...
I wouldn't be so sure.
It's only about 1% of all ETH and the funds are frozen. The DAO hack was ~15% and would have put those funds into the hand of a single entity which would endangered the eventual move to PoS.
> That's not correct. There is a construct "library" that is different from a normal contract. But the code in question didn't use that (for whatever reason).
Thanks for pointing me to this! Didn't know that yet...but in that case I'm really wondering why this strange "library" from Parity even worked the way it did...? If it's necessary to use the library construct in order to have the code not access its own contracts' data storage and funds, but those of the calling contract (this is at least how I understand the description you linked to), how could the Parity library even work the way it did without this construct?
You can always call public methods from other contracts regardless what construct you use. The library construct is a Solidity implementation detail but you can also use normal contracts, like they did in this case.
So far, it really looks like almost a criminal sloppy refactoring of the official multi sig contract from the EF that has been extensively audited.
As far as I know, Solidity "library" is practically just syntax-sugar for exactly what Parity's wallet was doing already. It wouldn't have prevented the library-contract from suiciding.
If they used a library instead of a contract, this wouldn't have been possible. I hope they had a reason to use a contract otherwise they clearly have noone else to blame this time.
Not to mention that he wrote the buggy contract...ehm, both buggy contracts, to be precise, the one that let funds be stolen and the one that now freezes funds...
>If they used a library instead of a contract, this wouldn't have been possible.
It's actually the opposite, using a library allowed this to break all the wallets using it. However, an Ethereum "library" isn't what you'd expect a software "library" to be - it's an executable contract that just is never supposed to be executed directly. But oops, nothing prevented that from happening.
The concept of everyone using a common, well-audited contract makes sense though. Virtually all Bitcoin multisignature transactions use the same script construction and it has never been hacked, despite being much older.
For something as important as contract code, there should still have been more failsafes. Even just having a kill() on the main contract that doesn't delegate out to the library would have protected against this.
> The concept of everyone using a common, well-audited contract makes sense though.
Just Parity's contract was neither common nor well audited.
> Virtually all Bitcoin multisignature transactions use the same script construction and it has never been hacked, despite being much older.
The only multi-sig issue that I'm aware of in Bitcoin was the Bitfinex hack but I don't know in what relation BitGo's multi-sig implementation is to the standard multi-sig.
The EF multi-sig implementation has been audited and AFAIK there has also never been an issue with it.
The Bitfinex hack was due to getting enough parties of the multiparty signature to sign it (e.g. by stealing 2 out of 3 keys, or taking advantage of insufficiently secure automatic signing systems), not an issue with the contract itself.
Can someone break down how funds have been frozen and what the bug that's being exploited is for those less familiar with Ethereum?
From what I've read about Ethereum's contract language, it doesn't make itself easy to statically verify properties you want to check so I don't see how problems like this are going to go away until another language is used.
The parity wallet uses a "shared library" in which the actual logic is implemented. All individual wallets have their own data storages and coin balances, but contain just a little bit of logic code that redirects calls to this shared codebase.
This shared library itself is also just a contract, except that it's intended to be called internally by other contracts (the different wallets). Though it typically doesn't happen, it can be called directly by humans. This is what the makers of this "shared library" apparently forgot to consider, until somebody called the "initialization function" of the shared library directly.
By doing this, the shared library initialized itself as if it was one of the individual wallets that normally call the library. It therefore used its own (previously unused) data store, in which it correctly entered the caller of the init function as owner.
This wasn't of use for anything, as there are no ethers at all on the shared library, so the owner could not steal any funds. But being the owner, he was able to trigger the kill switch! Since this particular "multisig wallet" was actually not a wallet, but the shared library, killing it not only killed the (empty) wallet, but also the core functionality of all the real wallets that contain real money out there! And of course that functionality is mandatory to work with the funds of these wallets. Without it, the money cannot be moved anywhere.
Now comes the fun part: suiciding a contract normally transfers all ethers on that contract to the caller of the suicide function. Knowing this, you could expect that the individual wallet owners could just as easily suicide their now "brain-dead" multisig wallets as well, thereby recovering their funds...but that doesn't work, as performing the suicide requires a call to the shared library to check whether the callers' signatures qualify the caller to perform that suicide ;-)
Awesome, thanks for the breakdown! So this is like a function being "public" when it should have been "private"? Would this be helped by making all functions more restrictive by default? What else would help? You'd think code that could change the owner would be heavily audited as well.
This sounds really similar to the big Ethereum wallet hack from earlier this year.
No, this function (the init function) was public for a reason - it must be callable by anyone, since it's the thing you call when you want to create a new wallet! And the kill functionality has been non-public, it required the caller to be the wallet owner - which the guy who triggered all of this unfortunately was, due to him being the first who initialized the "shared library" as a wallet.
I would say there are many ways to look at this with regard of "what went wrong":
- You could say that it's a very, very bad idea to share ANY code between individual wallets which - from a functional standpoint - should not have any intersections between them whatsoever (except of using the same blockchain of course). Individual wallets are DESIGNED to fully isolate the contained tokens and state from each other, so why not also fully isolate their code by duplicating it? Is saving a bit of gas on wallet creation actually worth the additional complexity that comes with code sharing? Seems like someone took the "DRY" principle to a very unhealthy extreme here.
- Apparently the explicit construct of libraries described here (http://solidity.readthedocs.io/en/develop/contracts.html#lib...) is not very well-known in the Ethereum community. I did not know about it (someone here on HN pointed me to it), and while this is understandable considering that I have just a tiny stake in ETH and don't write Ethereum contracts for a living, the fact that Gavin Wood - co-creator of Ethereum - did apparently also not know about it (or for some reason decided not to use it for this library, which would be equally concerning, because if it's not usable for a textbook example like this, it must be seriously flawed) should cause a bit of head-shrugging. Because according to the docs, this construct delivers a crucial limitation with which this entire drama would have been impossible: libraries don't need their own state! So it's just consequential to not allow them to have any state (like an owner, or ETH funds), which apparently is exactly what the library construct does.
- Maybe this incident is just another bit of proof to the theory that the combination of immutability, handling of huge monetary values without any human oversight at all, and the idea of a Turing-complete language just don't mingle together very well. If you're not able to manually interfere in case stuff goes wrong in a way you didn't anticipate, you need to be able to basically anticipate absolutely all ways in which stuff can go wrong beforehand. A Turing-complete language seriously complicates doing this, possibly to an extent that kicks the entire concept beyond the realm of practicability. If this turns out to be true, the entire value proposition of Ethereum would be void right from the beginning.
Everything in the "library" was "OK" the problem was that the person who deployed the contract to the main network forgot to call the constructor function.
The guy who killed the contract was the first one to initiate the contract.
My wife once left the car running and went to buy gum in a drug store, the car wasn't their when she got back.
Shit happens I guess.
Didn't they fuck it up by creating a real contract instead of a library (where you can only do delegatecalls)? And having an init function that was not the constructor as well?
Solidity is, I think, the fourth high-level language created for Ethereum. This is not a problem that it is going to be fixed with just yet another language: if Ethereum is going to live up to the expectations for it, it will require formal verification at a scale never before done, both in terms of the languages and other tools needed, and in terms of the skills needed to produce verified contract code.
Depending on who you read, the expectations for Ethereum go all the way up to replacing banking systems, if not beyond, so there does not need to be any problem specific to Ethereum for there to be concerns about the practicality of its verification, though the fact that it is not a well-defined problem domain is itself an issue. Do you have a more restricted expectation of Ethereum's usefulness that implies no more difficulty than the largest formally-verified project that you are aware of? Update: the lower reasonable bound on Ethereum's complexity / usefulness is that it should enable something useful beyond what can be done with Bitcoin, or any other blockchain-based system lacking Turing-complete contracts.
Why would how useful Ethereum is or could be make a difference? Formal verification has been researched for decades and applied to complex domains like operating systems, hardware, smartcards and huge mathematical proofs already. I don't see why applying it to Ethereum would be a giant leap.
We may have a misunderstanding about formality here. While the mere use of defined software development processes has sometimes informally (and confusingly) been called formal, it really isn't. True formal methods involve developing proofs of correctness along with programs, or at least proofs of the absence of certain types of error.
Work on this has indeed been going on for decades, and its very limited adoption so far is a testament to its difficulty. Only a tiny fraction of the code in the domains you mention is formally verified, and I notice that banking and finance are not on your list. The answer to "why would how useful Ethereum is or could be make a difference?" is that if Ethereum becomes as useful and important as intended, the size and scope of the problem will be well beyond anything that has been achieved so far. Arguably, given the value at risk, it has already crossed that threshold by a wide margin.
There are, however, people working on it, such as at Cardano [1], which is an exciting development. Ultimately, I think it will be more successful than trying to fix Ethereum.
If you don't have experience writing formally-verified code, I suggest the F* tutorial [2].
I don't think it will require formal verification per se.
Rather, formal verification is just one piece in the puzzle. The software responsible for contracts in Ethereum needs to be equally well and thoroughly developed as if it was sending people to the Moon in the 60s or to Mars in the current Decade.
It'll probably take blood, sweat, money and mistakes just like in many other disciplines but we'll get there.
Solidity is garbage. There is a ton of space for improvement between Solidity and even a solid programming language, let alone a formally verified system.
AFAIK hardforks are hard to detect by a contract, the contracts don't know anything outside the chain, if you split the chain, you can't tell there is another.
Of course I've briefly entertained the idea but on the other hand, a bet between two mostly-honest individuals doesn't need a blockchain contract, similar to how I don't need a blockchain contract to borrow money from my sister and pay it back later.
In any case, if there would be a hardfork, it would include the replay protection, so a simple but working solution would be to prepare a transaction for the fork chain and one for the non-fork chain, the participants can then publish the transactions once either chain becomes available and claim the reward.
It wouldn't be that hard in this case. You just have to watch for an address holding stuck ethers because of the bug, if the ethers move, it is a proof that a fork has happened.
FYI this is not the reason Ethereum failed as a blockchain. Security bugs are bad, but what's worse is 9GB/week bandwidth requirement = 3 hours sync on average world connection, if you're lucky.
No idea why everyone ignores this metric. And that's why Bitcoin is still somewhat blockchain (also poor sync, but doable)
9GB/week is not huge at all, and ethereum nodes are not designed to be run on "average world connection". The only people running full nodes realistically should be on extremely fast connections.
Bandwidth and storage are only getting cheaper
Also "Ethereum failed as a blockchain"? They're the 2nd largest coin after bitcoin, it can hardly be called failed
You may have a point about the space but don't resort to insults like the last sentence. I think you also have a lot to prove when saying Ethereum has failed v Bitcoin.
3 hours of sync per week is not as bad as you might think. A week has 168 hours, which means you'll spend a minute per hour syncing on average.
Additionally, Ethereum, unlike Bitcoin, does not want everyone to run a full node, you can certainly run Archival nodes, but most people should be using light clients or nodes which do not store the full history of the chain (only recent history)
> A week has 168 hours, which means you'll spend a minute per hour syncing on average.
Assuming, the user wants to have a daemon running full time. They just downloaded your thing and you're imposing your rules? Deleted.
> Additionally, Ethereum, unlike Bitcoin, does not want everyone to run a full node
To me a full node is the one that verified every single block since the install point. (Not from genesis, a snapshot is fine). I'm strongly against archiving the blocks for normal users, only the state should be stored.
Certificate validation don't involve UX friction. I need this friction to be justified, and it the sync is very slow new comers will never bother to be a full node. Give people instant sync, and they won't consider light wallets anymore = greater overall security, ready for any censorship.
That's like counting a mentions in Google Trends. Number of non-mining nodes is quite irrelevant to security or usability of the network. People install it to play around somewhere in the cloud.
It is not 9GB/week. The 9 GB is the tx data plus the state at every block. You don't need the copy of the state at every block. The latest state is perfectly sufficient. More indepth explanation:
You seem to be right! That doesn't dramatically change the problem, but with avg blocksize 13Kb https://etherscan.io/chart/blocksize multiply 6000 blocks per day the data to download per week is just 700Mb, am I right? I wonder why the wallet syncs so slowly then.
Eventually other solutions will be needed, like sharding. One solution for the never ending growth of spent transaction and block header data is snapshots. Practically, you can safely not validate tx data older than X, if X is a sufficient length of time.
A solution for neverending state size growth is storage rent with pruning of entries that default on rent payment.
Isn't sharding major compromise on security? I thought snapshots mean you just download the exact state at block X and never bother about tx older than X. And you do that not because of time, but because at the point of installing of blockchains you already trust _someone_ with node software, so you should also trust with latest state (and treat it just like genesis block).
Speaking of storage tax, Ethereum should have implemented one like yesterday.
Apologies, I misread what you wrote. I thought it was 6,000 blocks a week. I also misread that as 13 KB per block header, though that mistake didn't change the calculation.
If the average block size is 13 KB, then there should be 546 MB added per week (13 KB / block * 6000 blocks / day * 7 days / week).
I don't know enough about sharding to offer an informed opinion on it, though I imagine the security compromises are tolerable.
With regard to a snapshot, yes that is one way they're used. I was suggesting that archival nodes could even rely on snapshots to cap their storage requirements.
It would be perfect to make a snapshot whenever a blockchain to last state is taking over 20% of state size. I.e. with 10 GB state do it every 2Gb (monthly). And IMO it's safe to discard any chain older than 3-6 months because only people who were offline for that long would ever need them (unrealistic)
Isn't it possible to generate a new token that has the same amount of ether lost, and airdrop it to those addresses? That token can be assumed to replace ETH (call it ETH1), and should have the same dollar value in trading markets.
It's probably safe to assume that the title of "most expensive software bug in history" will be held by a cryptocurrency glitch within the next couple years. It's nearing the couple-hundred-million mark of things like Knight Capital or Ariane 5's Flight 501.
So I see this as a growing pain. But this is something that has already been thought of as something that could happen, and there is work looking into how to solve it going back a ways: https://github.com/ethereum/EIPs/issues/156
It looks like if this EIP is implemented in the future, the address that created the original multi-sig wallet contract created after July 20th, would just be sent the ether balance in the wallet. I'm not sure on this, but it seems like, if implemented in the future, an owner of a multi sig wallet that is frozen can call this contract from the same address they created the wallet with and it will retrieve the ether from the address where the contract is now blown away?
Another option would be during the next planned fork (upgrade), to just say, any contract that matches the byte code of the frozen wallet one, just replace the code with this code and move on. Although the first option is MUCH nicer and future proof.
People will write bad code and things like this will happen. I think the more often and earlier on we find these types of flaws and can fix them, the better for the whole ecosystem. It's $300 million today... in 10 years, a mistake like this that hasn't been worked out could cause a shock to the entire world economy. (run on the banks, but there are no banks and everyone's funds are frozen...panic!)
So better now than later!
Holy shit, I just moved my ether off of coinbase on sunday so that it could be more secure and almost chose parity, but went with MyEtherWallet instead. This makes me feel like there is no safe way to store my ether now.
To be clear, neither the regular Parity wallet nor MyEtherWallet are affected here. Also, they don't store your coins, all they can ever do is sign and publish transactions when given access to your private key.
Parity multi-sig wallets are an entirely different beast.
Bit of a confusing naming issue:
Parity wallet: light client software that accesses the blockchain.
Parity multi-sig wallet: a smart contract deployed on the blockchain, with the coins stored within this contract.
Ah okay, thanks for the explanation. I've heard of multi-sig wallets, but wasn't quite sure what they actually do. From what I can tell they are supposed to be more secure, so it is a bit ironic that this is the second time multi-sig wallets have had issues.
It's pretty bad when the type of wallet that is supposed to be more secure has bugs like this multiple times. For reference, this only affects multi-signature wallets, not normal wallets. Very few normal users use multi-signature wallets.
The previous bug with these was very trivial and could have been caught by a unit test or a simple code review, and it resulted in around 9 figures (USD) of Ether being stolen.
This bug looks like it's exactly the same. A very simple bug that could have been caught by a simple test or manual audit, and has resulted in 9 figures USD being locked instead of stolen this time.
As mentioned by others it's possible at some point (not any time soon) that this frozen ETH can be recovered (https://github.com/ethereum/EIPs/issues/156) by adding rules to recover it in the next Ethereum hard fork. Not creating a specific hard fork just for this, but adding it to one that is planned in the future. That might come across as controversial, and cannot be guaranteed though.
For safely storing Ethereum I would advise to keep it out of smart contracts, period. Cold storage and hardware wallets exist, and they are much less likely to have critical bugs related to them than a smart contract is.
There will probably be a hardfork and increased moral hazard for auditing contract code. Why spend money finding bugs if the "immutable" blockchain can be rolled back?
Pact (http://github.com/kadena-io/pact) is a turing-incomplete LISP (no recursion, no lambdas, no unbounded loops ... no macros either ;) ) and built in Haskell. Also has formal verification by directly compiling to SMT-LIB2 (not released yet, but watch a demo! https://youtu.be/l7XuSuEe-Yg?t=22m23s).
Https://cardanohub.org looks promising. Haskell, peer reviewed, formally verified. They're working on the compute layer though, so no smart contracts yet but Philip Wadler (one of the godfathers of haskell) is working on that. It's is promising because they actually hire programming language academics to work on the technology
Does this move the bugs from the implementation language to the language of the verification spec? Or is there a way to express some generic requirements such as "don't strand assets"?
Presumably one would have to first formalize that constraint (taking care, for example, that 'not stranded' is not being satisfied by someone stealing the assets), and then, unless the language makes it impossible, prove that it is not violated anywhere. In Solidity, it is a long deductive chain from the specific bug here to the realization that it could lead to stranding.
I don’t know if probably is the right word. There might be a hard fork there might not. The DAO hack was only three months after the Homestead release. You could credibly say Ethereum was in beta. I think over a year later that’s no longer true.
At the time of the DAO hack there also hadn’t been a public demonstration of the scale and danger of contract hacking. That’s also no longer true.
That said, ETH is an anarchist federation in the end, and the market will decide which reality is most valuable: the one in which the parity hack happened or the one in which it didn’t.
Well, "traditional" law can be changed as well, so I'm not sure why a blockchain should not be able to. Some changes are more controversial than others, but in the end the majority (more or less) decides. Either by vote in congress/senate, or by users picking a particular client/chain.
Ethereum has had one particularly controversial fork, and so did Bitcoin. In both cases, both chains survived, with one significantly more popular than the other (in both hash rate, transactions, and market cap). (Un)fortunately, traditional law in real life does not permit two realities to coexist, so there the analogy falls apart somewhat.
Well, national currencies do get "forked"[1], but this would be like if they did extremely narrow forks to fix problems of someone's own stupidity, and only the stupidity of the most important people.
Like, imagine if twenty members of congress kept their life savings in cash in uninsured briefcases and surprise, those briefcases were stolen. And they responded by passing emergency legislation invalidating the specific serial numbers stolen, and requiring every merchant and bank to screen for those serial numbers (and not those from any other e.g. bank robbery).
I would consider that kind of action to be very delegitimizing to the currency.
[1] I would consider it to be analogous to a fork when they e.g. deprecate an old design or migrate to the Euro.
Once again, this is supposed to be better than, and different from, "traditional" law! It has no purpose if the contracts don't actually do what they say. The whole point is that computers evaluate the contracts and do what they say.
As seanwilson says above, blockchains work by consensus. Leaving aside the "better", that does mean it is different. The instructions are still executed by computers as it was programmed as you say, but if enough users/miners agree this was not the intention of the contract/code, they can fork.
I do think that calling blockchains "immutable" can be confusing to users not familiar with the concept and its nuances. And I personally hold no opinion on whether the currently locked up funds need to be returned to their owner with a fork. There is something to be said for both options, specifically in this case where there the "rightful owner" is clear (like the other cases mentioned in https://github.com/ethereum/EIPs/issues/156 ).
Well blockchains work by consensus is the difference: the rules can only be changed if enough people agree. This sounds better in principle but breaks down using proof of work when a small number of parties control most of the computing power.
Parity appears to have a bug bounty program, but the bounty is only $100. Given that they've now had two bugs that caused 9-figure losses in the past year, this is clearly too low. They need real auditing, and they need to pay the market price for real auditing.
You are right, but unfortunately, the de-facto bug bounty for unethical hackers is way beyond anything that could be offered to well-intentioned researchers. This makes your suggestion of professional auditing the highest priority.
bug bounties don't compete with crime. crime always will pay more.
bug bounties compete among themselves. Honest researchers will be busy finding some mobile game bugs for $700 a pop or improving security at google or yahoo for up to $10k instead of helping your company save from a 9 figure bug because you only offer $100
I wondered why you didn't mention the maximum, and after checking their website found no other figures besides the $100 minimum.
They do state "Rewards over the minimum are at our discretion, but we will pay significantly more for particularly serious issues, i.e. that the identified issue could put a significant number of users at risk of severe damage, monetary or otherwise."
What they consider significant is anyone's guess. Given the stakes, even a 10000% increase would still be underwhelming for a high impact bug.
Being coy about what they will pay is not going to have the desired effect of attracting bug hunters - it's kind of like Dr. Strangelove: "The whole point of the doomsday machine is lost...if you keep it a secret!"
This might sound mean, but I laugh every time I see Ethereum bugs in the headlines. The developers intentionally made their platform analytically intractable, despite knowing the dangers this presents given our long history of vulnerable software.
They then compounded this poor choice with an Ethereum programming language with poor and insecure semantics.
I applaud the ambition behind Ethereum, but not it's technical choices.
This. It reminds me of PHP in many aspects - Solidity is just awful. Like the way the multi-dim arrays' sizes are written in opposite order to the one used when accessing values? Pure genius. </s>
Solidity needs to get rid of features like library and inheritance. If you write an unstoppable contract that is responsible for holding hundreds of millions of dollars, you alone should be responsible for it, and not some library you used.
Better yet, people who have the mindset that it's ok to have these hipster "modular" features that spread out the responsibility (for whose benefit?) should really not be working on such fundamental pieces of technology. If you write software that holds people's money and you fuck up, you and only you are responsible for it.
This is a recurring theme with the Ethereum community where people complain about how there was a bug in the system which resulted in a huge hack and people losing tons of money, and developers say "hey don't blame me I just used some library, it's the library's fault".
Since contracts are immutable, you need modularity to be able to fix bugs like what happened with Parity. The problem is that Solidity libraries are also immutable, which means you can't fix them. The solution is easy: just use contract modules, not libraries.
Having modularity in these things only amplifies the damage when something DOES happen.
I'm not saying it is bad to have a centralized auditing of contracts, but I am saying it's not a good thing to simply import libraries and inherit some other abstract contract you don't fully understand when it comes to irreversible contracts.
This is a new type of problem we as a humanity have never faced before, so we need a different type of solution.
> This is a new type of problem we as a humanity have never faced before, so we need a different type of solution.
Could you elaborate on that? How is it a new problem? I would think it's similar to problems with hardware components or FPGA libraries, but maybe I'm missing something?
Crypto used to be a purely technological problem, which means if you have a secure cryptographic lock in your bank account and someone steals it from the bank, the bank is responsible to get it back to you.
But with cryptocurrencies, it's not just about technology but ties into other issues that normally have been tackled on a social level. So in this case there is no "bank" you can complain to or no one to sue.
Of course, you could say Ethereum as a whole can do a hard fork just for this, but that's another discussion altogether.
When people blamed Ethereum for being the cause of the DAO, the devs said it's not Ethereum's fault but the ones who wrote the DAO, which is technically true, which is why I'm making this point. It's not about technology, it's about responsibility.
Also, a while ago some guy complained about how he lost his money using myetherwallet, and the problem was NOT because of myetherwallet but a library they used. So the guy from myetherwallet told reddit that it's not their fault, which is again technically true, but again fits into what I'm talking about.
Dependency spreads out responsibility, which works out fine for traditional finance because everything is reversible, but not in this new economy.
The whole point of Ethereum is for people to be able to use custom contracts. People would be using Bitcoin if they only wanted to be able to use contracts by the Ethereum -- er, cryptocurrency developers.
Contracts in the real world are written with the understanding that they rest on the shoulders of millions of pages of legislature and legal precedents.
In this case the library was also written by Parity. They were trying to minimize the gas cost of deploying a new wallet, which imho doesn't seem like the best thing to worry about optimizing, for a contract that may hold millions of dollars.
If they don't fork, everyone affected by this will lose all of their ETH.
Many would argue the correct thing to do is to not fork and say that people knew the risks beforehand, etc. But that's what people said last time and they still forked, with no (apparent) severe consequences other than complaining about integrity. Two forks may be harder to justify.
Suddenly lots of people with guns to go get your money back is a very useful feature compared to some cryptographic guarantees that people with guns can't get your money back.
Oh please, consider the freedom of people to lock up their money and not get it back! These men{!} with guns first send a letter to an ETH autonomous corporation, then when it doesn't respond, they threaten it with guns. That's the State.
{!} Thanks to today's progressive reforms the State now also employs women with guns. We should just say people with guns to not be sexist.
A given "ETH autonomous corporation" might not have any controlling entities that are accessible to the wronged State.
Foreign shell companies are already hard enough for most governments to deal with—and that's with trade agreements that enable them to compel disclosure of ownership. DACs are foreign shell companies without a governing state to point guns at.
Sure, if the DAC does business in the US, the US government can shut that business down—much like the US government can shut down a domain name associated with foreign illegal activity. But that doesn't stop the business from operating anywhere else. Nobody has the ability to shut down the whole business.
There is an equivalent with Ethereum. When millions were stollen from the DAO they hard forked the currency to take it back. That's why there is Ethereum and Ethereum Classic. Some people didn't approve of forking to correct a bug in a high profile crypto contract. I've been wary of Ethereum ever since.
There are bound to be many more incidents such as this in various cryptocurrencies. There are now thousands of them. But it would be ignorant to dismiss the technology for a lack of understanding it.
That accomplishes the same thing, but that doesn't make it equivalent in the important senses. That requires everyone to change their core interface with the currency. It's not a trivial thing!
The analog in national currencies would be if everyone had to immediately stop using the old notes and replace them with new ones that a new anti-counterfeit feature. Or migration to the Euro.
When banks are hacked or whatever, they have some kind of insurance that just replaces the money. They don't have to get the rest of the system to update anything.
It's like if you have a bunch of cash, and then you see an ad on TV:
Get your Amazing Super Safe Cash Box today! With loads of advanced features that may or may not be useful in the future! Made by some of the cleverest people in the world!
You decide to store your cash in this amazing device, so of course you do a bit of due diligence on the construction and find that well, while there was a huge catastrophic construction failure causing millions of dollars of loss a few months ago, the new version was quickly released fixing the specific issue... so it should be fine, right? It definitely probably won't set all my cash on fire...
Never mind the lack of independent audits, and the fact that the whole thing is way too complicated for its purpose...
Ethereum's biggest problem, is that it has way too many moving parts, leaving too many points of failure. Even Bitcoin has a lot of moving parts, but Ethereum is a circus in comparison.
The moving parts is kind of the whole point, but yeah.
I hope and predict that these disasters become million dollar lessons on what kinds of autonomous functions you can trust with money, and what "security auditing" actually means, so that in a couple of years, given that the notion of a smart contract is actually useful, people won't put funds into bad, faulty logic.
Mind you, these digital currencies aren't much like a safety-deposit box (i.e. the actual Super Safe Cash Box.) They're more like a bank.
Safety-deposit boxes are dumb stores for objects. They've never been marketed on features; in fact the opposite, they're marketed partially on the idea that nobody can open them but you. Therefore, no services (e.g. automatic transfers) can be built that depend on someone being able to automatically do things to your safety deposit box without you there to watch.
Banks (specifically, checking and savings accounts) are not dumb stores of money. They don't even hold onto your money; they leverage it into investments. Banks have always been built on "loads of advanced features" like compound interest, wire transfers, cheques, etc.—things the bank can do to your money because it is not, in fact, a Super Safe Cash Box. It's a convenient, maybe-safe money-management agent.
Bank accounts are only really trustworthy because of 1. a long track-record, and 2. being insured against losses (in banks' case, by the government.) Those are the same requirements I would put on any digital-currency+contracts system before I considered it trustworthy. Digital-currency+contracts is trying to do banking with banking features, so hold it to the expectations of a bank.
291 comments
[ 2.8 ms ] story [ 84.8 ms ] threadhttps://twitter.com/polkadotnetwork/status/92788076205302170...
edit: they just put out a post to say that not all of their funds were in a Parity multisig wallet:
https://medium.com/web3foundation/web-3-multi-sig-wallet-upd...
A similar recovery already happened once, after somebody exploited a bug in The DAO, resulting in a fork into Ethereum and Ethereum Classic, which rejected changing the rules to bail out bugged but too-big-to-fail smart contracts.
> In May of 2016, a venture capital fund called The DAO built on Ethereum raised around $168 million, with the intention of investing in projects using smart contracts. In the same month a paper was released detailing security vulnerabilities with The DAO that could allow ether to be stolen. In June, 3.6 million Ether (approximately $50 million USD) was taken from accounts in The DAO and moved to another account without the owners' consent, exploiting one of the vulnerabilities that had been raised in May. Members of The DAO and the Ethereum community debated what actions, if any, should occur to resolve the situation. A vote occurred and in July 2016 it was decided to implement a hard fork in the Ethereum code and to move the Ether taken in the exploit to a new smart contract through which it would be restored to the owners from whom it had been taken.
> Ethereum Classic came into existence when some members of the Ethereum community rejected the hard fork on the grounds of "immutability", the principle that the blockchain cannot be changed, and decided to keep using the unforked version of Ethereum.
https://en.wikipedia.org/wiki/Ethereum_Classic
Wait, am I reading this right? All multi-sig wallets are frozen due to this? This is surely concerning, as I've seen others recommend multi-sig wallets as a security best practice.
Can anyone comment on the method in which they might revert this? Would it require a hard fork.. again?
All multi-sig Ethereum wallets created by Parity (or using the Parity contract code).
> Can anyone comment on the method in which they might revert this? Would it require a hard fork.. again?
So far, it doesn't look like you can do anything about it. Of course you can change everything with a hard fork but as this time it doesn't compromise the move to PoS, I don't think a hard fork will be the favored solution.
But this time, there is no deadline, so it can be discussed thoroughly.
Has this extra layer of complexity really been injected just to save some bytes on the blockchain?
> I made myself the owner of "0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4" contract
How is that possible?
AFAIK this feature was introduced to make owners capable of deactivating contracts which contain known security bugs (so at least nobody can accidentially send any more money to those contracts). And because that's the intended purpose, a suicide is non-revokable, so a dead contract remains dead forever.
A library apparently can be nuked because Ethereum does not explicitly have a concept of "libraries". They are after all just contracts, with the only difference being that they are intended to be called by other contracts instead of humans.
I see the next controversial, but eventually Vitalik-blessed hard fork incoming...
That's not correct. There is a construct "library" that is different from a normal contract. But the code in question didn't use that (for whatever reason).
http://solidity.readthedocs.io/en/develop/contracts.html#lib...
> I see the next controversial, but eventually Vitalik-blessed hard fork incoming...
I wouldn't be so sure.
It's only about 1% of all ETH and the funds are frozen. The DAO hack was ~15% and would have put those funds into the hand of a single entity which would endangered the eventual move to PoS.
Thanks for pointing me to this! Didn't know that yet...but in that case I'm really wondering why this strange "library" from Parity even worked the way it did...? If it's necessary to use the library construct in order to have the code not access its own contracts' data storage and funds, but those of the calling contract (this is at least how I understand the description you linked to), how could the Parity library even work the way it did without this construct?
So far, it really looks like almost a criminal sloppy refactoring of the official multi sig contract from the EF that has been extensively audited.
Parity's refactoring of the official audited multi-sig contract code has fucked up again. I wonder if they even audited their code.
The post-mortem of the last incident https://blog.ethcore.io/the-multi-sig-hack-a-postmortem/ evades that question under the paragraph "Was the wallet not audited?".
If they used a library instead of a contract, this wouldn't have been possible. I hope they had a reason to use a contract otherwise they clearly have noone else to blame this time.
It's ethereum, they'll just hardfork those coins back
Apparently almost $300M stuck - I don't see them not bringing up another hard fork to retrieve them
Perhaps it can be fixed though, as part of the next hard fork.
It's actually the opposite, using a library allowed this to break all the wallets using it. However, an Ethereum "library" isn't what you'd expect a software "library" to be - it's an executable contract that just is never supposed to be executed directly. But oops, nothing prevented that from happening.
The concept of everyone using a common, well-audited contract makes sense though. Virtually all Bitcoin multisignature transactions use the same script construction and it has never been hacked, despite being much older.
Just Parity's contract was neither common nor well audited.
> Virtually all Bitcoin multisignature transactions use the same script construction and it has never been hacked, despite being much older.
The only multi-sig issue that I'm aware of in Bitcoin was the Bitfinex hack but I don't know in what relation BitGo's multi-sig implementation is to the standard multi-sig.
The EF multi-sig implementation has been audited and AFAIK there has also never been an issue with it.
From what I've read about Ethereum's contract language, it doesn't make itself easy to statically verify properties you want to check so I don't see how problems like this are going to go away until another language is used.
The parity wallet uses a "shared library" in which the actual logic is implemented. All individual wallets have their own data storages and coin balances, but contain just a little bit of logic code that redirects calls to this shared codebase.
This shared library itself is also just a contract, except that it's intended to be called internally by other contracts (the different wallets). Though it typically doesn't happen, it can be called directly by humans. This is what the makers of this "shared library" apparently forgot to consider, until somebody called the "initialization function" of the shared library directly. By doing this, the shared library initialized itself as if it was one of the individual wallets that normally call the library. It therefore used its own (previously unused) data store, in which it correctly entered the caller of the init function as owner.
This wasn't of use for anything, as there are no ethers at all on the shared library, so the owner could not steal any funds. But being the owner, he was able to trigger the kill switch! Since this particular "multisig wallet" was actually not a wallet, but the shared library, killing it not only killed the (empty) wallet, but also the core functionality of all the real wallets that contain real money out there! And of course that functionality is mandatory to work with the funds of these wallets. Without it, the money cannot be moved anywhere.
Now comes the fun part: suiciding a contract normally transfers all ethers on that contract to the caller of the suicide function. Knowing this, you could expect that the individual wallet owners could just as easily suicide their now "brain-dead" multisig wallets as well, thereby recovering their funds...but that doesn't work, as performing the suicide requires a call to the shared library to check whether the callers' signatures qualify the caller to perform that suicide ;-)
This sounds really similar to the big Ethereum wallet hack from earlier this year.
I would say there are many ways to look at this with regard of "what went wrong":
- You could say that it's a very, very bad idea to share ANY code between individual wallets which - from a functional standpoint - should not have any intersections between them whatsoever (except of using the same blockchain of course). Individual wallets are DESIGNED to fully isolate the contained tokens and state from each other, so why not also fully isolate their code by duplicating it? Is saving a bit of gas on wallet creation actually worth the additional complexity that comes with code sharing? Seems like someone took the "DRY" principle to a very unhealthy extreme here.
- Apparently the explicit construct of libraries described here (http://solidity.readthedocs.io/en/develop/contracts.html#lib...) is not very well-known in the Ethereum community. I did not know about it (someone here on HN pointed me to it), and while this is understandable considering that I have just a tiny stake in ETH and don't write Ethereum contracts for a living, the fact that Gavin Wood - co-creator of Ethereum - did apparently also not know about it (or for some reason decided not to use it for this library, which would be equally concerning, because if it's not usable for a textbook example like this, it must be seriously flawed) should cause a bit of head-shrugging. Because according to the docs, this construct delivers a crucial limitation with which this entire drama would have been impossible: libraries don't need their own state! So it's just consequential to not allow them to have any state (like an owner, or ETH funds), which apparently is exactly what the library construct does.
- Maybe this incident is just another bit of proof to the theory that the combination of immutability, handling of huge monetary values without any human oversight at all, and the idea of a Turing-complete language just don't mingle together very well. If you're not able to manually interfere in case stuff goes wrong in a way you didn't anticipate, you need to be able to basically anticipate absolutely all ways in which stuff can go wrong beforehand. A Turing-complete language seriously complicates doing this, possibly to an extent that kicks the entire concept beyond the realm of practicability. If this turns out to be true, the entire value proposition of Ethereum would be void right from the beginning.
My wife once left the car running and went to buy gum in a drug store, the car wasn't their when she got back. Shit happens I guess.
https://www.reddit.com/r/ethereum/comments/7bem7v/solidity_l...
What problems specific to Ethereum do you see? Formal verification has been applied to complex domains and large projects before.
Work on this has indeed been going on for decades, and its very limited adoption so far is a testament to its difficulty. Only a tiny fraction of the code in the domains you mention is formally verified, and I notice that banking and finance are not on your list. The answer to "why would how useful Ethereum is or could be make a difference?" is that if Ethereum becomes as useful and important as intended, the size and scope of the problem will be well beyond anything that has been achieved so far. Arguably, given the value at risk, it has already crossed that threshold by a wide margin.
There are, however, people working on it, such as at Cardano [1], which is an exciting development. Ultimately, I think it will be more successful than trying to fix Ethereum.
If you don't have experience writing formally-verified code, I suggest the F* tutorial [2].
[1] https://www.cardanohub.org/en/home/
[2] https://www.fstar-lang.org/tutorial/
Rather, formal verification is just one piece in the puzzle. The software responsible for contracts in Ethereum needs to be equally well and thoroughly developed as if it was sending people to the Moon in the 60s or to Mars in the current Decade.
It'll probably take blood, sweat, money and mistakes just like in many other disciplines but we'll get there.
Are these guys ever going to learn?
Of course I've briefly entertained the idea but on the other hand, a bet between two mostly-honest individuals doesn't need a blockchain contract, similar to how I don't need a blockchain contract to borrow money from my sister and pay it back later.
In any case, if there would be a hardfork, it would include the replay protection, so a simple but working solution would be to prepare a transaction for the fork chain and one for the non-fork chain, the participants can then publish the transactions once either chain becomes available and claim the reward.
An example betting contract for anyone interested (note it was eventually refunded and not run):
https://etherscan.io/address/0xf4b8ccc5734ed7d2d8beb5fddd223...
And an overview with some reasonable criticism:
https://www.reddit.com/r/ethdev/comments/6sd8hl/mayweather_v...
No idea why everyone ignores this metric. And that's why Bitcoin is still somewhat blockchain (also poor sync, but doable)
https://medium.com/@homakov/weekly-sync-friction-the-most-im...
Bandwidth and storage are only getting cheaper
Also "Ethereum failed as a blockchain"? They're the 2nd largest coin after bitcoin, it can hardly be called failed
It's a lot on average.
https://medium.com/@homakov/weekly-sync-friction-the-most-im...
>They're the 2nd largest coin after bitcoin, it can hardly be called failed
"caps" are short term hypes, they are not definition of blockchain. Say, Ripple is not a blockchain at all. Try critical thinking, highly recommended.
This seems unnecessarily combative.
Additionally, Ethereum, unlike Bitcoin, does not want everyone to run a full node, you can certainly run Archival nodes, but most people should be using light clients or nodes which do not store the full history of the chain (only recent history)
Assuming, the user wants to have a daemon running full time. They just downloaded your thing and you're imposing your rules? Deleted.
> Additionally, Ethereum, unlike Bitcoin, does not want everyone to run a full node
To me a full node is the one that verified every single block since the install point. (Not from genesis, a snapshot is fine). I'm strongly against archiving the blocks for normal users, only the state should be stored.
When you run software you kinda accept that this software imposes rules on you.
Or do you delete Firefox or Chrome because they enforce Certificate Validation on HTTPS with HSTS?
https://www.reddit.com/r/ethereum/comments/6zcoja/10_gb_in_2...
Shouldn't believe random charts on the internet!
Eventually other solutions will be needed, like sharding. One solution for the never ending growth of spent transaction and block header data is snapshots. Practically, you can safely not validate tx data older than X, if X is a sufficient length of time.
A solution for neverending state size growth is storage rent with pruning of entries that default on rent payment.
Isn't sharding major compromise on security? I thought snapshots mean you just download the exact state at block X and never bother about tx older than X. And you do that not because of time, but because at the point of installing of blockchains you already trust _someone_ with node software, so you should also trust with latest state (and treat it just like genesis block).
Speaking of storage tax, Ethereum should have implemented one like yesterday.
If the average block size is 13 KB, then there should be 546 MB added per week (13 KB / block * 6000 blocks / day * 7 days / week).
I don't know enough about sharding to offer an informed opinion on it, though I imagine the security compromises are tolerable.
With regard to a snapshot, yes that is one way they're used. I was suggesting that archival nodes could even rely on snapshots to cap their storage requirements.
I love this feeling of living on the edge when I know that I just evaded a critical bug that could have cost me a lot of money.
Though, a lot of people who aren't me will be a lot more angry, especially (and probably only) people actively using the multisig.
It looks like if this EIP is implemented in the future, the address that created the original multi-sig wallet contract created after July 20th, would just be sent the ether balance in the wallet. I'm not sure on this, but it seems like, if implemented in the future, an owner of a multi sig wallet that is frozen can call this contract from the same address they created the wallet with and it will retrieve the ether from the address where the contract is now blown away?
Another option would be during the next planned fork (upgrade), to just say, any contract that matches the byte code of the frozen wallet one, just replace the code with this code and move on. Although the first option is MUCH nicer and future proof.
People will write bad code and things like this will happen. I think the more often and earlier on we find these types of flaws and can fix them, the better for the whole ecosystem. It's $300 million today... in 10 years, a mistake like this that hasn't been worked out could cause a shock to the entire world economy. (run on the banks, but there are no banks and everyone's funds are frozen...panic!) So better now than later!
Have you lost faith in the Pound yet?
Parity multi-sig wallets are an entirely different beast.
Bit of a confusing naming issue:
Parity wallet: light client software that accesses the blockchain.
Parity multi-sig wallet: a smart contract deployed on the blockchain, with the coins stored within this contract.
The latter is what was affected.
The previous bug with these was very trivial and could have been caught by a unit test or a simple code review, and it resulted in around 9 figures (USD) of Ether being stolen.
This bug looks like it's exactly the same. A very simple bug that could have been caught by a simple test or manual audit, and has resulted in 9 figures USD being locked instead of stolen this time.
As mentioned by others it's possible at some point (not any time soon) that this frozen ETH can be recovered (https://github.com/ethereum/EIPs/issues/156) by adding rules to recover it in the next Ethereum hard fork. Not creating a specific hard fork just for this, but adding it to one that is planned in the future. That might come across as controversial, and cannot be guaranteed though.
For safely storing Ethereum I would advise to keep it out of smart contracts, period. Cold storage and hardware wallets exist, and they are much less likely to have critical bugs related to them than a smart contract is.
“Code is Law” fails again.
There will probably be a hardfork and increased moral hazard for auditing contract code. Why spend money finding bugs if the "immutable" blockchain can be rolled back?
https://github.com/pirapira/bamboo
The Bamboo manifest:
https://github.com/pirapira/bamboo/blob/master/doc/manifest....
There is a project under way to formalize Viper, which is the other newly developed programming language for Ethereum, as well:
https://runtimeverification.com/blog/?p=411
At the time of the DAO hack there also hadn’t been a public demonstration of the scale and danger of contract hacking. That’s also no longer true.
That said, ETH is an anarchist federation in the end, and the market will decide which reality is most valuable: the one in which the parity hack happened or the one in which it didn’t.
Ethereum has had one particularly controversial fork, and so did Bitcoin. In both cases, both chains survived, with one significantly more popular than the other (in both hash rate, transactions, and market cap). (Un)fortunately, traditional law in real life does not permit two realities to coexist, so there the analogy falls apart somewhat.
Like, imagine if twenty members of congress kept their life savings in cash in uninsured briefcases and surprise, those briefcases were stolen. And they responded by passing emergency legislation invalidating the specific serial numbers stolen, and requiring every merchant and bank to screen for those serial numbers (and not those from any other e.g. bank robbery).
I would consider that kind of action to be very delegitimizing to the currency.
[1] I would consider it to be analogous to a fork when they e.g. deprecate an old design or migrate to the Euro.
I do think that calling blockchains "immutable" can be confusing to users not familiar with the concept and its nuances. And I personally hold no opinion on whether the currently locked up funds need to be returned to their owner with a fork. There is something to be said for both options, specifically in this case where there the "rightful owner" is clear (like the other cases mentioned in https://github.com/ethereum/EIPs/issues/156 ).
As I think I saw both "alive" yesterday.
> Parity's goal is to be the fastest, lightest, and most secure Ethereum client.
with all the recent past in mind, makes it sound pathetic. I'll continue to use geth, although it didn't board the cool-kids-Rust-train.
Every time I read opinions like this, it's mostly by people not using Ethereum.
> For safely storing Ethereum I would advise to keep it out of smart contracts, period
This is what I don't understand. Why would anyone use these things?
bug bounties compete among themselves. Honest researchers will be busy finding some mobile game bugs for $700 a pop or improving security at google or yahoo for up to $10k instead of helping your company save from a 9 figure bug because you only offer $100
This is the minimal bounty.
They do state "Rewards over the minimum are at our discretion, but we will pay significantly more for particularly serious issues, i.e. that the identified issue could put a significant number of users at risk of severe damage, monetary or otherwise."
What they consider significant is anyone's guess. Given the stakes, even a 10000% increase would still be underwhelming for a high impact bug.
Bullet #1: Prepare for failure
They then compounded this poor choice with an Ethereum programming language with poor and insecure semantics.
I applaud the ambition behind Ethereum, but not it's technical choices.
Better yet, people who have the mindset that it's ok to have these hipster "modular" features that spread out the responsibility (for whose benefit?) should really not be working on such fundamental pieces of technology. If you write software that holds people's money and you fuck up, you and only you are responsible for it.
This is a recurring theme with the Ethereum community where people complain about how there was a bug in the system which resulted in a huge hack and people losing tons of money, and developers say "hey don't blame me I just used some library, it's the library's fault".
Having modularity in these things only amplifies the damage when something DOES happen.
I'm not saying it is bad to have a centralized auditing of contracts, but I am saying it's not a good thing to simply import libraries and inherit some other abstract contract you don't fully understand when it comes to irreversible contracts.
This is a new type of problem we as a humanity have never faced before, so we need a different type of solution.
Could you elaborate on that? How is it a new problem? I would think it's similar to problems with hardware components or FPGA libraries, but maybe I'm missing something?
But with cryptocurrencies, it's not just about technology but ties into other issues that normally have been tackled on a social level. So in this case there is no "bank" you can complain to or no one to sue.
Of course, you could say Ethereum as a whole can do a hard fork just for this, but that's another discussion altogether.
Who really says that?
Also, a while ago some guy complained about how he lost his money using myetherwallet, and the problem was NOT because of myetherwallet but a library they used. So the guy from myetherwallet told reddit that it's not their fault, which is again technically true, but again fits into what I'm talking about.
Dependency spreads out responsibility, which works out fine for traditional finance because everything is reversible, but not in this new economy.
For the most part, they work just fine.
The language used is unsafe, and developers didn't test properly.
What can be done? Fork I guess.
Or maybe leave the developers developing on the Ethereum platform to just fail?
It's just funny how decentralized currency is so easily swayed by a few individuals to serve their purpose.
Many would argue the correct thing to do is to not fork and say that people knew the risks beforehand, etc. But that's what people said last time and they still forked, with no (apparent) severe consequences other than complaining about integrity. Two forks may be harder to justify.
{!} Thanks to today's progressive reforms the State now also employs women with guns. We should just say people with guns to not be sexist.
Foreign shell companies are already hard enough for most governments to deal with—and that's with trade agreements that enable them to compel disclosure of ownership. DACs are foreign shell companies without a governing state to point guns at.
Sure, if the DAC does business in the US, the US government can shut that business down—much like the US government can shut down a domain name associated with foreign illegal activity. But that doesn't stop the business from operating anywhere else. Nobody has the ability to shut down the whole business.
There are bound to be many more incidents such as this in various cryptocurrencies. There are now thousands of them. But it would be ignorant to dismiss the technology for a lack of understanding it.
The analog in national currencies would be if everyone had to immediately stop using the old notes and replace them with new ones that a new anti-counterfeit feature. Or migration to the Euro.
When banks are hacked or whatever, they have some kind of insurance that just replaces the money. They don't have to get the rest of the system to update anything.
Get your Amazing Super Safe Cash Box today! With loads of advanced features that may or may not be useful in the future! Made by some of the cleverest people in the world!
You decide to store your cash in this amazing device, so of course you do a bit of due diligence on the construction and find that well, while there was a huge catastrophic construction failure causing millions of dollars of loss a few months ago, the new version was quickly released fixing the specific issue... so it should be fine, right? It definitely probably won't set all my cash on fire...
Never mind the lack of independent audits, and the fact that the whole thing is way too complicated for its purpose...
I hope and predict that these disasters become million dollar lessons on what kinds of autonomous functions you can trust with money, and what "security auditing" actually means, so that in a couple of years, given that the notion of a smart contract is actually useful, people won't put funds into bad, faulty logic.
Safety-deposit boxes are dumb stores for objects. They've never been marketed on features; in fact the opposite, they're marketed partially on the idea that nobody can open them but you. Therefore, no services (e.g. automatic transfers) can be built that depend on someone being able to automatically do things to your safety deposit box without you there to watch.
Banks (specifically, checking and savings accounts) are not dumb stores of money. They don't even hold onto your money; they leverage it into investments. Banks have always been built on "loads of advanced features" like compound interest, wire transfers, cheques, etc.—things the bank can do to your money because it is not, in fact, a Super Safe Cash Box. It's a convenient, maybe-safe money-management agent.
Bank accounts are only really trustworthy because of 1. a long track-record, and 2. being insured against losses (in banks' case, by the government.) Those are the same requirements I would put on any digital-currency+contracts system before I considered it trustworthy. Digital-currency+contracts is trying to do banking with banking features, so hold it to the expectations of a bank.