I'm pretty sure a hard fork can undo anything on the block chain. You can start over from the block before the hack. There's probably a cleaner solution than that though.
I don't think that's correct. If you only revert the stolen money transactions and all the branches of them since, almost nobody loses. The few stolen ETH that got sold will be a loss, but it's nothing compared to $35M.
It's a hard fork. The contract would be fixed. But you could also send the victim's money anywhere, just ask the victim where they want it, there are only 3 major ones.
Piecing together the comments up thread: there was apparently a unique twist to the infamous DAO hard-fork which allowed someone to steal the funds but not withdraw them (ie, transfer them to an exchange and get dollars out), so they were able to undo the transaction.
There was no such twist this time around which means the funds could already have been transferred to an exchange and withdrawn as dollars or BTC. You can only undo the ETH part of the transaction, which would take money away from the exchange (or from people who have since bought the stolen coins from the exchange unknowningly) and give it back to the victim. That's a lot less palatable than taking the money from the thief, so it's unlikely to happen.
I know this is a joke, but what would prevent the thief from attaching high transaction costs to the withdrawal of ETH from the target wallets? Say they place 50% of the value into the transaction costs - miners would assume a healthy profit off of the theft and it wouldn't be beneficial for them to rollback the chain.
Takes longer for such a change to propagate than for the miner to just move his coins. Unless you implement it as some kind of history tracking for wallets, but then the hacker can just send a tiny transaction to literlaly every wallet around, and everone's paying the 50% cost.
A hypothetical hacker could robin hood easily then.. only steal coins from wallets with massive amounts, and "give them away" to miners via transaction costs
A hard fork couldn't undo the damage if everybody wanted to. The exploiter/hacker/scammer, whatever you want to label them, can move ETH into other coins on exchanges immediately. This will cause an innocent party to buy them, removing any chance of reversal affecting the person[s] responsible.
During the DAO hack, the funds were prevented from moving anywhere so a hard fork caused a direct reversal.
Eth is worth less right now, as there is an implicit chance that all transactions will be rolled back to a few hours ago. Hence any buyer of ETH will be getting a fair price for the risk. Wild west all round.
None of that is true at all. Rolling it back would do nothing for anybody affected, so there's no way a consensus would form. That and a majority of the hacked accounts were prevented loss by whitehats as things look now.
There was a faulty contract in Parity's multi-sig wallet, which is more like a vault than a typical wallet.
The page linked to here is the blockchain address of whoever exploited that fault and was able to take control of a large number of wallets and forward all of the ETH to their account.
They've sold ~20 ETH so far (~4100 USD), and have ~150,000 sitting at that address still.
Not really true. Nothing has to be perfect if there is insurance infrastructure. People should not use contracts they have no reason to trust.
As a contract becomes more important it should be viewed/vetted/trusted by as many entities as possible. Users of the contract should pay an insurance fee that goes to the vetters, who promise to reimburse in case of unpredictable behavior.
Yes, this means applying some meatspace solutions to Ether. However the smart contract infrastructure itself is ideal for implementing this. Ethereum offers immutability, and blockchains can foster new kinds of trust, but trust still has to grow organically in the ecosystem.
The blockchain offers characteristics (immutability, consensus, distributed backup) that allows entities to trust each other efficiently.
But when you introduce a non-trivial smart contract, there is a chance that it (a black box) has behavior that is not obvious from its source code.
Since the behavior of the contract will cause immutable changes to the blockchain, and since humans can't perfectly mentally model all conceivable source code behaviors and interactions, there must be some other mechanism for establishing that the behavior of the contract matches the common understanding of what the contract does.
This could be sandbox testing, parameter range verification, formal verification, star ratings, etc. As the would-be user of a contract I generally want some reason to trust it.
Ethereum offers the building blocks to create an elaborate vetting, verification, simulation, etc. system. Thusfar, existing institutions have leveraged their own reputations to make users of Ethereum comfortable trusting their contracts. The DAO is an example of the folly of this, but many other contracts are examples of the reasonableness of it.
Over time, Ethereum will build the right meta building blocks to create very rich trust mechanisms which put the meatspace hedging/insurance industry to shame while also shedding much of the inefficiency that ambiguous legal enforcement creates.
- enforceability. If your neighbor borrows your car and agrees to pay you $20 but never does, you are screwed. With Ethereum the smart contract could lock the door to the car until funds are received. Verbal contracts for low-priced transactions are rarely enforced.
I had a landlord who simply decided not to return my deposit, so I was out $5K. He stole the money simply because I didn't have time to fly back to that city and proceed with small claims court. With Ethereum, there could be an unbiased oracle that verifies the state of an apartment at end-of-lease and allows a contract to refund the deposit as agreed. The oracle could stop by for 15 minutes on move-in day and snap some pictures, then stop by on move-out day and verify the condition and deduct any money from the deposit as previously agreed. Also the contract could enforce that the money was held in escrow as required by law.
- regulatory risk. In some cases, regulators use their aesthetic to determine that some legal contracts are (in hindsight) bad, and they wipe them out. This drastically limits the usefulness of contracts as a planning mechanism and is essentially a tax (in the form of uncertainty) on all contracts. It's like having a buggy VM that does things arbitrarily differently now and then.
- higher confidence in the outcome of a contract. With paper meatspace contracts, the language is hard to understand and is pieced together from legal boilerplate based on court decisions where the court interpreted a sentence to mean something precise, etc. This makes these contracts difficult for a layperson to understand even though they are written in English. When you sign a contract you don't know how many times it has been reviewed by a court and whether the court found any of it to be unenforceable or to otherwise mean something different from what you think it means when you sign it.
We are always signing TOS agreements, license agreements, leases, waivers, etc. etc. Most of these are virgin legal territory, untested in the court system and designed by lawyers to be overly aggressive in favor of the entity the consumer is doing a transaction with. While it's great that all these contracts might one day be reviewed by a court if the stakes get high enough, a much better approach would be to have very simple, easily enforceable terms. How many unique smart contracts for doing insurance does the world need? Probably about as many as it needs AES implementations. Code that matters would be reviewed with far more scrutiny than most verbal contracts ever get, and composing contracts would also be far easier with well-defined, vetted behavior.
Proof of work allows participants to trust the ledger in a way that is enforced by cryptography, not by law. This creates a powerful deterrent for certain kinds of fraud and abuse.
I agree that waste-heat-generating proof of work is inefficient, but that does not mean that no proof of work system exists where the work itself has some positive externalities.
It's about the structuring of the trust. I trust that someone from the hospital will triage me when I get to the emergency room, but that kind of trust is very different than if there is an online service which does remote triaging when I am on my way to the hospital.
When the proponents of this service are claiming that you don't have to trust the hospital that they would get someone to triage you, instead you can have your own assigned triage Nurse, you're claiming "But you still have to trust that this third party agency will have someone on the remote location to triage you, then what's the point of using this service?"
> Not really true. Nothing has to be perfect if there is insurance infrastructure.
Why not just use a traditional financial institution then? What's the benefit of the complexity of a blockchain if it's still unreliable without the added meatspace complexity of a bank?
> Why not just use a traditional financial institution then?
Insurance via smart contracts is still far simpler and more efficient to implement than in meatspace.
Consider things like insurer solvency risk and the way that meatspace regulations make that hard to understand. With cryptocurrencies an insurer can easily offer proof of solvency based on all outstanding risks.
Insurance emerges as a fundamental economic behavior when you have investment and you have an uncertain future. There is benefit to risk pooling. Since most of us live in the first world where the traditional financial system has evolved ample insurance infrastructure, we don't always realize how remarkable it is, or how vulnerable we are to bad regulation of it.
This is nonsense. Ethereum is uninsurable. The turtles-all-the-way-down notion that you can wrap a bad "smart contract" in a bad "smart insurance contract" and buy Ethereum insurance from an Ethereum insurer and prove that there will be enough Ethereum there to make everyone whole economically should everything go to shit because a fundamental problem in Solidity lets anyone unilaterally blow the whole thing up...
I honestly don't know what to say about that. It's ludicrous.
It may not be uninsurable, but pretty clearly trying to use insurance on the platform to insure against risk that are in some sense endemic to the platform seems quite misguided.
> but pretty clearly trying to use insurance on the platform to insure against risk that are in some sense endemic to the platform seems quite misguided
Absolutely, the risk posed by a malfunctioning VM is a systemic risk that applies to the entire platform. So there is a chance that contracts impacted by a VM bug could be unreliable across the pre and post bugfix VM. The insurance contract could be one of these.
However, all things considered, I think it's interesting to contemplate a binary future "contract" about whether there will be a VM-bug-necessitated ETH hard fork in the next 30 days. What would the ideal exchange be to take a position on that future? I think it would probably be a different, but largely similar, smart contracts platform very similar to ETH, possibly even ETC.
Notably the meatspace financial system does a horrible job at identifying much less hedging against systemic risks. Identification is hard because the interactions between multiple regulatory systems and ambiguous and variable enforcement mechanisms are nearly impossible to model or to understand. It's like having a bunch of inter-related contracts all of which run on their own buggy VM.
The meatspace system seems very stable until you realize that it's highly brittle. It's impossible to meaningfully measure firm solvency risk, because the behavior of the "VM" is so unpredictable.
> The meatspace system seems very stable until you realize that it's highly brittle. It's impossible to meaningfully measure firm solvency risk, because the behavior of the "VM" is so unpredictable.
Actually, it's not. Regulators and ratings companies do a pretty good job of it, and in extraordinary Great Recession type events there is usually concerted response to keep consumers from incurring any losses. Insured not getting paid due to counterparty issues is a blue moon, black swan risk for business, virtual never happens to consumers.
Regulators and ratings companies did a terrible job leading up to the 2008 crash, and people did have real losses. Some pensions got hit hard, for example. The loss doesn't have to come directly out of your bank account to have a real effect on you.
Exactly. Also, the cost of bad regulation is not just in the aftermath... it's mostly in the period leading up to the crash when so many billions of dollars were invested in the wrong stuff.
The great thing about the modern economy is that capital is readily available, but that doesn't mean that the massive misallocation of capital over a period of decades lacks significant consequences.
Many of the dollars mis-invested into real-estate related investments brought on by tax loophole, sloppy (if not corrupt) regulation of downside risk scenarios, and the undemocratic socialization of risk via the GSEs were all things that had a massive social cost.
To argue, as the GP does, that the regulation and management of the crisis was a success by pointing to a few selected asset prices that were the focal point of knee-jerk populist reactions to the problems is a fairly absurd way to claim success.
Problems in Solidity are a systemic risk faced by all contracts and are thus not something that can be hedged within the system.
Correspondingly, fixes to VM bugs are the sort of thing that the hard fork mechanism is good for. Hard forks that fix flaky VM behavior are uncontroversial.
While there are many applications of insurance products, the use case I am referring to above has to do with specifically insuring the expected behavior of a smart contract.
Suppose I write a smart contract that "rounds up" a user's transactions for a day and donates the rest to charity. I describe the contract verbally as "This contract lists all the transactions your account made that day, rounds to the nearest ETH, and donates the difference to account xyz which is associated with the American Red Cross fundraising division.
There are several aspects of this contract to verify. First, does the logic in the code do what the verbal description says it does. Are there any mathematical errors? Can it run more than once in given 24 hour period? Is the id associated with the Red Cross actually linked to that organization?
If a trusted third party vetted the contract and claimed that its claims were true and that 800 people had used it that day to donate, I'd likely consider it worthwhile to trust that contract.
Similarly, if a third party offered an insurance smart contract that would charge me a tiny amount of Ether to guarantee that the contract would behave as expected within a 10 year period, I might feel comfortable buying that contract. If that third party was unknown to me I might rely on recommendations from others, etc.
The point is that trust builds upon trust. One sort of vetting can help buttress other layers of vetting. This is no different than trust in meatspace, only the characteristics of the blockchain make some kinds of trust easier to realize.
Damn, you're right. And if people use smart contracts to do things that are technically allowed, but have unexpected downsides, we should have a review system in place where impartial third parties review the contract language. Two people should be assigned to speak for and against the unexpected behavior, and then maybe a panel of 12 regular citizens could render the actual verdict.
This is the central, glaring flaw in cryptocurrencies to me. Transferring "value" for goods and services is really more of a social problem than a scientific/engineering one.
Money is a social technology that solves a social problem. Cryptocurrency is a engineering technology in search of a problem to solve.
> Transferring "value" for goods and services is really more of a social problem than a scientific/engineering one
Do you mean on the margin where there is debate about the contract or whether the goods/services were rendered adequately?
Cryptocurrencies don't attempt to solve this problem at all, they simply allow for efficient moving of currency between parties without the need for meatspace regulation/trust to do it.
Smart contracts make sense with a blockchain because now humans can agree on specific contract behavior that is fixed due to the highly prescribed way a VM will process it. This doesn't mean that humans will or should blindly trust a smart contract to do what some third party claims it will do.
But unlike meatspace, there is one VM that matters, contracts and oracles can earn a reputation as being trustworthy, and established patterns can be executed with incredible efficiency and fairness.
The issue that presents a challenge for all systems (cryptocurrencies and meatspace institutions) is bootstrapping. Some people will get burned in the beginning because fraud will be temporarily easier to commit. This is why I wish the DAO had just been allowed to die without the hard fork. What is needed is not innovative crowd funding schemes, but additional trust and vetting infrastructure.
Shame on whoever considers himself familiar with cryptocurrencies that downvoted this. This is a well worded argument for an opinion that one may or may not share, but whatever one's position about the "true believers" of smart contracts the parents points are valid, on topic and sensible.
Btc isn't here to pay your coffee or your salary, it's here as a fallback if you really need to get out of traditional finance.
Same with ETH. You're not supposed to switch all your banking, notarial or legal affairs to the platform but it's there for cases where traditional contract law isn't desirable.
Now why so many people ascribed additional meaning or value to these platforms is the really interesting part. In a way, it's good these hacks happen as a reminder that this is what you signed up for. It's the wild west and you don't have a court or government watching your back. That's a (the) feature.
> do things that are technically allowed, but have unexpected downsides
Unexpected downsides for whom? Smart contracts cease to be smart if we have to rely not on the VM but on a small group of human overlords.
If a smart contract exists and you don't know clearly how many times it has been used and what percentage of the parties who used it are pleased with its functioning, you really should not use it unless you feel comfortable personally reviewing the code.
With the insane decision to use a Turing-complete language, the contract's behavior undecidable. You don't even know if the contract will halt.
Limited "gas" (execution time) isn't the solution, because the lesson of the Halting Problem isn't that a program might not terminate. Even if the program halts within a finite time (or "gas"), the behavior of the program on the current input is still undecidable.
Any serious attempt at writing "smart contracts" should demonstrate their understanding of the science of insecurity[1] and limit the contract language's complexity to deterministic context-free.
> With the insane decision to use a Turing-complete language, the contract's behavior undecidable.
OTOH, if the language isn't Turing-complete, there will almost certainly be things you'll want a contract to do that it can't. You can have generality or decidability, but not both.
> It is possible to have trusted contracts, iff their logic is (mathematically) proven.
Suppose a non-Turing-complete language were used instead. Now, imagine a contract that is highly complex. If a layperson decides to trust that contract without reading the code, does it matter whether the language used to implement the contract was Turing-complete or not?
I'd argue that trust of contracts is pragmatically more of a social concept than a computational concept, since at scale the vast majority of contract users would make their trust decision about a contract based on non-technical factors.
> If a layperson decides to trust that contract without reading the code, does it matter whether the language used to implement the contract was Turing-complete or not?
Um, yes? Literally the point of weaker languages in this context is that they can be statically provable.
> No, being Turing complete makes it impossible to be 100% secure and trustworthy, by definition.
Being Turing-complete means it's possible to write some contracts/programs for which certain features are undecidable by analysis.
It doesn't mean that programs that could be also be written in any more limited language can't have all the properties about then that could be proven in the non-Turing complete language proven when written in the Turing-complete language.
> It is possible to have trusted contracts, iff their logic is (mathematically) proven.
Trustworthiness of programs (including “smart contracts”, which are only loosely analogous to traditional contracts) is about whether the actual people using them get what they expect out of their behavior. Mathematical proofs of formal properties may be useful to that in some cases, but are not generally sufficient.
I'm sorry but we have 6 decades of fundamental security research that has shown that it is essentially impossible to have a sufficiently complex, secure system.
The idea that we will ever stop needing human arbiters is laughable and pure hubris.
It's a matter of scope. You can build a secure currency exchange protocol: I have yet to hear of a technical issue with BTC that threatens its raison d'être.
But when you're making a distributed, general purpose, scriptable contracting platform at some point you ought to consider trimming the core way down.
Maybe if the contracts had more constrained semantics ETH programming would be less scary, at the cost of some bells and whistles or more verbose syntax.
If the language is Turing-complete there are definitely things you'll want in contract (such as the execution of it halting in finite time) that you won't be able to enforce. When code is the literal definition the contract, non-Turing complete is the way to go, because you can't reason about your code otherwise.
Turing-complete means you cannot write an algorithm to prove termination in every terminating case, but it doesn't mean you can't prove termination in particular cases, and it certainly doesn't mean you can't reason about your code.
Based on other comments here there certainly may be questionable decisions in the design of Solidity but that doesn't mean Turing-completeness is one of them.
These are good points. What if the default behavior of a contract was to reset the world to its previous state if the program does not terminate within 30 seconds?
Arguably unclear termination semantics would be a good reason not to trust a contract. Ideally trust mechanisms would exist such that closed source contracts were trustable via a pure insurance-based mechanism.
Obviously all EVM programs halt, otherwise the Ethereum network would be completely ruined immediately. You already know why they halt: there's a gas limit.
Ethereum programs aren't Turing complete. They always halt. Turing complete programs don't generally halt. That's the definition.
You should demonstrate your understanding by using these terms correctly!
This whole argument about Turing completeness is a huge red herring.
The Parity multisig attack was an extremely simple programming error that has nothing to do with Turing completeness.
That people put their trust in such a contract despite its source code being obviously wrong points to the real problem.
The real problem right now is the lack of convenient tools and established practices for formal verification. If you think formal verification is impossible for EVM, you're wrong and you fundamentally misunderstand computation.
I've seen this criticism over and over again on internet forums: "EVM is so stupid, it can't be formally verified because it's Turing complete."
It's totally wrong: EVM isn't Turing complete, and it doesn't matter.
Look at "The Art of Computer Programming." It's full of Knuth's proofs of the correctness of algorithms written in assembler and imperative code. Look at any proof of correctness of a sorting algorithm.
OBVIOUSLY you can prove the correctness of programs written in Turing complete languages. You just look at the specification of the language, formulate a specification of your program's intended behavior, and then prove that the code matches the specification. This is how formal verification works, regardless of Turing-completeness.
To clarify, what is the impact of Turing completeness on formal verification? It means that for some ARBITRARY program, you cannot ALWAYS prove that it halts.
But even with some non-Turing complete formalism, you obviously cannot automatically prove the correctness of an arbitrary program; that's just nonsense. You could be certain that the program halts, sure, but how valuable is that? Ethereum already guarantees that all programs halt using the very simple gas mechanism.
> You already know why they halt: there's a gas limit.
Did you actually read my post? I'm not claiming halting is a problem; it's merely an example of undecidability. The "gas limit" doesn't help in the cases where the program does halt with unexpected behavior.
> Turing complete programs don't generally halt. That's the definition.
Where did you get this nonsense? See [1] for the actual definition.
> attack was an extremely simple programming error
Yes, which is why it's stupid to use a language with a grammar that cannot be proven. If trivial mistakes happened in production code, how do you expect to find the subtle bugs that happen because of the complex interactions that occur in recursively enumerable grammars?
> prove the correctness of programs
You can do that for some programs, but not all. The point about grammars is there are classes of grammar that allow automatic verification. Using a recursively enumerable grammar instead of a regular or context-free grammar demonstrates a severe misunderstanding of either language theory, or secure/safe engineering practices.
int_19h description[2] of some of the insane parts of Solidity suggests a PHP-style fractal of bad design[3], not a platform for proving correctness.
If you can't prove the correctness of your program, you shouldn't run it. Why are you concerned with proving the correctness of arbitrary programs? Can you give an example of an Ethereum-like program that can't be proven correct?
Here's how reasonable Ethereum contract development should happen. You construct the contract, either in some high level language or in bytecode. Then you prove, using some reasonable formalism (TLA+, Isabelle, paper, symbolic execution, or whatever), that the contract does what it should do. Then people who want to trust the contract look at this proof.
This is not at all hindered by the EVM being quasi Turing complete, because at no point do you have the question "How can I mechanically verify halting of an arbitrary program?"
Using a Turing-complete language does not mean that all possible programs written in that language are undecidable. As a trivial example, if a particular program doesn't have loops or recursion, or if it loops for a fixed number of times, it quite obviously will halt. More generally, it's possible to write simple code with clear and obvious effects.
If were really that bad to use Turing-complete code, then smart contracts would be the least of our problems, because Turing-complete code runs our airplanes, medical equipment, and nuclear reactors.
I have heard of a similar system in which two opposing teams are formed and argue over technicalities of the language used in front of a lifetime appointee with no particular experience of the topic who will decide the outcome.
What is "unpredictable behavior"? Per ethereum, the code is the specified behavior. Would a contract with function "GiveMeAllYourMoney" be unpredictable behavior if it did what it said. What if instead it was named "Execute"? So now we have a contract whose "unpredictable behavior" depends on how you name functions and variables. However, that is something that cannot be checked by a computer, but would have to be human checked. "Unpredictable behavior" likely would ultimately have to be adjudicated by a court. In that case, what has the smart contract bought you?
I use the term unpredictable behavior simply to describe a case where the contract has behavior that was not fully anticipated by at leat one user of the contract.
Of course, the code is deterministic and so the behavior was unambiguously defined in the contract's source code.
But there exist all sorts of semantic bugs, which can at times be pretty subtle, which means that even for an expert, the mental model of code execution may not match reality.
If there were nondeterministic behavior in the Ethereum VM that would necessitate a fix to the VM and would likely be completely uncontroversial.
Seems like a chicken and egg problem. The crypto currency space is currently so fraught with fraud and crime that I assume no sensible insurer would touch it with a long stick. Insurers need a boatload of seed capital and - if they would be to act as expert intermediaries as you suggest - must invest lots and lots of R&D to due diligence. But as long as ETH mostly remains a get rich quick scheme for computer criminals, any such insurer party would only stand to loose all seed capital they invested.
> The crypto currency space is currently so fraught with fraud and crime
The lack of KYC requirements has led to some criminals using cryptocurrencies, but BTC is fully public and so money laundering, counterfeiting, and tax evasion both go away when we move to a public blockchain.
Those three crimes are all so much bigger and more costly to society than the petty crime that has fled KYC to use the blockchain that I think the truth is the opposite of your insinuation.
>but BTC is fully public and so money laundering, counterfeiting, and tax evasion both go away when we move to a public blockchain.
So you believe that all the public mixers are compromised? It's certainly possible, but even so, they clearly aren't publicly compromised, and as such, I'd argue that tracking down large amounts of money moved conventionally is easier than tracking down large amounts of money through the blockchain, as last I read, traditionally, btc was sent through mixers quite often.
If money laundering is illegal, and the owner of a BTC address sends money to a mixer, it's pretty easy for law enforcement to identify the person involved in money laundering.
If a person isn't linked to KYC in any way and the coins are anonyously owned, then it's a bit harder, but as BTC becomes more mainstream it becomes increasingly difficult to prevent most transactions from touching KYC-regulated accounts.
As a borderline anarchist I'm not arguing this is a great thing, but it nonetheless offers a much more efficient path to enforcing money laundering laws.
FWIW I suspect some are compromised. Also, mixing adds cost, and so even if money laundering happens but is heavily taxed by this additional cost there is some utility to the blockchain based system.
Various insurance contracts could be applied redundantly and/or recursively, and of course over time the real-world characteristics ought to become known and the price of insurance for well understood contracts should approach free.
There's a lot wrong with this argument. First of all, a primary concern when buying insurance is proof of the solvency of the insurer. That means the insurer has to hold the capital covering their outstanding risks. So any insurer that can prove solvency also has to sit on a ton of capital instead of using it productively, which means the minimal insurance cost of a contract is going to be value * (risk + r * time), where r is the expected rate of return on capital.
Adding on N redundant insurance contracts increases the total cost of insurance by N * value * r * time, assuming that the risk of insuring another insurance contract is extremely low. That number explodes extremely fast, and there's no obvious way to solve the problem apart from buying insurance without blockchain-based proof of solvency. But if you're doing that, why do it on the blockchain at all?
I think blockchain-based proof of solvency is one of the most compelling use cases of cryptocurrency, fwiw.
Your argument is valid, but consider that most contracts execute very quickly and so the scope of the insurance is quite limited. For more elaborate contracts, or for a set of inter-related contracts, insurance will be available for highly demanded combinations.
Also, since much of the insurance is against fraud, as parties became more trusted the price of insuring against their bad behavior would decrease.
Insurance is and has always been a profitable business simply because pooled risk is desirable in many circumstances. Blockchains don't alter this basic reality, and they make it far cheaper to offer proof of solvency and other meaningful transparency measures that benefit consumers.
Consider, for example, if employees could do a solvency audit of the PBGC at the click of a button.
There is money to be made providing vetting services as well as insurance services. You could argue that all parties offering either of those services are 100% going to be fraudulent, but this only makes sense if you assume that there is more money to be made acting badly than by developing a legitimate reputation for being honest.
In a group of actors, trust is a good thing. It benefits everyone, and everyone has an incentive to foster its development.
In meatspace systems we rely on things like identity verification (id cards, green bar certs, fingerprints, retinal scans, etc.), reputation by affiliation (resumes, schools attended, firms worked for) and and testimonials from others we trust.
The key aspect of the above is that we don't have to trust any of those signals perfectly in order for it to be of some benefit. If I find out someone went to Harvard, is followed on Twitter by Marc Andreessen, has had five commits accepted by Linus, has a credit score of 675, uses Android, has bad breath, etc., I will take each of those signals as some indication of her credibility on various issues and formulate my meta-opinion about how/whether to trust her based on some heuristic.
When I order from a seller on Amazon with very few stars I take a similar risk, yet once in a while I do so. Some fraud is taking place on Amazon but on balance the system gets more trustworthy every day.
> Users of the contract should pay an insurance fee
Which would make such contracts significantly more expensive than regular contracts that are reversible by trusted intermediaries and legal authorities.
Paying out insurance claims is much more expensive than simply reversing a transaction. This is part of the reason Bitcoin never took off as an alternative to credit cards. Consumer protections are much more expensive to wrap around immutable transactions.
> Which would make such contracts significantly more expensive than regular contracts that are reversible by trusted intermediaries and legal authorities.
You assert this but don't offer proof. The cost of fraud is baked into all areas of our economic system to the point where it's very difficult to establish how much it is costing society. Arguably the massive innovations in counterfeiting prevention in the past decades indicate that counterfeiting is a major problem. Money laundering and tax evasion are the other big crimes that impose significant social cost which public blockchain systems solve beautifully.
The larger a percentage of the economy that is transacted via a public blockchain, the less opportunity for all sorts of crime. The existence of the "trusted intermediaries and legal authorities" as well as the elaborate enforcement mechanisms that accompany them, are themselves a cost.
> This is part of the reason Bitcoin never took off as an alternative to credit cards
This does not make sense as Bitcoin is not a mechanism for extending consumer credit.
> Consumer protections are much more expensive to wrap around immutable transactions
Protections against what? Confusing interest rate terms or cards sold to college students? Bankruptcy or minimum payment rules? All these sorts of things would apply equally to a credit card denominated in BTC so I'm not sure what you mean.
Parent is referring to the transaction mechanism of the CC providers, not consumer credit.
Fraud is a function of humans not the currency. The reason large systems to protect from fraud are baked in, is because there are a lot of humans that commit fraud. The blockchain would only provide a well documented account of the fraud, with no tooling to remove the assets from the fraudster. Chargebacks are a blessing when you need them and a curse when you receive them, but something that the economy has deemed a necessary evil mostly because there are a lot of fraudsters in the world.
> Chargebacks are a blessing when you need them and a curse when you receive them, but something that the economy has deemed a necessary evil mostly because there are a lot of fraudsters in the world
This is an excellent point, and I think it's an example of how an institutional mechanism evolved to help address fraud.
There's absolutely no reason to think chargebacks would not come to exist if commerce were dominated by ETH or BTC transactions.
The difference is that the infrastructure to do chargebacks, merchant account underwriting, etc., can be built very easily with relatively few lines of code.
I don't think anyone doubts that smart contracts can be written that allow for a trusted third party to effectively reverse a payment, especially not in Turing-complete languages. I think the point is that if mutability and trusted third party oversight is actually usually a necessary and desired fraud prevention feature in a payments system, there's probably not huge demand to replicate all that using blockchains whose most-touted virtue is immutability and trustlessness and brand new institutional infrastructure
(it's not like we don't already have ways for algorithms to execute trades subject to contract conditions being met using old-fashioned dollars and yen)
> I think the point is that if mutability and trusted third party oversight is actually usually a necessary and desired fraud prevention feature in a payments system, there's probably not huge demand to replicate all that using blockchains whose most-touted virtue is immutability and trustlessness
I'd argue that rarely in meatspace finance is the consensus mechanism considered separately from the other aspects of a currency that matter. Consensus at changing aspects of a currency typically fall upon a government organization which has its own politically-driven, non-transparent consensus mechanism.
In meatspace, we have things like bankruptcy law and its derivatives to help preserve order when contracts unwind.
Of course, provisions for unwinding an agreement in an orderly way are part of any sophisticated financial deal. Meatspace contracts bootstrap on existing legal interpretations and regulations, but those things mainly add convention, repeatability, and predictability to the behavior of the contract.
So when (if ever) does the consensus mechanism in a fiat currency actually matter? I'd argue that it matters when the sh*t hits the fan, when there is an economic shock and widespread demand for action. This is when the stupidest decisions get made and the rule of law is the weakest.
Hedging against these stupid decisions adds tremendous cost and friction to meatspace financial deals. While it may feel right for regulators to "make whole" certain parties, that is not necessarily in the interest of the rule of law. It's far better if the various contingencies are addressed before the fact so that they can be priced in accurately.
Systems like Ethereum have the potential to create (over time) a set of useful and inviolable rules that can allow transactions to take place without the costly hedging against stupid, knee-jerk decisions by regulators.
In order for parties to willingly enter into contracts, the desirable state is not that later some wise overlords will take a look at the contract and make a fair decision about some yet-to-be-determined aspect of it. The desirable state is for the contract itself to be 100% trustworthy.
Of course, with the infamous hard fork, Ethereum failed at this once, but ETC exists now in tandem, so the two governance approaches can compete on their merits.
Distributed blockchain consensus give us a more transparent consensus mechanism than ever before, which is crucial to democracy. On this bedrock, it will likely be possible to create a world where we truly have the rule of law, not the rule of men.
The point here is not that smart contracts are "law", it's that the execution of a contract should take place in an unbiased VM, and the transparency and consensus mechanism of ETH ensures that.
> if mutability and trusted third party oversight is actually usually a necessary and desired fraud prevention feature in a payments system, there's probably not huge demand to replicate all that using blockchains whose most-touted virtue is immutability and trustlessness
This is exactly right. Once you empower trusted intermediaries to police and reverse transactions, you lose cryptocurrency's primary raison d'être.
I buy a shirt online using cryptocurrency. The merchant teams up with an intermediary to ship it to me.
I buy a shirt online. I team up with an intermediary to verify that the merchant ships the product as promised in exchange for a small fee.
I buy an electric skateboard online. I view reviews written by intermediaries about their experiences and watch some videos those intermediaries have posted of them riding the boards over various terrain.
I make a transaction where I am asked to commit money upfront without receipt of any goods. I use an intermediary (escrow service) to hold the funds in a specifically sanctioned way, to avoid the risk that my counter-party is dishonest.
None of these things are replaced by the core mechanisms of a cryptocurrency. Cryptocurrencies just make some kinds of trust more efficient to establish, but it still must be established and in most cases cryptocurrencies don't offer mechanisms for it. Ethereum does, but in a way that necessitates trusting the behavior of smart contracts, so it's a building block for efficiency and scale, but not a replacement to the core human institutions that involve intermediaries.
None of those are intermediaries that police and reverse transactions. Even escrow services do not offer the same protection as credit card chargebacks, which go out to 90 days or longer. Once you implement that type of intermediary, the primary raison d'être of cryptocurrency -- decentralization and immutability -- goes out the window.
I take note that you have reduced the claimed value of cryptocurrency from decentralization and immutability to mere "efficient trust establishment". However you are still making a totally unsupported claim that it is more efficient that existing methods (e.g. getting a credit card or payment processor). Considering the enormous energy cost of mining you will need to offer some support for that. Otherwise it's just frothy hype.
> The larger a percentage of the economy that is transacted via a public blockchain, the less opportunity for all sorts of crime.
Talk about unsupported assertions. You do realize the article you're commenting on is titled 153K Ether Stolen in Parity Multi-Sig Attack.
Others have noted your confusion about what "consumer protections" means. It is patently obvious that paying out $153,000 in insurance claims would be more expensive than reversing the fraudulent transactions.
I think your confusion is that you think the immutability mechanism is a flaw. Addressing the fraud should be done via insurance, since otherwise we need to trust yet another party to be sure transactions can't be mutated/reversed.
I think if you examine all the assumptions leading up to your conclusion you may find that it is erroneous.
There's no confusion. I've pointed out that protecting consumers from immutable fraud via insurance premiums, as you propose, is much costlier than having a trusted intermediary police and reverse fraud. You have pointed to no errors in my assumptions or logic.
You simply believe that we "should" not trust intermediaries, which is fine, but you must accept the consequence that consumer protections will be weaker and/or costlier to implement. This is why Bitcoin was for the most part never more attractive to consumers than cards.
A few days ago people on HN were arguing that it's okay if cryptocurrencies use a decent fraction of the world's energy, because securing the blockchain and building a financial system that is decentralized and impossible for any human to gain control of is a major project for humankind and worth spending a decent fraction of the world's resources on.
Does that argument still hold up if you're going to have human insurance and human arbitration?
> Does that argument still hold up if you're going to have human insurance and human arbitration?
I think it does. You don't need human arbitration, but there are so many cases where having it makes people more likely to transact.
Similarly, a hotel can put up a rack with brochures in the lobby, or can hire a concierge to smile and interact with guests as they walk by. The purpose of the concierge is to create more transactions than would have happened with a rack of brochures.
As for the question in the previous thread, I'm not sure if it's worth the energy expenditure or not, but predictions are that energy will cease to be scarce by 2030 or so.
1) moral hazard/information assymetry - If I insure you against fraud I have removed most of your financial incentive to protect yourself, so I need to have some other reason to think that you will. I also need protection against the fact that you have more information than I have about the risk of fraud (how do I know you won't collude with the fraudster, in effect defraud yourself and collect on the insurance?) In the normal world this category of concerns prevents lots of types of risks from being insurable, and we have criminal law to protect against collusion
2) Capital commitment - It's not sufficient to just get a promise from the vetters, the capital has to be committed (ie escrowed in some way) otherwise how do I (as an insured party) know they will make good on their payment when I need them to? As an insured party I have to be able to verify that you have done this. In the normal world, this is handled by regulatory capital guidelines for insurers and counterparty collateral posting in the world of OTC contracts.
3) Network effects - If I have capital in escrow, the contracts protecting that escrow would presumably themselves become extremely high-value targets for fraud. Can they be insured? How would you know that the capital is committed to pay out on these insurance contracts? Escrow again? This is a very significant bootstrapping problem - how do I as a participant somewhere in this chain know that in the last resort my insurance will be able to pay out so that if need by I can make good on my commitments. In the normal world this is handled by central counterparties demanding collateral posting against open contracts.
It's very tempting for engineering/technical people to assume that even though they don't really understand all the details, everything has an engineering/technical solution that would be so much better than what has been developed by their predecessors. This disruptor's hubris is necessary for progress to be made against very hard problems otherwise they would probably be to daunting to tackle.
Trust in the existing contract law system has grown organically over a very long period of time. Some of the smartest people going are lawyers and they've had a significant head start on these problems. It would be pretty difficult for trust to evolve organically given some of the poor decisions and scale of subsequent fraud that has already happened in the "smart" contract world.
These are valid and clearly articulated points. I do not disagree. I would simply point out the following:
You point out the non-trivial nature of building a system like we have today. I'd argue that Ethereum, with smart contracts and an immutable public blockchain is a useful innovation that I consider a useful building block for creating and improving the kinds of institutional relationships and interactions that you describe.
A system of insurance implemented on Ethereum would need to have the same sorts of moving parts that you describe. Ethereum would make some aspects of this harder and others far easier.
There would still be a need for collateral, escrow, etc. My comments are not meant to argue that these mechanisms become useless, they simply become more transparent and when viewed in terms of the rule of law, become significantly more resilient when markets become politicized and the rule of law is in danger of breaking down.
Things that would potentially be far easier in an Ethereum based system would be:
- assessing/auditing the books of an entity. Things like proof of solvency become much easier, and also looking at assets which are accounts receivable that depend on another entity's solvency. The modern financial system has very course-grained and inadequate ways of looking at this sort of systemic risk, which makes cascading firm failures truly devastating and nearly impossible to insure against, since any cascading firm failure will involve many ad-hoc regulatory interventions and rule changes that essentially nullify a large number of pre-existing contracts/hedges that might have existed.
- forcing precise regulations. One of the pre-2008 meatspace glitches was the too-little-too-late regulatory decision to force firms to mark certain types of assets to market even if their accounting approach determined that doing so inflated or deflated their balance sheets incorrectly. With a public ledger it would be possible to easily test a new accounting rule's impact on a firm's financial statements.
Let perfect not be the enemy of good. If you demanded that our currencies like dollars live up to your criteria, we would still be trading goods without currency.
That ship sailed a while ago. Ethereum has already used its market position to de facto interfere with the transactions they declare immutable on the project home page. [1]
Oh, yeah, I forgot. Dollars are much better; a central bank (actually, any bank) can create arbitrarily many of them and flood the other banks and the market with cheap money, causing things like the subprime crisis. Much better than crypto currencies.
Airplanes can fall out of the sky at any moment, but you're still less likely to be hit by one than if you're standing on a rail waiting for a train to dodge around you.
Inflexibility is not an advantage unless you're dealing with formally describable, proven systems. Human behavior and economics are not.
The dollar depends on the willingness of the US government to keep servicing its debts, which would have real-world implications if it stopped. Indeed, political disagreements over this have already resulted in interruptions to governance and the availability of services, which is arguably equivalent to food shortages under communism.
Can't you say the same thing about software that uses encryption in general? For example your browser, yet you still trust it. Also, what you said applies to critical software in airplanes, and cars like Tesla, yet you still somehow trust it without reading the code.
Maybe you should replace the word "Ethereum" with "sotware". "Software in general makes sense is all the following are true"
> Can't you say the same thing about software that uses encryption in general? For example your browser, yet you still trust it.
Software in general doesn't exist in a vacuum - it's backed by all the centuries-old meatspace institutions like common law, courts, and lawyers that provide a recourse when something goes wrong. As I understand Ethereum's whole purpose is to replace a lot of these institutions with "smart contracts" (correct me if I'm wrong). If Ethereum has to rely on the same institutions as every other piece of software to deal with contract disputes isn't it just adding more complexity to transactions?
Not necessarily. Without judging the suitability of Ethereum for this, if you have something that does automated contracts at e.g. 9 nines reliability (fails one time in a billion), it may be very much worthwhile even if you have to fall back to the court system for the one in a billion occurrence.
Now, I'm skeptical of Ethereum's suitability in this space - the design doesn't seem to be geared enough towards correctness. However, they've also done some things that I really like (e.g. rolling back The DAO), so I'm not counting them out just yet.
Rolling back the dao set a terrible precedent, and people that were ripped off in the latest hack should rightfully be asking for another fork. If there isn't one, then it'll be apparent that the developers will only protect their own interests.
That's a great point. It will be interesting to see what they do here. My bet is that they cover their interests, with an outside chance that they make up some kind of BS about percentage of ethereum in circulation vs the size of the fraud.
You're right that software can & will have bugs... but I think that makes my point?
To clarify, my point isn't "software has bugs! don't trust it for anything". My point is "software has bugs! don't make it the forum of last resort for contractual disputes".
Safety-critical software, for flight in particular, is required to meet rigorous certification standards and processes specified by law that include independent engineering review. You can't just slap in something from github, write some tests and call it a day.
This is somehow the top comment, but doesn't deal with the issue at hand. In fact it entirely ignores it.
The theft wasn't due to an issue in the core protocol of Ethereum, it's due to faulty code in a single piece of software (as you can see throughout the rest of the thread).
It's a matter of poor engineering practices, not a flaw in the fundamentals of the protocol.
If an engineer designed a bridge, and it failed due to a flaw in the design -- say the math on a strut's angle was bad and the bridge collapsed causing millions in damages and took a few lives. Do you blame steel, all steel, and everybody who uses steel in construction as foolhardy? Or do you blame the engineer, the safety inspectors, and the company that oversaw the project?
The whole point of TCP/IP was understanding that networks are unreliable, and introducing schemes check for the receipt of packets, handling lost ones, and changing connection parameters dynamically so fewer packets would be lost in the future.
In essence, TCP/IP is engineers trying their utmost to design a system where a single flaw doesn't result in the whole data stream being corrupted.
Add HTML browsers into it, which is extremely tolerant of input mistakes and you have a total system that will handle random losses pretty well.
That is until somebody writes a simple script to utilize the protocol to overload an end server with requests, then a server not equipped to handle such a load will fail due to an exploit that wasn't immediately obvious (of course it is now. It's an assumed part of best practice for any large project.)
The protocol doesn't offer any recourse itself, and the end user who might suffer because of such an attack has no defense. They rely on the ability of the engineers involved and some technical voodoo they don't understand to keep everything safe and working for them. That's my point -- I wasn't comparing the technologies directly, but their roles in a larger system.
> The theft wasn't due to an issue in the core protocol of Ethereum
True enough, but what the parent pointed out is that this class of problems is due to a flaw in the core concept of Ethereum - which is much worse than just a flaw in the protocol.
To extend your analogy - Ethereum is like if a company advocated for building bridges using a process that made the bridge's integrity unverifiable using traditional engineering means. Some bridges may hold up, some may fail, with no clear way to identify which bridges will do what.
I understand your counterpoint, but I don't think it's accurate. I mean, if it isn't verifiable, then how would it at all be exploitable, and then patchable?
Even so, any product designed for the network could be tested to death on any of the available testnets. It would be foolish not to ram any project up against everything in that environment, which is why I suggest poor practice as a primary cause.
It was an oversight, to be sure, and a major one. (that's not nearly strong enough language, but I want to be civil)
> I mean, if it isn't verifiable, then how would it at all be exploitable, and then patchable?
Let's assume you're right and smart contracts are verifiable. Verifiable by whom? I can assure you that my non-techie friends could not verify a smart contract themselves, so they will have to trust some authority that verifies the contract for them. The chain of trust now moves entirely into meatspace again and will be subject to the same economic and social forces as existing financial systems. So what has Ethereum accomplished other than adding an automated intermediary to transactions?
For a real-life example of what this might look like consider HTTPS. In theory SSL allows you to cryptographically verify the identity of the site you're looking at. In practice your ability to do this is still bounded by the competence of third parties like browser vendors and the integrity of CAs issuing certificates.
Well you've picked up on very difficult bit of semantics, and one that is probably worth its own discussion entirely.
The code is verifiable by a skilled engineer (in good faith) -- so there is a catch. Any body that produces a smart contract requires the trust of those who take part. Alternatively, it requires trust in one's own expert engineer to verify the content and functioning of a smart contract.
Where Ethereum is trustless is in the execution of the contract once verified. There is then no course for non-delivery if the code is designed this way.
So, it's trustless at one level, and requires trust at another. When I say it's semantics it's just this last point.
Personally I don't see the problems other see with that, because I don't see blockhain tech and tokens replacing everything all in one go, including the need for governing bodies and law. I don't see it as a choice between one or the other. For what it's worth, I'm closer to a socialist than the usual libertarian ranks that flock to these things. I think the world would benefit from the efficiency it could bring about, once the kinks are worked through.
Well, the original comment that I excerpted from was discussing the flaw in the very idea of smart contracts superseding human-readable agreements (ie, "the code is the law, and anything we say about the code is just so much noise").
So, yes, in reposting I generalized from "smart contracts are a bad idea" to "Ethereum is a bad idea". Considering how essential the smart contract is to essence of Ethereum, I feel comfortable making that generalization.
Side note: "the essence of ethereum" would make a great subtitle for Drakkar Noir.
I have zero domain expertise in cryptocurrencies or Ethereum, but much experience with unexpected failures of "guaranteed" things and processes.
To use your analogy - I'd view the bridge design engineer as having guaranteed that the design process could not possibly result in construction of a bridge that fails. That seems closer to what Ethereum would have us believe.
A bridge design domain expert presumably understands:
- that design process uses strut calculations (and therefore includes measures to guarantee those calculations can never be wrong);
- that bridges may be built from steel (and therefore includes inspection routines that guarantee faulty steel can never be used);
- that the environment acts on bridges through corrosion and earthquakes (and therefore includes routines that absolutely always preclude failures arising from the bridge's environment);
- etc., etc., etc.
Maybe it's just my ignorance or misunderstanding of this domain, but I see Ethereum as naive in its guarantee of perfectly predictable behavior.
A guaranteed flawless protocol that fails (for whatever reason) when implemented in reality, isn't.
In your description I still take away that the root problem isn't in the technology, but in the engineer's implementation. Even a calculation that is guaranteed to produce the correct results [if implemented poorly or with errors or with exclusions] can fail.
The engineer who wrote the contract appears to have made a critical logical error.
That does bring me to your conclusion, though. I've paid less attention to the marketing and promises and have assessed the technology as-is (within the confines of my knowledge) -- as such I see what's possible instead of seeing it as a product that under-delivers.
I wonder if a lot of people (especially on HN) would view it differently if it weren't for such bold claims on the developers' part. I mean, I think you're probably right in it being naive in its guarantee of predictability. I think any actors on the platform should assume its supposedly perfectly predictable behaviour is not quite so when they take to designing software or a contract. But that's part of what I meant when I've said it comes down to engineering practice -- when it comes to critical systems assumptions just shouldn't be made in young technology no matter what anybody tries to sell you.
I would add one more point: even if both participants in a contract fully understand and agree to the contract, the contract could still be thrown out under contract law for many reasons -- unconscionability, agreement to commit a crime, etc.
If Ethereum becomes popular enough, one day the participants in an Ethereum contract are going to sue each other, and the judge is not going to be impressed by arguments that the contract is intended to be immutable. You can't opt out of contract law just by saying that you opt out of contract law.
If we enter a contract that we all know is intended to be immutable, why would a judge not enforce that? I can understand buried and obfuscated immutability clauses, but if the parties know exactly what they're getting into, the parameters of justice are contained.
We (tech geeks) tend to think of situations like this as analogous to code, where the local declaration supercedes the global one. We see a specific investment platform with specific terms and rules and our gut says those override more general ideas about how it should work because they're more immediate to the context.
But civil society is the opposite: Contracts cannot violate the law; the law cannot violate the constitution. The justice system would care about the terms of the DAO only insofar as those terms fail to conflict with the law, which includes a massive body of precedent in contracts and torts.
There can be an immutable smart contract which is in compliance with the law (though you have to be more specific with which law, but for these purposes I know we mean US law).
Point being, immutability is not sufficient to demonstrate that a contract is in conflict with the law.
But it's impossible to prove that a smart contract (or any contract, for that matter) is in compliance with the law until it goes in front of a judge and all possible appeals have been exhausted, and that's what matters here.
Judges throw out contracts that both parties agreed to on a regular basis, even if both parties knew exactly what they were getting in to.
Agreement is not the only prerequisite for a legally enforceable contract. The contract also needs to avoid certain unenforceable things like unconscionable clauses, or agreements to do things that are illegal.
Every single second, mountains of new information becomes relevant. Parties cannot know what they are getting into, because they cannot see the future. They can only make assumptions.
But that's basically obvious to anyone not hinging their personal identities on peddling technocratic revolution.
Right. Ethereum is just a medium for recording a contractual agreement. Using ethereum should not make contracts any more enforceable in the eyes of the law.
In many cases I would assume the opposite will occur: plaintiffs will claim that there was no contract formation because because the technical mumbo-jumbo of computer code is incomprehensible to a layman.
I suspect that courts will react quite favorably to this argument seeing as how they have a natural interest in maintaining their jurisdiction.
I'm just amazed that people want to cut the courts out of jurisdiction over contracts. The courts are a legal recourse if you get screwed.
Why give up those rights and let a computer program (or rather, it's creators) dictate that you're screwed if you make a mistake? I mean, contract law exists because that kind of strict arrangement proved unsatisfactory in real life in the past.
> Ok, and now what if the two parties are anonymous or one lives in Russia?
> In that case the judge can't do shit.
In the latter case, I'm pretty sure that (even leaving aside other mechanisms that might apply), judges and courts exist in Russia. Agreements where the parties are based indifferent countries have long been a thing, and long been enforceable by courts.
Unmasking anonymous parties, obviously, can be (though it is not always, even where it must be done) a prohibitive burden to legal action, OTOH.
Slow down! Let's just aim for reducing uncertainty.
Let's say we have an uncertainty scale scored 1-100. If 100 is "money in a bank" and 1 is "money that's already been set aflame, but there's a cup of water nearby", I'd put Ethereum in the low single digits =)
If we put "cash in a hidden safe" at 1, I'd put "money in a bank" around 10. My checking account was once drained by the state on a clerical error. Or almost - they left me 17 cents. They did have a process to get it back (which, interestingly enough, involved emailing cryptographically signed documents back and forth), but it took a few days, and it was only lucky timing that prevented it from triggering a cascade of problems.
These newfangled experiments that I don't fully understand are still well above 10 for me, but they only have to get down to around 11-15 before I'll be interested.
Actually, there are only limited public policy exceptions to contract enforcement. In theory, almost any court should enforce whatever the parties agreed to. When they encounter "bugs" (usually ambiguity), the court might need to choose a side. Sounds a lot like choosing a fork, right?
Why is there no "pen-test" phase to any crytocurrency which hits the market.
So, let me understand; you're ostensibly smart enough to (perhaps as a body of contributors, even) develop a cryptocurrency offering - yet youre also fucking stupid enough to not have same/wider network of ppl attempt to hack the fuck out of your plan?
Does this already occur? or some savant comes and owns them?
We have fucking HIPPA FFS and the compliance systems for something as trivial as my stupid name.
so; ELI5: WTF are currencies doing/not-doing which allow for such hacks (1) and allow for exploits to go unseen (2)
It has nothing to do with any currency or protocol. It was a broken feature in a piece of software used on the network that was bad. Unfortunately, it was widely used and somebody caught the fault and exploited it.
It's more like a company's open source software allowing somebody to steal your bank password. It doesn't have anything to do with USD or the Fed, or even the bank's larger practices. It has to do with how negligent they were with regard to a particular feature.
Of course, there is a very large financial system designed to deal with the fallout of a bank password being stolen. There is no such system with crypto-currencies.
This...it was a poorly written contract just like the DAO was. Parity developers didn't follow the most basic contract safety steps, and people used it because they trusted them too much.
Each of these situations is a painful learning experience, but moves the platform forward.
Cryptocurrencies do go through pen tests. I think instances like these are a good analogy to how even multiple tests run by 3rd parties will only get you so far -- particularly when the "bounty" is potentially worth millions.
> The Swarm City Core team is more committed than ever to the development of Swarm City. The real value of our token lies in the community, and the technology the developers are creating. Black hat hackers, vulnerabilities, and bugs will not stop us from creating the decentralized sharing economy our community and the world craves.
What?!? That seems like a pretty relaxed response for someone who just lost 8m dollars.
Their whole statement is pretty concerning. They do not seem to be taking responsibility for writing a very basic and obvious bug that lost them millions of dollars. That'd end most companies.
The initWallet function should have been marked internal, but was instead not marked. Unmarked functions default to public in Solidity, so anyone can call that function and reinitialize the wallet to be under their control
Why would an unmarked function get the broadest possible scope in a language designed for contracts? I'm always surprised by the decisions made around Ethereum, and just how much value people have poured into it.
i know that you're not really serious when you generalize against all of us crypto simpletons, but anytime theres a stupid amount of money on the table people are bound to rush to pick it up. and that means mistakes.
the work being done on public blockchains is unlike anything else done before. You don't have he luxury of keeping your db behind a vpn running on a vm platform secured and maintained by the worlds largest companies. These engineers put themselves out there, waaaaaaaay out there to try and make shit happen. And they mostly do good work. But if banks and major retailers who have huge budgets can get hacked, of course we can too.
I think a big part of the complaint is about the implicit assumption that because people are smart, and have experience with cryptography, they necessarily have the experience to design a sane and safe programming language given their goals.
They did put themselves way out there, and that takes ambition, but also hubris. I wish they were able to figure out which one was driving them at certain points a bit better, as while some of these problems are because they are doing new and interesting things, some are old as dirt for computing, and there's little defense.
If some company tried to tout a new language with all the pitfalls of C, but none of the benefits of being really inter-operable and known the same way, I'd like to think we could recognize that as having some very bad design choices given what we've learned from C, and at little benefit other than being different. Ignoring decades of research and experience on the topic through ignorance is not laudable, even if you've put yourself out there. I can't help but feel we have a similar scenario going on here.
Actually, I think Solidity being designed to turn bad node.js coders into bad smart contract coders was key to Ethereum's success.
I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually used. Some tried doing them in Bitcoin, but Ethereum's the first that gets lots of action. And so many other blockchains lift the smart contract functionality straight from Ethereum.
That may be, but if so, it might be worse. What's worse, not getting a lot of uptake for this idea that's been hard going for others, or getting the uptake because of trade-offs you made that make it a ticking time-bomb that may damage the reputation of the idea for years to come and set it back?
Solidity is like PHP in the 90's, easy to learn and easy to screw up. Though Solidity just compiles to the EVM, and there is no reason new, safer languages can't be built on top.
As far as I can remember, the EVM has never failed, just programmers.
That comparison may be apt. PHP at that time was a mix of some good ideas (ease of deployment) with some horrible ones (register globals on by default is unexcusable), and some poor planning. We all lived with the fallout of that for a very long time.
The register globals issue could have been avoided at very little cost, if any cost at all, to the popularity and spread of the language and many millions of dollars and much personal information would have been saved.
I agree that it was a key to the success; but it will also be a key to it's failure.
Because it's a financial system, and normal sane people don't want money that is demonstrably worse for nearly all the things that normal sane people do with money.
Ethereum is a great political statement, and a fun toy... but when you recast the worse is better story into this context, you're just demonstrating that you don't really understand the meaning of the words that you are mindlessly parroting.
Thanks for warning us that you're about to release a terrible book, with an incredibly stupid central idea.
You might as well have just written that MySpace is the future of social networking. Because while crypto will have an interesting place in the future; only a complete moron would make the argument that Ethereum is a success, or that worse is better applies here. Congratulations on being that moron.
You appear to have misconstrued my words. I don't in any way think this is a good idea; just one that has the viral characteristics of "worse is better".
I spent about three thousand words on the smart contracts chapter, attempting to conclusively stab this bad idea in the face and supply a suitable rhetorical ammo dump for anyone faced with having to deal with these things to kill the idea stone dead. Absolutely everything about smart contracts is terrible and misconceived. I don't believe there is any way to do them right, because the idea is fundamentally wrong.
Are you asserting Szabo's original smart contracts idea "is terrible and misconceived", or Ethereum's implementation "is terrible and misconceived". The latter, I would have to agree; hard forking as a response to these kinds of security holes is neither sustainable nor scalable, and I'm very partial to mechanical proof-based designs and implementations as a result.
Szabo's idea was a hypothetical for two decades. Ethereum is the first smart contracts platform people actually write for. There were attempts to do it previously, but Ethereum is the one that actually took off.
So if you're talking about Ethereum as a bad implementation of a good idea, you're weighing up reality against something that was a hypothetical from 1994 to 2014.
In any case, there's plenty really obviously wrong with the idea of immutable smart contracts. Legal code is a bad match for computer code; immutability means changes in circumstances can't be allowed for; immutability means you must code with zero bugs; the oracle problem (getting real-world data in and out of your smart contract) ...
"Dr. Strangelove" is the story of a smart contract going wrong, unstoppably, immune to human intervention.
Szabo's stuff is better than the reality - he does actually understand law as well as code, and at least early on he considered there was a role for human intervention - but it's still the sort of thing that's "interesting" rather than "a good idea".
I don't think your personal attacks lie within the standards set by this community. There are many ways of disagreeing, even vigorously, without being a jackass. It's discrediting to yourself.
One of the more important skills in this craft is the combination of intuition and knowledge to know when you don't know something well enough to achieve the goal. The difference between "ambition" and "hubris" is small but critical.
Then you shouldn't be working on it. If you can't be humble, you should not be working on things that can hurt people because you're creating risk for them that they can't actually measure. (It's why I consciously avoid such projects; knowing one's propensity to arrogance makes it unethical not to.)
If it's important, you need to be good. If it's very important, you need to be good and sure.
The Ethereum developers sold a vision of smart contracts, where the code is the contract. However, their hubris lead to them attempting to implement a complex language, instead of starting the endeavor with a small, simple, verifiable language. Similarly, their belief in their own infallibility lead them to write code that is not tested, and to create capabilities that are literally untestable.
This was bound to result in multiple massive failures. The dao was one. This is another. There will be more, because it's an overly complex implementation.
It doesn't matter, though. Only dumb-fuck crypto futurist suckers have ether exposure, so it won't matter that they get zero'd out once a competent team enters the space. That said, the space attracts incompetence like lights attract moths, so it'll take a while to find a team that is technically competent and also has the marketing chops to get traction.
you don't think 200m ico's counts as marketing traction?
This space doesn't atract incompetence, it atracts everyone. When you have tech thats so transparent and accessible, degrees and diplomas don't get to decide who can or cannot work on it. Plus, the world most experience blockchain developer has at most, 9 years of experience. That's not a lot of time to work out the kinks.
I like your point about language complexity. Can you point to a language that would fit the simple and verified criteria? I don't really follow the subject, so it would be interesting reading.
You could take inspiration from a system like Dafny or F-* and write your contracts with the assistance of a type system and compiler that generated proofs that your contracts satisfied some postcondition given a precondition. People have already written moderately complicated applications like operating systems in these languages, so there's some evidence they could be applied to contracts on the blockchain.
There's essentially no legitimate use case for crypto-currency. Cypherpunks have been at it for decades and all they have to show for it is drugs, ponzis, assassination markets, and conspiracy theories.
It would be nice to see some sort of casual hawala-type federated micropayments system based on real national currency, with instant settlement, low fees, and no fake money value store. But, that would be a pre-9/11 idea. Nowadays that's basically illegal and useless.
Paypal is more or less good enough, and hopefully regulators and market forces will control the fees and abuses.
Sorry, but have you looked on the democracy and justice-culture index maps worldwide? The democratic, end-of-history, justice-seperatly-delivered state is currently in full retreat.
I agree, the futurists got it the wrong way around, assuming something cyper-punk-currency enough would blow the state away and allow for crypto-anarchy to rule. Instead, we got states that on slight economic decline implode on themselves (a whole thinker caste in denial about human nature hunting scape goats) and suddenly the crypto-currency nonsense doesent look idiotic, because it can work on, even as the state becomes hostile.
Thats the vision- a somalia like decline, but society moves on, with schools back uped to youtube, with contracts backed up to the block chain, with the currency back uped to bitcoin. I find the ideals of crypto-anarchy laughable (those guys would be gunned down on the first corner, in a real anarchic world), and yet, i can agree to the path we taken. Cellphones and facebook, to have a culture of shame, that fights wild mobs and public hysteria, because the internet does not forget your lowest point. Anyone in power in fear of getting caught in public, for the world to see as just another corrupt, well fed monkey?
When my work introduced me to the guy that explains to us how the retirement fund works, I asked him if the Euro is safe (this was 2011-12), and what the safest investment is. He said "the safest investment is to buy a farm and grow your own food, because you can't eat money or gold.".
And in this Somalia 2.0 future of yours, how will the computers and networks be powered?
Predictable, but not necessarily inexcusable. What is gained and learned in attempting more complex smart contracts sooner rather than later when all the building blocks for absolutely secure smart contracts are built can certainly justify the approach.
> But if banks and major retailers who have huge budgets can get hacked, of course we can too.
Here's the thing: banks and major retailers can't get hacked. At least, not in the sense you're using "hacked".
When Target's credit card systems were compromised, resulting in the CEO resigning and and about $300M in costs to the company to deal with the breach, not one customer lost a penny.
When $171M from Union Bank of India was fraudulently wired via NYC to two Cambodian banks and one Thai one, they got all the money wired back within a day.
The traditional banking system is designed to be unhackable, because the numbers on computers are not authoritative. They're a cache, and they're periodically reconciled, but humans (and other computers!) will look at the cache during reconciliation for obvious attacks like these. A bank can call up another bank, or a retailer can call up a credit card company, or whatever, and say, "Hey, these transactions were fraudulent, please reverse them," and it'll happen. Target did that. Union Bank did that. A hacker can get to some bank's MySQL database? Sure, whatever, it's not what matters. Definitely it's a greater headache than if they got to the bank's website, but at the end of the day it's exactly as fixable as hackers getting to the website.
There are a lot of bright people trying very hard and putting honest work into a problem that simply doesn't need to be solved and shouldn't be solved: making the computers authoritative. When you do that, you're suddenly hackable. When you do that, of course $16M gets actually stolen irrevocably from time to time, no matter how bright you are or how honest your work is.
From this and your previous comments, I am trying to figure out your basic point. Would you summarize it as, "I have a low tolerance for financial risk and others should think as I do"?
I don't think that's a good way to summarize my point - I have expressed no opinion about financial risk, either my own or others. (Did you mean to address someone else?)
However, whatever financial risk you would like to tolerate, you should make sure you're pursuing goals that do in fact match that financial risk, and that you're not concluding that something more or less risky than it is because you are uninformed. Also, if you are tolerating increased risk, you should do so because there is a purpose for it (e.g, better potential upside), not because high financial risk seems inherently cool. It isn't, and I will certainly defend that point, but it's just a lemma on the way to my actual point.
Arguing that it's okay that cryptocurrencies are hackable because the traditional financial system is hackable is simply factually incorrect: it's a misunderstanding of why the existing financial system looks the way it does, and why its risk tolerances are built the way it is (not a lot done to secure transactions, but a lot done to be able to reverse transactions if needed).
If you really want a simple point out of me, I think G. K. Chesterton made it in 1929:
> In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
If you do not understand the existing financial system, you cannot honestly claim that your new one is better. First figure out how it works and why, and get that right, then you can describe how your changes are improvements.
I'm inclined to agree but I must say this traditional system is unscalable. Sure it can detect millions of dollars of fraudulent transactions, but what if it's a single person who's the victim of identity theft and lost just a few thousand dollars? A few thousand dollars is nothing in the grand scheme of things but they are a lot to a single individual.
Right, and also, a good part of why credit cards have 2-3% overhead is essentially insurance against chargebacks. I'd rather pay $51 for groceries every week than $50 for groceries plus a risk of irrevocably losing tens of thousands of dollars at some point with no warning.
If cryptocurrencies think that they can provide this service for substantially cheaper than 2-3% (note that this is an additional service on top of simply making the transfer happen, so mining fees aren't the right thing to compare), that sounds awesome, but also I'd like to understand why it's possible.
Even that 2-3% is way high, in some places like Europe and Australia, interchange fees are capped at values around 0.3% and that doesn't seem to be a hindrance in getting business done.
I've had calls from my bank's fraud detection department about single transactions of less than fifty pounds that they were concerned weren't from me, so clearly the traditional system is plenty scalable enough.
But Bitcoin and Ethereum can do this too. In fact Ethereum already has done it (and is arguably designed to do it). Ethereum simply has to convince a majority of the participants to fix the bug and reset to a good hash (whereas bitcoin would need a majority of the mining power unless they went out of band and used old school politics/force/coercion).
The thing is, cryprocurrency people usually think of themselves as smarter and better programmers than the rest of us. They even co-opted the term "crypto" to mean their toy currencies instead of actual real life, useful cryptography.
But yeah I admit, cryprocurrencies are good toy projects on which to learn real crypto, that's true. But then it's time to move on. And not to pour millions of dollars into that
Would you please stop posting snarky and/or uncivil and/or unsubstantive comments? especially on divisive topics?
You've done this repeatedly, it lowers the quality of discussion, and we're hoping for better than that here. If you have a substantive point to make, make it thoughtfully; otherwise please don't comment until you do.
That's not how JavaScript works. Variable declarations are hoisted to the start of the enclosing function scope and only undeclared variables are global by default.
But yes it seems pretty asinine to use global by default for (not so) smart contracts.
Another way of describing that is that variables are global (scoped to the lobby, to borrow a term from the languages which came before JavaScript) unless explicitly marked with the "var" keyword, which has semantics that some languages might have chosen to give the name "local". Like: your entire premise that a variable is only the declared variables makes no sense to me as someone who teaches college-level classes in programming languages. In Python variables default to local unless marked "global". In JavaScript, variables default to captured via scope unless marked "var".
Well, if they are global when they are undeclared, that pretty much means they are global by default. Maybe a better way of putting it would be "js variables are declared global by default, when unspecified and not using strict mode".
Anyway, I think parent's point was to say this behavior already has been seen in javascript. Actually, it may even be inherited from javascript. When I first looked at solidity last year, I was under the impression it was a modified version of javascript, like unity3d's one. Nowadays, solidity landing page reads "high-level language whose syntax is similar to that of JavaScript", so not sure if it still is (or has ever been, for the matter) derived from something like v8 or rhino.
The reason for that choice seems not far fetched : it's not uncommon, when wanting to add scripting to something, to go with javascript, since it's arguably the most known language, developers knowing "<their main language> and javascript", especially webdevs (a blockchain app project, lisk, even made html/css/js the defacto mean to build apps). Of course, fintech is an industry where the usual values from webdev (release early, release often) have disastrous results.
In javaScript, the following lines does different things:
"use strict";
foo = 1;
var bar = 1;
"foo=1" changes the variable foo (this is very useful) and "var bar=1" creates variable bar and adds it to the function/lexical scope. If the variable foo is not created/declared, it will throw an error! But without "use strict", "foo=1" would add variable foo to the global scope! Which might create unexpected bugs if you are used to other languages that does the sane thing and adds it to the local function/lexical scope. So I suggest to always "use strict" !
It's a good indicator that these people may be experts in one area, but not necessarily in others.
Language design is actually notoriously difficult in general[1], but if you're doing language design for a security-critical language[2]... well, that requires actual mechanized proof, IMO. Not just proof of "design", but proof of the implementation. Anything else is a huge gamble. (And I'm sure there are some 'investors'/gamblers who made off very well.)
[1] Beyond surface-level, obviously.
[2] We're talking about 0.0001% of the general population here.
my stepmother recently got a nice twelve month old Nissan Rogue SUV only from working part time off a macbook air. visit this page>>>>>>>>http://www.joinmate2.com chek it site.
> Not just proof of "design", but proof of the implementation.
Absolutely, few people really get this. Even those that do get it generally don't know what it looks like in practice because it's so rare.
In case you're curious about what it looks like in practice (at least one way), we presented direct user code compilation and verification[1] in Jan for our smart contract language Pact[2].
The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts. For the first few days that the system started working (I built the FV portion, Stuart the language + H-M type system) I thought it was broken... turned out we just had a bug in our demo code that we never noticed.
Usually, tests check the things you know to check so when they find something it's not a surprise what they find. Sometimes you can fuzz and randomly find something, which is cool but doesn't guarantee that there isn't a problem somewhere else. However, FV just feels uncanny (as a dev) because the test either finds a problem in the code -- and tells you how to replicate the bug -- OR proves that a problem cannot exist.
> The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts.
I'm not sure I understand this sentence. Are you doing doctests, or are your doctests statements of formal properties, or have you abandoned that and are now doing formal specs->code type things?
It's closest to the middle, assuming that you meant that you're stating the properties that you want to test. It does more than that, but at its base that's effectively how it works so it's close enough for a solid intuition. We're working on a paper about it now -- or at least a sub-paper in the clutch of papers that pertain to a public chain version -- that I'll link to when it's out (a couple weeks probably).
I get paid over $95 per hour working from home with 2 kids at home. I never thought I'd be able to do it but my best friend earns over 10k a month doing this and she convinced me to try. The potential with this is endless. Heres what I've been doing,
•••••••••>>https://is.gd/qKRnJt
Why bad timing? This is really just an example that while safe smart contracts are technically possible using Solidity/EVM, it's practically impossible. "One of the best Solidity devs" just failed to write a safe contract to the tune of a $30M exploit. Given that, what chance does anyone else have?
At some point, it's time to blame the tool and not the user. Moreover, it's not like people didn't see this coming, myself included[1]. I mean, who really thought that basically taking JavaScript and swapping out the DOM for a bank account wasn't going to end badly? But then again, maybe I've spent too much time at in the SEC/finance where "move fast and break things" engineering gets you shown the door quite quickly. That mantra's fine for a number of domains but finance isn't one of them as one bug can bankrupt the company (see: knight capital).
It really just underlines the need for a safer/better approach. Formal Verification has to be part of that story. A language that was designed with safety in mind has to be another part.
Also, not an academic (yet at least). Cofounder here: http://kadena.io
>This is really just an example that while safe smart contracts are technically possible using Solidity/EVM, it's practically impossible.
I don't see any justification for this statement. The bug could easily have been discovered if there had been better auditing. That the auditing missed the bug doesn't prove that it's "practically impossible" to write secure code with Solidity.
In any case, nothing is stopping you from porting your formally verifiable language to Ethereum. The EVM is not Solidity. In fact there is already a project underway to create a verifiable programming language for the EVM.
> That the auditing missed the bug doesn't prove...
Honest question, what would be required in your opinion for before we start considering if the tool is at fault? I ask because, if you're of the opinion that it's never the tools fault then I'll never be able to justify my point of view. Which is fine, we can disagree. I'm all for massive experimentation in this area and thus need people who disagree with me to do research down the other lines.
Also, it's not that I think it will always be practically impossible just that currently (and for the next several years at the very least) it is. We'd need way better tooling and the type of tooling needed is incredibly advanced stuff. We're not talking about a build system here, we're talking about formal verification which is one of the most advanced tools you can build. I can only think of one tool that can formally verify user generated code (cryptol) and even then it's only for a small subset of C/Java that applies to crypto work.
It's not that you can't write safe solidity contracts today but that IMO an element of luck is required. You need to get the right auditors, have them do a good enough job, implement the logic a certain way instead of another and thus avoid a bug no one has thought about before, etc... When people's money is on the line, needing luck is terrifying.
> nothing is stopping you from porting your formally verifiable language to Ethereum
I wish this were true but it isn't. We spent months trying to see if there was a way that it would work because we would have preferred this approach. The EVM itself is stopping us (as well as the shape of the Eth blockchain but we could probably have worked around that problem). Pact is interpreted, so while we could make an EVM version technically it's practically unworkable -- there's nowhere near enough gas to run the interpreter. We couldn't compile directly to EVM either as the EVM just doesn't do enough[1] for you. It's closer to a 1980's era CPU ASM than a modern VM (like the JVM). Moreover, the Pact runtime does a lot of things for you (as a safety feature) that the EVM just doesn't have a notion of. Even then, while all of the Pact-compiled-to-EVM code would work and be safe, we couldn't protect it that code from EVM code that doesn't play by Pact's rules. Moreover, supporting all the extra things that Pact does for you would make it, again, run out of gas on EVM.
This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.
That's the thing about having the EVM be Turing-complete, it makes people think that "it can do anything and thus abstracts over the problem thus solving it." This is technically true but not practically true -- all you are doing is punting a huge number problems/required features (like dispatch and module loading) down the road for the language to figure out. In a gas-metered context, every feature the language adds because the EVM lacks it costs gas and thus makes a number of features impossible in practice.
> In fact there is already a project underway to create a verifiable programming language for the EVM.
Mind linking me to it? I collect references to smart contract languages at this point and haven't heard of this one. I know the people working on the EVM + solidity formal verification project personally (well some of them at least) and it's still years away.
>Honest question, what would be required in your opinion for before we start considering if the tool is at fault?
The programming language being partly at fault is not the same thing as it being "practically impossible" to write safe smart contracts that language, in my opinion.
I was taking issue with your wording, which I think gives a misleading impression of the attainability of secure Solidity code. Your follow up comment is more measured, as it doesn't characterise the need for some measure of luck to write a safe smart contract as writing a secure smart contract being "practically impossible".
Maybe we're using different definitions of "safe", but I think many use my definition, in which case your statement would give them a misleading impression.
>This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.
Yes I am aware of that. There is research being done on possibly switching the EVM to an Ethereum variant of Web Assembly, i.e. eWASM, which will be able to efficiently execute a wider range of functions.
Further on this point, I have to admit that I am not qualified enough to comment on the portability of Kadena to the EVM, so I'll take that back. What I meant to dispute was the notion that formally verifiable programming languages cannot be built for the EVM, which is the takeaway that I got from your comment. A PL of this type is in fact being developed [1].
Thanks for the link to the technical discussion on Solidity.
Read the Solidity documentation on visibility [1]. Public, private, internal, external, that really seem to mix overlapping concerns. In the visibility documentation, it explains that the default is public.
Then, in another section of the documentation, when talking about function types [2], not specifying internal or external defaults visibility to internal.
It doesn't seem like the simplest or most consistent way to express these concepts, and certainly not the safest way.
Your honour, in my defence, the contract clearly specified that anyone could reset the wallet, and if that's not what they wanted, they shouldn't have agreed to it.
> Unmarked functions default to public in Solidity
What kind of brain-dead apes designed this language? This would be a stupid decision in any language, never mind one specifically intended for high-value transactions.
I think the capitalization of a method making the difference between two very different outcomes might be my favorite example. It's that kind of stuff that makes me happy I have to go through api reviews at work - although seriously how does anyone sign off on these designs?
I only wish people had to do that. Shit like this are why professional and civil engineers roll their eyes at the mention of software "engineering". There are best practices and available tools but people employ them far less often than they probably should. In the space, take a look at Kadena's Pact smart contract language. It's not perfect by any means (lisp-religious syntax and its tight integration with Kadena internal constructions, for example) but it is at the least, working on formal verification support.
This is why I keep saying that "smart contracts" should be expressed in some declarative notation like decision tables. Byte-coded programs as contracts were a really bad idea. Contracts need to be readable, not just executable.
Just looking at this language, it makes me feel like we are going back in time in regards to readability and ease of use. I understand that security and provability of contracts is more important in these cases, but one can dream!
Michelson is a VM bytecode, not a programming language, although it happens to be readable enough to write simple contracts in it directly.
IIRC, the old Camllight VM was pretty similar (I might misremember, that was literally decades ago); an ML-like language to Michelson compiler is fairly straightforward to write and to prove sound.
I'm happy that they do things the sane way, i.e. focusing on sound foundations rather than on how Javascripty the syntax looks; but I'm afraid the communication isn't as clear as it could/should be. Blessing a compiler for some subset of ML, as a first high level language, would have cleared things up IMO.
That looks interesting. I just skimmed the white paper. It's not clear what their contracts can do, though. They need more examples.
The underlying DAG idea has potential. You could have two half-transactions happening on separate subtrees, where A is buying X from B and B is paying Y to A. So A broadcasts "A will buy X from B when B pays Y to A", and B broadcasts "B will pay Y to A when A buys X from B". When the matching half-transactions acquire a common child, the transaction commits. It's a true "meeting of the minds".
Yes they do have that what you are describing, "smart conditional payments".
You can for example trade user-defined (possible private) assets (tokens) in that way - "Ill send you my bytes for your blackbytes, I send bytes to this address and me can sweep them back after 4 hours, or you can sweep them if payment of X amount of blackbytes is made to my address". It has oracles as well.
These aren't called "Solidity" and more importantly weren't built specifically to write a financial infrastructure of multiple hundreds of million dollars (though some of these languages are definitely used to manage money now)
Wouldn't it make more sense to design it like Haskell? or something even more strict? A little bit of extra work seems like a small price to pay to prevent millions being stolen from your wallet because of a silly mistake like this...
I can literally feel how Ethereum changes the law. I mean, seriously, no need for lawyers anymore. On ethereum it's is simple: You got fucked, live with it. "Bad faith? It's the code, didn't you read it?"
You skipped the juiciest part of one of my favorite scenes of that movie. [scared the bejeezus out of me when I was little, I didn't realise for some time it was pure satire and no adult would be expected to understand him].
So I feel obligated to post the full bit (from wikiquote)
>Wonka: [angrily] Wrong, sir! Wrong! Under section 37B of the contract signed by him, it states quite clearly that all offers shall become null and void if - and you can read it for yourself in this photostatic copy - "I, the undersigned, shall forfeit all rights, privileges, and licenses herein and herein contained," et cetera, et cetera... "Fax mentis, incendium gloria cultum," et cetera, et cetera... Memo bis punitor delicatum! It's all there! Black and white, clear as crystal! You stole Fizzy-Lifting Drinks! You bumped into the ceiling, which now has to be washed and sterilized, so you get... NOTHING!!! You lose! GOOD DAY, SIR! [returns to work]
>[scared the bejeezus out of me when I was little, I didn't realise for some time it was pure satire and no adult would be expected to understand him].
Yeah, as a kid, I too thought Wonka was serious. It took viewing it as a much older person to see the satire there.
I thought the most ironic part of applying it to this situation is that, just like in the story, the rules were then changed to suit the whim of the enforcer. Meaning, of course, that the rules never meant anything anyway, except to the disadvantage of one party.
The DAO hit every objection from smart contract skeptics, bang bang bang - legal code doesn't work at all like computer code, immutability means you can't fix mistakes, immutability means you can't deal with changes in circumstance, immutability means you must code with 0 bugs - but even we were surprised when they went "lol immutability guarantee" the second the big boys were in danger of losing money.
That's a strawman of what GP said. Of course technology can't solve humanity's flaws. The point was that smart contracts caused many problems they weren't meant to, which was exemplified by the DAO hack. Smart contracts failed to deliver on their promise and the fallout proved that when it came down to brass tax, nobody with skin in the game would respect a smart contract's execution anyway.
That's a good article, and the point about him reading a lot of DFW is hilarious and accurate.
But I think of this issue in slightly different terms that are more simple.
There's a ton of case law about what constitutes a contract that pretty much all countries have. Clearly understanding the contract you are getting into is a prerequisite for the contract being enforceable in most places.
The simple fact is that this is never going to hold up in court when people start suing.
No one gets into a contract with the understanding that they can be robbed, and that's just okay. No rational person would do that. And I think it's a fair case to say that no rational person did clearly understand the contract as presented and agree to it.
The courts are going to to shut this down, in my opinion.
You can't just write into a contract that you might get stolen from or murdered or whatever bad thing and then that bad thing is suddenly okay.
"Okay, this guy didn't read the fine print on that used car loan. Let's go rape his wife and kids now. He said it was okay!"
That's not how it works. Etherium deserves to get hammered for this.
Won't happen. People need to believe that the justice system will hear their pleas and consider factors on-balance, and then proceed in fairness. In real law, there are several potential overrides available to stop egregiously unfair outcomes that would otherwise be legally valid (estoppel, unconscionability, etc.). People will not accept a system that does not have the appearance of fairness (regardless of its actual fairness).
One of the things that cyberpunks fail to grasp is that people don't want a perfectly immutable, fixed system. They want to feel that their sense of justice and moral righteousness can be satisfied. Stuff that drops people off right at "sucks to be you" doesn't really work; there must be some type of recourse available even if it doesn't have a 100% success rate.
And the inverse also applies. People (groups and individuals) want to be able to throw their power around and leave people they don't like at "sucks to be you". This behavior has been the status quo for millennia.
Eh, dictatorships and oppressive systems still work hard to appear fair and even-handed. That's why they have such elaborate propaganda machines.
Anyone who wants to maintain power in virtually any setting (communal, corporate, governmental) must create an impression of fairness and equity, at least to the extent that a good portion of the people are not willing to risk their [reputations/jobs/lives] to throw off the "oppressors".
It's not an accident that virtually all powerful corporate bosses and politicians are so image-conscious and superficial; it's a matter of survival for powerful people.
Not sure why you're being downvoted because you're exactly right. The crypto-anarchists love to say "the code is the law", but the reality is that losing your retirement savings because somebody forgot to mark a method private is a pretty shitty outcome.
For all its warts, a legal system backed by a jury of your peers is still the best way of sorting out the actual intent of a contract when the shit hits the fan.
Sarcastic or not, "contract by code" and "lawyers are obsolete" are, in reality, major selling points used by Ethereum evangelists. The OP's post gives an opportunity to discuss this.
I did not assign any assertion or position to the OP, only followed up on his thread about the potential ramifications that ETH backers seriously advocate.
Ignoring the fact that he was responding to a post that was sarcasm, if we really stop to think about it, how many people are judged by their peers and how many are judged by people who are the furthest from it?
Agreed! It really won't happen, and isn't happening, even in Ethereum: when people find the result distasteful enough, they go via political means to rewrite the ownership so it feels right.
Specifically, in the DAO hack, the affected people had enough political influence to get the entire network to undo the ownership transfer that was the result of their own oversights:
If anything, Ethereum is worse because you have to get the entire network to fork (analogous to a revolution or constitutional convention) to fix a mistake, instead of just getting a judge to rule "okay, that's obviously not what anyone meant".
Furthermore, it's far more unequal, where mistakes only get fixed when they affect the most influential users. Seems like a step in the wrong direction.
You're right on the facts, although I don't quite get why you ridicule this idea as a "sense of justice and moral righteousness" with only the "appearance of fairness".
A system of laws devoid of all ambiguity and emotion isn't even possible, let alone desirable, because at some point these contracts have to come into contact reality, and the humans in it. And these humans happen to be, well: human.
I guess there's an ideology at play that would love to change humans to fit within their neatly arranged algorithms. And if that means some grandmother loses her house because she signed the wrong smart contract when buying cat-food, there'd be a lot expressions of sympathy on Twitter, but she really needs to understand that it's just not possible to do anything about, because principles etc etc.
Here and there, some of these people may, very privately, consider it a feature of the system that others less intelligent than them sometimes happen to die on the streets because of that one Saturday morning where they didn't audit all 500k lines of brainfuck in that contract for chinese takeout.
With less snark: the idea of ambiguity or emotions as being something negative is a somewhat naive view of reality, somewhere on the spectrum between Star Trek's ideal of Spock and the social darwinism of Ayn Rand. It's most often seen in the currently popular misunderstanding of how judges should behave, and how journalism supposedly used to work.
For an example that maybe is a bit less inflammatory than anything about journalism, check any recent threat about the Google vs Uber lawsuit: the presiding judge is almost a legend for his diligence in learning the technology in the Oracle vs. Google lawsuit a few years back. Yet people criticise him for a lack of decorum whenever he uses language that doesn't pretend to be a robot following an algorithm: "This judge is clearly biased! The contract clearly only says $50,000, and there's no law that gives him the authority to say those are USD. When the defendant says it means Canadian Dollars, it's he-said-she-said and undecidable"
I don't ridicule the need to have senses of justice and moral righteousness fulfilled. I think they should be accommodated by legal systems. My point is that systems must at least pretend to do so if they want public credibility.
Ethereum, as well as things like IPFS that say "Your content is permanent and irrevocable, don't publish if you don't like that", are non-starters because they overlook this core desire to operate under forgiving systems.
Many unfair or distorted legal regimes exist (including, to some degree, the American one), but they all make overtures toward these principles in some form or another. Ethereum et al must correct this if they want widespread adoption.
And there's more Ethereum now. The DAO was a ~$50 million fraud. This was a ~$30 million fraud. Obviously this is totally different and there's nothing we can do about it and it's just fine. People should have known better than to use parity with this bug in it.
“Churchill: "Madam, would you sleep with me for five million pounds?"
Socialite: "My goodness, Mr. Churchill... Well, I suppose... we would have to discuss terms, of course... "
Churchill: "Would you sleep with me for five pounds?"
Socialite: "Mr. Churchill, what kind of woman do you think I am?!"
Churchill: "Madam, we've already established that. Now we are haggling about the price.”
We've already established that they will fork. Now we are haggling about the price.
Considering how powerful, famous and charismatic he was, I think, makes one consider that maybe it was Churchill who was being insulted, not the socialite.
"Would you sleep with me?" "Maybe for a million dollars..."
Well, you know, except for the whole "we, the central governors, will hard-fork if we get scared that there's an existential threat to the blockchain" thing.
I realize that was probably satire or sarcasm or both, but since I've seen people actually seriously take that position I'm going to go ahead and respond as if it was serious.
How do these smart contract deal with the real world? I can see how they can work for things that entirely involve activities that take place on the block chain (e.g., a smart contract that automatically pays a crowd funded project if and only if it meets a threshold for pledges by a deadline, and refunds the donors otherwise).
But suppose our contract is something like I will pay you $X in Ethereum when you deliver to me 125 bales of Surat cotton, guaranteed to be middling fair merchant's Dhollorah [1], delivered at the Liverpool docks from Bombay on the next sailing of the Peerless.
How do we put all of that into a smart contract? Can a smart contract trigger payment only when the cotton arrives? Can it check to make sure it arrived on the ship specified in the contract?
And what happens if it turns out that there are two ships named Peerless, unrelated to each other, one of which is sailing from Bombay to Liverpool in October, and one in December? I only know about the December one, and it is on that one that I'm expecting the cotton. You only know about the October one, and so it is on that one you send the cotton. The cotton arrives before I'm ready to deal with.
Unless dealing with all that can be included in the smart contract, and executed by the smart contract without human intervention, lawyers will still be needed...and they will be needed almost as much as they are now.
PS: my cotton hypothetical is based on a real case: Raffles v Wichelhaus, EWHC Exch J19, (1864) 2 Hurl & C 906. There really were two unrelated ships both having and neither deserving the name Peerless, and both working the India / England trade routes, both scheduled for Bombay to Liverpool, one in October and one in December.
[1] Dhollorah is a very dirty cotton of a longish staple, which when cleared is very white, as if bleached. For for more than you probably ever wanted to know on this and other types of cotton, see the book "Cotton Spinning and Weaving: A Practical and Theoretical Treatise" by Herbert Edward Walmsley, page 71. It's from the late 19th century and is public domain now I believe, and you can find it on Google Books.
Didn't you just describe an example where the ambiguity of human language is a problem and a smart contract may actually have a better chance of performing as expected?
I feel like anything humans can use to communicate to each other could be considered a human language.
More relevantly, creating a synthetic language that's a subset of natural languages will mean that multiple natural concepts will map onto the same synthetic one.
Why do you asssume smart contracts can't be ambiguous? A lot of people read the DAO contract, and yet it took a hacker a while to find a small error -- if I recall correctly it was a capitalization error -- that triggered an unexpected exit path.
At some point you have to ask yourself whether we really prefer that code be law, with the quality of code that's so common these days, or whether we actually like being able to specify something to a lawyer -- rather than a computer -- simply because the lawyer will return the contract and ask for clarification if something is ambiguous/unclear.
The human-to-lawyer interface is the best contract interface that exists, the only reason we use computers is because they're so cheap and fast. When we dream of AI we dream of having a computerized lawyer, who can ask clarifying questions and resolve ambiguity before it becomes a problem.
If tomorrow I sign a contract with my mobile phone carrier and it turns out that through some loophole in the contract they get entitled to the kidneys of my first born daughter then clearly I have a case to go to a tribunal and get it overturned as it's obviously not a reasonable clause.
I think people arguing that "code is law" (which is simply a modern form of "letter-ism") don't really know what they wish for. I guess is many are going to change their minds when those attacks get more and more common and they lose a ton of money because of an unforeseen and obviously unintended flaw in the contract code.
Have you ever been to some old manor or library with hundreds of weathered ancient leather bound books...I always wonder about their contents... (usually they are under lock and key)...Cotton case law now seems a perfectly reasonable assumption.
>How do these smart contract deal with the real world? I can see how they can work for things that entirely involve activities that take place on the block chain (e.g., a smart contract that automatically pays a crowd funded project if and only if it meets a threshold for pledges by a deadline, and refunds the donors otherwise).
They can't deal with the real world by themselves, but where they have value in agreements involving real world events is that they allow the real world assessments to be debundled from those aspects of the agreement that can be formalized.
So in the cotton shipment example, the smart contract would have three parties assigned as Oracles that determine whether the correct ship arrives at the correct port on its correct trip. The smart contract would dictate that if 2 out of 3 of the Oracles agree that the condition has been met, then the smart contract will transfer the funds. There could also be a failsafe clause in the smart contract, that is controlled by a set of five oracles, who have the power to override the smart contract if the majority deem that an expected event occurred.
So yes you need human intervention, but only for those parts that cannot be automated. This explicit definition of what the human roles are may encourage better contracts, by forcing the counterparties to spend more time reasoning about which aspects of the smart contract are subject to ambiguity.
> How do we put all of that into a smart contract? Can a smart contract trigger payment only when the cotton arrives? Can it check to make sure it arrived on the ship specified in the contract?
I've not worked with smart contracts personally, so take it with a grain of salt, but...
This problem seems to be mostly solved by the information available in shipping manifests; the locations of loading and unloading, the consignee (buyer), container ids, description of goods... all there in a publicly available (at cost) record.
The real difficulty has more to do with verifying the quality - I'll admit I'm at a loss to how that's done today and I can't imagine quality assessors are at the port to verify that container #123 contains the shipment of Grade B+ cotton or map that to an API. As well, what happens when you disagree and your own independent assessor says its Grade B-? This seems like something that would remain up to legal debate; probably denoted in the contract but not verified by it such that lawyers and assessors can handle it should problems arise.
Especially for this; it should be enterprise, bank-tier code, covered by as much red tape as possible.
The problem with cryptocurrency is that they try to be better than the system, but have to relearn all the lessons the hard way. It probably won't take too long before all of it becomes exactly like what banks are now - heavily regulated, etc.
This is not a problem in ETH [1]. It's a bug in one of the contracts written by Parity. Anyone that has (had) money in these specific contracts is in trouble. If you are not using these specific contracts, you are safe (for now).
ETH and ETC have the same underlying technology and language to write the contracts. So if someone writes a contract it can be used in both variants. The contract may check that it is in ETH or ETC (probably looking for the contract that was added during the fork) but I think very few contracts check this, so almost all contracts are usable in both chains.
So if it was possible to use the Parity contract in ETH, then it's very probable that it was also possible to use it in ETC.
To answer your question: Probably the same bug that was used to steal ETH can be exploited to steal ETC, if someone is using these contracts in the ETC chain. But it's not a problem in ETH or ETC [1].
[1] As other commenters noted, it's a very bad design flaw to make all function public by default. It's not an error, but it makes much easier to write buggy code.
Poking around in that project, I don't see any specific tests of the Wallet contract... would be interested to see what UTs/STs were included if anyone knows where they are -- or was it just manually tested on the testnet? It seems that a basic set of UTs for this contract should have caught this issue.
It's not even in the category of weird timing attacks or complicated internal states allowing unexpected state transitions -- this is a trivial bug that could be spotted by viewing the contract in Remix (the Solidity IDE).
There are certainly some weird edge cases in the Ethereum VM programming model that are hard to UT, and I think that dev efforts in this area are under-resourced (e.g. it's currently impossible to test time-dependent contracts as there's no way of mocking out the clock in the simulated blockchain).
I've been writing some smart contracts over the last couple weeks and have learned a lot from OpenZeppelin's solidity repo–you can either use them directly (importing and extending off of them) or use them as a good resource for building tokens, crowdsales, etc–can't recommend them enough.
Agreed, it's definitely the way to go. Hope the project will continue to evolve. Both Aragon [0] and Storj [1] are making active use of them, if you look for example usage.
As I said here last week "Also the lead developer is some kid who believes very much in moving fast and breaking things. This philosophy may work for a social network site but not for other people's money."
This philosophy permeates the community of Etherum development.
Bitcoin disabled most of the smart contracts op codes for a very good reason.
I wouldn't recommend putting anything of value into an Etherum smart contract and find a project with more responsible developers who take a more "wait and see" approach.
I feel like we shouldn't be expressed in dollars, but in percentage of total funds. In this case 16 million is about 1% of the total. This would be a $16 billion case if the US banking system was the target and used this technology.
You should ask yourself what the Bitcoin developers are doing while Ether takes their market share. The answer is the exact same thing, at https://elementsproject.org
Now why hasn't there been as much publicity about this? Is it because Vitalik Buterin is a wunderkind genius who simply beat them to market? Nope, the Bitcoiners are simply being more responsible and making sure they get the formula right before rushing to market.
People write this stuff off so fast. Here we have a parity developer, probably one of the most competent in the Ethereum ecosystem, and he screwed up to the tune of losing $30m of other people's money.
If HE can't get it right, what business do you have running around saying that anyone who can make a webpage can make a decentralized application?
We are playing with money. Dealing with attackers is not as simple as rebooting your server. Mistakes mean irreversible loss.
The devs in this industry are way over their heads and nobody is willing to admit it, because doing so destroys the entire core value prop of Ethereum, the poster child of the current bubble.
Dear god, I've been thinking crypto is a bubble since 2010. At some point, we have to admit this is not just a bubble. It's a new unproven evolving technology
I actually think eth has a lot of potential, but I don't think he's saying crypto is a bubble. He's probably talking about the ICO "bubble", which isn't a controversial thing to claim. Eth has already halved in value in the last month which is mostly put down to the crazy value being pumped into ICO's slowing down.
I would argue ICO phenomenon is not a bubble
Rather, some ICOs are scams
But many are legitimate business ventures. Buying into an ICO is similar to buying deep out of the money options
Crypto has had at least 3 distinct bubbles. There's the current one, marked by Eth's absurd rise to $300. The previous one was when Bitcoin made an absurd rise to $1200 in 2014. There was a bubble before that where Bitcoin rose to $266 in 2011. And one before that I believe where Bitcoin rose to $32 in 2010.
Though crypto has risen past the high point of each of these bubbles, each price point can be definitively classified as a bubble in it's own time, and was followed by a crash that wiped out >70% of the market cap over the coming months/years.
Though it did recover, that doesn't mean it wasn't a bubble.
I believe cryptocurrency is going to be bigger than e-commerce is today. But it's not there yet, and it shouldn't be valued as though it has changed the world. It hasn't yet, and it's still a few years away at least from doing so.
It's only a bubble if you can identify it ahead of time.
Stating that something became much more valuable over a short period of time doesn't mean you know how to identify bubbles. Bitcoin is 70-80 times more valuable now than when it was at 32, and had you bought it then you would be up a lot. So, to say crypto is in a bubble today is the same thing as to predict that in a few years it will be worth less than today. Do you know that definitively ? I don't
Downvoters, since you know how to indentify bubbles, I'm assuming you shorted ethereum on margin on GDAX when it hit 400 and made a ton? No? If not, why not, if you knew definitely it was a bubble ?
Because it's very hard to figure out where the top of a bubble is, and if you short a bubble asset too long before the peak, you go broke, even if you are correct.
Well, now we are talking semantics. You don't get to claim you are correct if your forecast turns out to be wrong. So, if you identify a bubble, part of the requirement to say that you succeeded is that you can identify the top. Otherwise, your "knowledge" that it's a bubble is useless
He may be brilliant, but he played fast and loose without real testing or concern, so I wouldn't call him the "most competent". For a wallet contract they knew would secure many millions of dollars, there should have been dozens of people auditing it before rolling out to users.
Charlie is trolling. The architect isn't going to be the best craftsman, that requires very different set of skills.
Parity devs may be academically brilliant, and they put out a fantastic client, but the wallet issue shows how lax their development lifecycle has been.
I can't edit my post above to add this now, but looks like Charlie retracted this as Gavin was the original author, but not the one who made the mistake.
Someone's loss is anothers gain. That money didn't disappear, just got reallocated. And if spent ,will generate economic activity. It's certainly a hit in the trust of the core dev though.
> Bitcoin disabled most of the smart contracts op codes for a very good reason.
Bitcoin is also stuck in the past. Yes, Ethereum breaks things, but for me it's not about the money but about the technology stack. We're too early in the process to have the luxury of being able to stop innovating.
If I want to play with cool state-of-the-art technology I use Ethereum. For financial transactions I use my bank and/or Transferwise. Haven't quite yet figured out why I'd use Bitcoin for something.
The 20 cases for underflow and overflow [0] show how difficult it is to develop error-free contracts. Would have been great if the VM would detect such cases and thus make the contract code less polluted with boundary and overflow checks.
Some projects have started sharing audit results publicly directly in their repos [1]. It's a great read to see common errors and yet unsolved issues that originate in the ERC20 token specification.
Please be aware that you can press Y before sharing a link to make it a permalink. The link you shared points to master branch, which will change over time, so the line number you pointed to will have something else.
Based on the time of your post, I suspect you meant to link to:
Where "master" is the branch which normally has the latest code. And #L216 automatically scrolls down to the 216th line.
The issue is that line isn't permanent since the code in the master branch is subject to change. So in order to make a reliable link, you can link to the ref [1].
Normally you'd have to scroll up to the top right of the document and grab the short form it, e.g. "6b0e4f9" and replace it with master. Note that's only the ref of the last change for that blob (file) [2].
If you click the line number on a GitHub file, it will add the #LineNumber to your URL.
From there, press Y, this will replace master with the latest commit of the repo.
It's only for GitHub. GitHub has custom JavaScript on their site that listens to every key press. If they detect you pressed 'y', they look up the commit hash of the version of the code you are looking at and then set the page URL to a page that shows the code for that version.
It's a bug in a smart contract, but the root cause is the bug-prone design of Solidity. It's hard to write bug-free code in Solidity (or anything targetting EVM actually), and nearly impossible to be confident that a given contract is bug-free.
parity.io, the company author of the bug, is a top-notch Ethereum actor. If they can neither get a wallet contract right, nor realise that it's faulty, then who can write and trust any non-trivial Ethereum contract?
How many DAO or Parity trainwrecks before people admit that Ethereum isn't a dependable platform?
> If you hold a multisig contract that was drained, please be patient. They will be creating another multisig for you that has the same settings as your old multisig but with the vulnerability removed and will return your funds to you there.
You don't really have a choice right now. Either trust them and wait to see if your eth is returned, or start rabblerousing for yet another hard fork to undo this 'hack'
It's the same group that rescued funds during The DAO attack so they have a good history of benevolent hacking.
They are just going to deploy new multi-sig contracts with a fix and make the original owners the owners of the new contracts. Pretty easy to do. They are actually paying for the gas to do the fix using donations they received for their work on The DAO attack so the original wallet owners aren't even out the gas the fix would charge (which isn't all that much but it's nice that they are being made completely whole).
The exploit allowed anyone to reinitialize a multisig contract with themselves as an owner because the constructor was a public function. These contracts weren't "fixed" like they were supposed to be.
The white hats will deploy a new contract without the faulty constructor with the old owners reinstated. These newly deployed contracts will have all the same information the old ones did but won't be exploitable.
IANAL but if someone leaves their front door open, it's still illegal to walk in and take their possessions. I would imagine this falls under a similar ruling.
In most cases yes, but isn't ethereum all about "the code _is_ the contract"? If you as the owner of a house put an ad in the paper saying "if you can manage to enter my house feel free to take whatever you want", should you complain if someone did exactly that?
This comment fails to address the point of the comment it is replying to... you simply repeated the original point, but the person you responded to worked within that analogy and then modified it to try to address the statements by Ethereum.
Right, I am saying the analogy I responded to is flawed. Ethereum doesn't invite people to violate the intended use of the contract. It's like claiming that if a corporation got hacked due to lax security, then those hacking are in the clear because that corporation invited them in
Yes because that would still be a crime. Expanding on your analogy - if I declare right now that it's ok to murder me, it's still not ok to come and murder me. Same principle applies to EULAs and Terms of Service, you're not bound to it just because it's in there.
If the hacker was entitled to those funds based on the agreement between the concerned parties (implicit OR explicit in the contract) it would not be theft. But it clearly isn't their Ether and the implicit agreement behind the contract stands.
Basically human ethics, morals and the legal system will always trump code.
> Yes because that would still be a crime. Expanding on your analogy - if I declare right now that it's ok to murder me, it's still not ok to come and murder me.
The comparison to murder doesn't work because you can't consent to murder, but you can consent to theft.
It's not clear to me whether that situation would be taken as consent, but unless you know something I don't, it probably shouldn't be clear to you either.
I mean, legally, what happens is not "consenting to theft". Unlike say assault, which you can consent to, and legally speaking an assault actually happens but consent makes it okay; but with theft, if you consent what happens is not legally theft. (IANAL, but this is my recollection from law A-levels.)
But that distinction is irrelevant here. The point is that there's basically no way for someone to deliberately kill someone and have it not be a crime. But there are ways for someone to take someone else's stuff and have it not be a crime, and one way is if the owner consents.
Under US law, I think that's probably true, but a) it's not what I was talking about, and b) I don't think you should be as confident as you seem to be.
True but there are lots of cases of people exploiting real world contracts (eg. Insurance) to their own benefit. I imagine this is probably a new frontier as far as laws go.
I don't know if that analogy holds in the context of ethereum which is marketed as "code as law". I think it could be reasonably argued that this individual was fairly participating within the terms of the contract.
Monero is the ONLY cryptocurrency where full privacy is enforced by default. No mixers, no opt-in mode, no super-nodes, no tumblers, it's all obfuscated by default. I'm very bullish on Monero long-term.
What I don't like about monero, and why I think it'll ultimately lose to another anon product, is that the transaction history is written to the blockchain, albeit in obfuscated form. But there is no proof on the bounds of what a sophisticated blockchain analysis can uncover given enough information. Roughly speaking, its conceivable that given enough transaction information downstream from a transaction of interest might reveal a "most likely" pairing of an address with a transaction. Or perhaps a global analysis of the monero blockchain along with traditional blockchain analysis could reveal a most likely pairing of all transactions with addresses. The point is that without such a proof I'm not sure how much people will trust it compared to a protocol with such a proof (say zcash). Your exposure to future analysis is essentially indefinite.
What I don't like about Zcash is that privacy is optional and address balances are public. This means that a blockchain analysis company could correlate what is public (all the other transactions and all the address balances) to deduce who the sender, receiver, and amounts were in private transactions.
What you said is essentially meaningless though. "I don't like a blockchain-based currency because the record of transactions is permanent." Well...yeah, that's the whole point of blockchains. The strength in Monero's case is that everything is so obfuscated (and amounts + addresses are encrypted) that it's the best option out there. It doesn't have to be perfect, it just has to be better than its competitors.
e.g. Facebook isn't perfect, but it sure obliterated MySpace.
Not meaningless as the links between sender and receive can be eliminated completely depending on the protocol in place. The record of a transaction has to be on chain, but not necessarily who participated in it, or the nature of their participation.
It's true that a system doesn't have to be perfect to win, but I don't see how monero has the edge on any dimension. It's not necessarily the most secure, its not the furthest along in development, not the most user friendly, not the fastest mover, etc. The overall bullishness people have for monero is because its supposedly better in terms of privacy than its rivals. But this is dubious without the right kinds of proofs when the competition does have proofs.
This won't work in the US. It's very hard to get USD out of Bitcoin. And then the IRS will want to know where you are suddenly getting a huge amount of money from.
You could use localbitcoins to offload one coin at a time on an as-needed basis. That'd be pretty sweet, and the IRS won't be able to know anything strange is happening if you avoid depositing your USD into a bank. But paying rent in all-cash is rather sketchy. I wonder if drug dealers deal with similar problems.
I don't know how plausible this is, but the localbitcoins route might also open you up to being kidnapped. You'd need some pretty decent opsec to avoid revealing that you have a massive amount of BTC you're trying to offload.
Why is it very hard? Can't one simply use Coinbase?
> And then the IRS will want to know where you are suddenly getting a huge amount of money from.
In my experience, the IRS is largely unconcerned with where you are getting money from. They just want you to declare it, and pay taxes on it.
If you treat Bitcoin as ordinary income and pay taxes on it at the highest available rate, the IRS will largely be satisfied. If you treat Bitcoin as a long term investment and attempt to only pay capital gains tax.... well then the IRS will become curious enough to ask for 'proof of origin'.
A bit. They limit to 10,000 per day which would be 300 transactions total for $30 million.
I'd personally call them and get a contract out before funneling this kind of money through their system.
Though that's pretty normal. A regular brick and mortar bank would likely want additional assurances before funneling $30 million into or out of an account that doesn't see that regular volume.
You're saying you could declare "I now have $30 million in assets" on your IRS forms and it wouldn't trip any alarms?
I mean, I don't personally know which alarms would be tripped, or what effect that would have. But that just seems so unlikely.
It'd be fascinating if this were true, though, so any info would be appreciated.
Re: coinbase, it'd be foolish to use them because they have a history of disabling accounts for any reason they feel like. A friend of mine had their account disabled, so I know firsthand this is true. Also it's unlikely they'd send you such a large amount of money unless you were a business in good standing or had a long history with them. (I'm just guessing, though.)
Sure they will ask. And you can say something like "I was an early bitcoin investor". Or "I trade cryotcurrencies".
It is perfectly reasonable to be a cryto trade that never withdraws to USD, and just makes money by transferring between crypto currencies and ICOs or something.
I am sure there are a whole lot of people out there who spent a thousand dollars or so back in 2009, and now they have 10 mill in the bank. It is not like any of that could be tracked.
And then you pay long term capital gains on that money, and you are set.
I guess I'm skeptical of the idea that they won't ask for proof of your trades, which would lead to discovering you were a thief. But I suppose that's highly unlikely.
I suppose but this sub thread was a reaction to someone mentioning that it was hard to get USD out of Bitcoin. It's not about laundering money from illicit transactions.
Illegal activities. Income from illegal activities, such as money from dealing illegal drugs, must be included in your income on Form 1040, line 21, or on Schedule C or Schedule C-EZ (Form 1040) if from your self-employment activity.
>You're saying you could declare "I now have $30 million in assets" on your IRS forms and it wouldn't trip any alarms?
Technically, it's illegal for the IRS to do so without third parties coming to them or suspicions of terrorism. In practice, they probably rat people out to LE agencies regularly.
Someone I know tried depositing btc sale proceeds to their wells fargo bank account. The bank promptly froze all their accounts. It eventually worked out I believe but it doesn't seem as easy as 'just sell them.'
Exchange as much as possible via Shapeshift (accessed via Tor) and other exchanges that don't care about KYC to Zcash, Monero, and BTC. BTC is not anonymous but it's unlikely that BTC transactions are blocked and it will allow to convert to other currencies later on. Once you got Zcash and Monero you can anonymously convert to BTC and cash out via Coinbase. Make sure to only move small amounts at a time, so that the exchange can't block all of your funds.
I suspect that when you steal this amount of money, the law is the least of your worries. There are likely people who will hunt these hackers to the ends of the earth for what they've done. For their sake, they better cover their tracks well.
While Zcash allows for keeping the sender, receiver, and amount private, making that optional and having the ability to analyze address balances will allow for blockchain analysis to potentially figure out the sender, receiver, and amount by correlating all public transactions and address balances. A better cryptocurrency would be Monero which forces all transactions to be private and keeps all address balances private, preventing a blockchain analysis company or government agency from figuring out transaction details.
Change to BTC, use mixers to mix coins. Take a flight to Asia for few months/half a year. Open a bank account in some less regulated jurisdiction (some tax haven) - better yet open several bank accounts like these. Travel around and keep using localbitcoins to change BTC for cash.
Keep sending cash to bank accounts you have opened by depositing cash in person. Use round robin to distribute money across multiple of your hidden bank accounts so suspiciously large volumes of incoming money doesn't get noticed.
Keep moving around, mixing coins and using localbitcoins to get cash and deposit. Also diversify outside of cash to not raise suspicion of the banks by depositing every day / regularly.
Buy physical gold from pawn shops. Then you can turn gold into cash in banks and deposit it to your account like that. You can also use cash to buy prepaid travel debit cards with like 5k on them at a time from post offices or so. Use that for daily expenses.
That might work. If you are not a US citizen but let's say citizen of China that makes it easier to pull off.
Of course, getting that money back to US to your home bank account would be near impossible (without some way to launder the money).
But you could live off your hidden bank account in tax haven. Just don't flash your millions too publicly so people don't get suspicious. Be humble and pretend to live regular life.
Also you could try to launder the money via setting up some fake ICO project and investing your mixed coins into your own ICO, then cash out your custom tokens on exchanges. Just make sure to do this from some unregulated tax haven and it should work (most of these ICOs create their businesses in dodgy tax havens for this reason).
This is how I'd imagine these scammers are doing it.
Can someone explain how immutable contracts get updated? From what I understand you can have one contract forward requests to another, and you can use some storage in the forwarding contract to determine the real target contract. But why would someone participate in a contract that is mutable?
I guess I am just wondering how this contract can be updated, given its on the blockchain and considered immutable.
There are architectural ways as you said, but basically you don't update them. You know the possible bugs, you document the contract, methods and your process early on, you write tons of tests, use auditing tools, do code review with the team, hire somebody to audit your code, test it with bounties, implement emergency stops and speed bumps and some proper monitoring.
When it's about your money, you should be able to do all that.
And yes, Solidity is pretty horrible. I hope there will be better options such as Idris in the future.
I'm sure they'll just hard fork again. And nobody cares because ethereum isn't actually being used for anything real, just a bunch of enthusiasts trying to get rich.
Because it's rolling back transactions that were done under "the law" (e.g. the ether contract stuff) by human intervention when the entire draw of the ether contract stuff was the promise of no human intervention
Yes, and that 'feature' of block chains is never really touted by blockchain supporters. Basically, if 51% of the network think you have too much money, they can just take it from you with no recourse available.
Yes. This was true before and after the hard fork. Seems like common sense to me, but I guess it's a good thing that the hard fork happened because it educated people that this is possible.
> Basically, if 51% of the network think you have too much money, they can just take it from you with no recourse available.
That's not how it works. Even if you had 99.99% of the hash rate, you still have to work within the rules of the chain, so a "give me your money" without a valid signature would still be rejected as invalid by every full node (and you just wasted your hashing power). What having 51% or more of the hash rate allows is a double spend attack: you can undo recent transactions, so you can spend a coin twice.
But the rules of the chain can be changed. If for instance 90% of the full nodes decide to change their software so that "give me your money" is now valid in some special circumstance X even without a valid signature, and that "give me your money" transaction is sent to the network, these 90% of the nodes will allow it to be added to the chain, and let the chain grow on top of it; while the other 10% will grow a separate chain on top of the last block without the "give me your money" transaction. Soon, each side has an incompatible view of which transactions are in the blockchain; this is called a "hard fork". And if the minority side is small enough, it will no longer matter if they still say you have your money, since everyone else you want to transact with will say you don't.
That's what blockchain proponents tend to omit: the blockchain is a social construct. Its rules are fixed as long as the majority of participants want them to be. When they decide to change the rules, like that time when the Bitcoin developers fixed a database bug which changed the validity of some blocks, the rules will change. Even retroactively.
This is a nice illustration that all property in general is a social construct: you only truly own something if the rest of the society agrees that you do. Blockchain is one particular way to set the rules, but our regular property laws are not any different in principle.
The law is written in code, and clearly code can be changed by human intervention. It's even open source, so technically anyone can change the Ethereum protocol, at any time.
Of course, changes to the law are effective only when there is overwhelming consensus, otherwise they're called minority forks.
... because it breaks the basic fundamentals of a block chain. A block chain is supposed to fight against roll backs not support them.
Sure, the core team / devs are using the rollback for good. But will that always be the same in the future? It's an avenue for abuse and one of the primary reasons ether isn't going to take off.
The point is, if the core team made a change that's widely unpopular, clients would just refuse to upgrade to that version.
Discontent users simply switch to a different branch maintained by different developers. If there's enough consensus, people will call it "real" blockchain and the other one will be left behind with few users and hence no meaningful way to spend the balances.
Exactly. You need overwhelming consensus to change the rules safely.
Bitcoin is currently in a state of disarray because groups of developers, miners, industry and users disagree on fundamental aspects of the scaling debate.
There are no fewer than 4 competing Bitcoin fork proposals on the horizon, each one with an unknown number of supporters. The only thing we can measure accurately is "signaling" in blocks, where miners declare their intention to follow one fork when the designated time comes: https://coin.dance/blocks
However, there is such a thing as "false signaling" for strategic reasons, and hashing power can rapidly shift (or just appear, if new mining rigs come online) in favor of a different proposal at any time.
This is indeed a deeply flawed voting system. In contrast, Ethereum still has a capable leadership with sufficient consensus that they can propose and execute hard-forks whenever they feel it's needed, without this level of uncertainty and drama.
Are you asking for a formal definition that could be put in code? Sorry, there just isn't one.
The same laws which apply to stealing tangible things and cash also apply to stealing cryptocurrency.
In the very unlikely event that the perpetrators came out and sued the Ethereum developers for violating their contract and taking "their" money back, a judge would look at the facts and then decide how the law applies to this particular case. IANAL, but I'm ready to bet that the thieves will go to jail for a while :-)
It demonstrates that Ethereum isn't what it claimed to be. ETH was supposed to be smart contracts where the "code is the law". Clearly, after the DAO debacle, that's not the case.
This means that ETH has no actual value. It adds nothing to the legal or economic landscape because it does nothing new (if we repeatedly rollback and hard fork because of "hacks" like this). This isn't a hack. This isn't theft. This is morons who don't know how to code coding in a crappy language meant to run on an even crappier VM. The only victims here are the people who were duped into investing in ETH in the first place. Poor saps.
Because people want to dream this is some anarchist system where nobody controls etherium the same way everyone thinks bitcoin-core isn't a centralized authority on the protocol.
To dispute that de-facto centralization requires miners to collectively decide to abstain from updates to these primary clients en masse. That just won't happen, people don't organize or coordinate like that. The status quo has tremendous inertia beyond what can be reasonably expected of independent actors trying to act in their own self interest.
> To dispute that de-facto centralization requires miners to collectively decide to abstain from updates to these primary clients en masse. That just won't happen, people don't organize or coordinate like that. The status quo has tremendous inertia beyond what can be reasonably expected of independent actors trying to act in their own self interest.
There will be no hard fork for this one. The DAO hard fork fix was only possible because the funds were tied up in a time lock for enough time that they could plan a hard fork.
Vitalik on why there will be no hard fork for this: https://twitter.com/VitalikButerin/status/887783867129745412 (not to suggest that Vitalik can just decree there won't be one like some people think, he's just listing the reasons why the community is very unlikely to support a hard fork).
748 comments
[ 3.0 ms ] story [ 363 ms ] threadThere was no such twist this time around which means the funds could already have been transferred to an exchange and withdrawn as dollars or BTC. You can only undo the ETH part of the transaction, which would take money away from the exchange (or from people who have since bought the stolen coins from the exchange unknowningly) and give it back to the victim. That's a lot less palatable than taking the money from the thief, so it's unlikely to happen.
This is completely incorrect.
A hard fork can undo anything, it's just backing up before this happened and continuing down another path as if it didn't.
Nah, Vitalik is not affected by the bug this time. You only hard fork, when your money are stolen.
During the DAO hack, the funds were prevented from moving anywhere so a hard fork caused a direct reversal.
That's my understanding, anyway.
I use Parity, I have a wallet contract deployed, it's night and I'm wearing sunglasses.
The page linked to here is the blockchain address of whoever exploited that fault and was able to take control of a large number of wallets and forward all of the ETH to their account.
They've sold ~20 ETH so far (~4100 USD), and have ~150,000 sitting at that address still.
Importantly, the contract is not part of the Ethereum protocol, so other implementations and non-multi-sig Parity wallets are safe.
Safe from this bug, maybe. But there's nothing to say that they might not also have bugs of their own.
[Ethereum] only makes sense if all of the following obtain:
(a) the code is 100% bug-free (b/c accidents cannot be rewound)
(b) all code-writers are 100% honest (their code does what they say)
(c) all contract participants are 100% perfect code readers (so as to not enter into fraudulent contracts)
(Strictly speaking, only one of (b) and (c) needs to be true).
None of these conditions will ever obtain.
[0] https://news.ycombinator.com/item?id=14471465
As a contract becomes more important it should be viewed/vetted/trusted by as many entities as possible. Users of the contract should pay an insurance fee that goes to the vetters, who promise to reimburse in case of unpredictable behavior.
Yes, this means applying some meatspace solutions to Ether. However the smart contract infrastructure itself is ideal for implementing this. Ethereum offers immutability, and blockchains can foster new kinds of trust, but trust still has to grow organically in the ecosystem.
If you need a source of trust outside of the blockchain, why would you need the blockchain after such trust has been obtained?
The blockchain offers characteristics (immutability, consensus, distributed backup) that allows entities to trust each other efficiently.
But when you introduce a non-trivial smart contract, there is a chance that it (a black box) has behavior that is not obvious from its source code.
Since the behavior of the contract will cause immutable changes to the blockchain, and since humans can't perfectly mentally model all conceivable source code behaviors and interactions, there must be some other mechanism for establishing that the behavior of the contract matches the common understanding of what the contract does.
This could be sandbox testing, parameter range verification, formal verification, star ratings, etc. As the would-be user of a contract I generally want some reason to trust it.
Ethereum offers the building blocks to create an elaborate vetting, verification, simulation, etc. system. Thusfar, existing institutions have leveraged their own reputations to make users of Ethereum comfortable trusting their contracts. The DAO is an example of the folly of this, but many other contracts are examples of the reasonableness of it.
Over time, Ethereum will build the right meta building blocks to create very rich trust mechanisms which put the meatspace hedging/insurance industry to shame while also shedding much of the inefficiency that ambiguous legal enforcement creates.
There is, we have been using them for hundreds of years, it is called a contract.
Think about what puts contracts at risk.
- enforceability. If your neighbor borrows your car and agrees to pay you $20 but never does, you are screwed. With Ethereum the smart contract could lock the door to the car until funds are received. Verbal contracts for low-priced transactions are rarely enforced.
I had a landlord who simply decided not to return my deposit, so I was out $5K. He stole the money simply because I didn't have time to fly back to that city and proceed with small claims court. With Ethereum, there could be an unbiased oracle that verifies the state of an apartment at end-of-lease and allows a contract to refund the deposit as agreed. The oracle could stop by for 15 minutes on move-in day and snap some pictures, then stop by on move-out day and verify the condition and deduct any money from the deposit as previously agreed. Also the contract could enforce that the money was held in escrow as required by law.
- regulatory risk. In some cases, regulators use their aesthetic to determine that some legal contracts are (in hindsight) bad, and they wipe them out. This drastically limits the usefulness of contracts as a planning mechanism and is essentially a tax (in the form of uncertainty) on all contracts. It's like having a buggy VM that does things arbitrarily differently now and then.
- higher confidence in the outcome of a contract. With paper meatspace contracts, the language is hard to understand and is pieced together from legal boilerplate based on court decisions where the court interpreted a sentence to mean something precise, etc. This makes these contracts difficult for a layperson to understand even though they are written in English. When you sign a contract you don't know how many times it has been reviewed by a court and whether the court found any of it to be unenforceable or to otherwise mean something different from what you think it means when you sign it.
We are always signing TOS agreements, license agreements, leases, waivers, etc. etc. Most of these are virgin legal territory, untested in the court system and designed by lawyers to be overly aggressive in favor of the entity the consumer is doing a transaction with. While it's great that all these contracts might one day be reviewed by a court if the stakes get high enough, a much better approach would be to have very simple, easily enforceable terms. How many unique smart contracts for doing insurance does the world need? Probably about as many as it needs AES implementations. Code that matters would be reviewed with far more scrutiny than most verbal contracts ever get, and composing contracts would also be far easier with well-defined, vetted behavior.
Nope. All of these can be achieved without using proof-of-work which is terribly inefficient.
The parties would have to trust each other... but well, they have to in Ethereum too :)
I agree that waste-heat-generating proof of work is inefficient, but that does not mean that no proof of work system exists where the work itself has some positive externalities.
When the proponents of this service are claiming that you don't have to trust the hospital that they would get someone to triage you, instead you can have your own assigned triage Nurse, you're claiming "But you still have to trust that this third party agency will have someone on the remote location to triage you, then what's the point of using this service?"
Why not just use a traditional financial institution then? What's the benefit of the complexity of a blockchain if it's still unreliable without the added meatspace complexity of a bank?
Insurance via smart contracts is still far simpler and more efficient to implement than in meatspace.
Consider things like insurer solvency risk and the way that meatspace regulations make that hard to understand. With cryptocurrencies an insurer can easily offer proof of solvency based on all outstanding risks.
Insurance emerges as a fundamental economic behavior when you have investment and you have an uncertain future. There is benefit to risk pooling. Since most of us live in the first world where the traditional financial system has evolved ample insurance infrastructure, we don't always realize how remarkable it is, or how vulnerable we are to bad regulation of it.
I honestly don't know what to say about that. It's ludicrous.
Absolutely, the risk posed by a malfunctioning VM is a systemic risk that applies to the entire platform. So there is a chance that contracts impacted by a VM bug could be unreliable across the pre and post bugfix VM. The insurance contract could be one of these.
However, all things considered, I think it's interesting to contemplate a binary future "contract" about whether there will be a VM-bug-necessitated ETH hard fork in the next 30 days. What would the ideal exchange be to take a position on that future? I think it would probably be a different, but largely similar, smart contracts platform very similar to ETH, possibly even ETC.
Notably the meatspace financial system does a horrible job at identifying much less hedging against systemic risks. Identification is hard because the interactions between multiple regulatory systems and ambiguous and variable enforcement mechanisms are nearly impossible to model or to understand. It's like having a bunch of inter-related contracts all of which run on their own buggy VM.
The meatspace system seems very stable until you realize that it's highly brittle. It's impossible to meaningfully measure firm solvency risk, because the behavior of the "VM" is so unpredictable.
Actually, it's not. Regulators and ratings companies do a pretty good job of it, and in extraordinary Great Recession type events there is usually concerted response to keep consumers from incurring any losses. Insured not getting paid due to counterparty issues is a blue moon, black swan risk for business, virtual never happens to consumers.
The great thing about the modern economy is that capital is readily available, but that doesn't mean that the massive misallocation of capital over a period of decades lacks significant consequences.
Many of the dollars mis-invested into real-estate related investments brought on by tax loophole, sloppy (if not corrupt) regulation of downside risk scenarios, and the undemocratic socialization of risk via the GSEs were all things that had a massive social cost.
To argue, as the GP does, that the regulation and management of the crisis was a success by pointing to a few selected asset prices that were the focal point of knee-jerk populist reactions to the problems is a fairly absurd way to claim success.
Problems in Solidity are a systemic risk faced by all contracts and are thus not something that can be hedged within the system.
Correspondingly, fixes to VM bugs are the sort of thing that the hard fork mechanism is good for. Hard forks that fix flaky VM behavior are uncontroversial.
While there are many applications of insurance products, the use case I am referring to above has to do with specifically insuring the expected behavior of a smart contract.
Suppose I write a smart contract that "rounds up" a user's transactions for a day and donates the rest to charity. I describe the contract verbally as "This contract lists all the transactions your account made that day, rounds to the nearest ETH, and donates the difference to account xyz which is associated with the American Red Cross fundraising division.
There are several aspects of this contract to verify. First, does the logic in the code do what the verbal description says it does. Are there any mathematical errors? Can it run more than once in given 24 hour period? Is the id associated with the Red Cross actually linked to that organization?
If a trusted third party vetted the contract and claimed that its claims were true and that 800 people had used it that day to donate, I'd likely consider it worthwhile to trust that contract.
Similarly, if a third party offered an insurance smart contract that would charge me a tiny amount of Ether to guarantee that the contract would behave as expected within a 10 year period, I might feel comfortable buying that contract. If that third party was unknown to me I might rely on recommendations from others, etc.
The point is that trust builds upon trust. One sort of vetting can help buttress other layers of vetting. This is no different than trust in meatspace, only the characteristics of the blockchain make some kinds of trust easier to realize.
Money is a social technology that solves a social problem. Cryptocurrency is a engineering technology in search of a problem to solve.
Do you mean on the margin where there is debate about the contract or whether the goods/services were rendered adequately?
Cryptocurrencies don't attempt to solve this problem at all, they simply allow for efficient moving of currency between parties without the need for meatspace regulation/trust to do it.
Smart contracts make sense with a blockchain because now humans can agree on specific contract behavior that is fixed due to the highly prescribed way a VM will process it. This doesn't mean that humans will or should blindly trust a smart contract to do what some third party claims it will do.
But unlike meatspace, there is one VM that matters, contracts and oracles can earn a reputation as being trustworthy, and established patterns can be executed with incredible efficiency and fairness.
The issue that presents a challenge for all systems (cryptocurrencies and meatspace institutions) is bootstrapping. Some people will get burned in the beginning because fraud will be temporarily easier to commit. This is why I wish the DAO had just been allowed to die without the hard fork. What is needed is not innovative crowd funding schemes, but additional trust and vetting infrastructure.
Btc isn't here to pay your coffee or your salary, it's here as a fallback if you really need to get out of traditional finance. Same with ETH. You're not supposed to switch all your banking, notarial or legal affairs to the platform but it's there for cases where traditional contract law isn't desirable.
Now why so many people ascribed additional meaning or value to these platforms is the really interesting part. In a way, it's good these hacks happen as a reminder that this is what you signed up for. It's the wild west and you don't have a court or government watching your back. That's a (the) feature.
Unexpected downsides for whom? Smart contracts cease to be smart if we have to rely not on the VM but on a small group of human overlords.
If a smart contract exists and you don't know clearly how many times it has been used and what percentage of the parties who used it are pleased with its functioning, you really should not use it unless you feel comfortable personally reviewing the code.
With the insane decision to use a Turing-complete language, the contract's behavior undecidable. You don't even know if the contract will halt.
Limited "gas" (execution time) isn't the solution, because the lesson of the Halting Problem isn't that a program might not terminate. Even if the program halts within a finite time (or "gas"), the behavior of the program on the current input is still undecidable.
Any serious attempt at writing "smart contracts" should demonstrate their understanding of the science of insecurity[1] and limit the contract language's complexity to deterministic context-free.
[1] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
OTOH, if the language isn't Turing-complete, there will almost certainly be things you'll want a contract to do that it can't. You can have generality or decidability, but not both.
It is possible to have trusted contracts, iff their logic is (mathematically) proven. But the VM can't make contracts more secure by itself.
Suppose a non-Turing-complete language were used instead. Now, imagine a contract that is highly complex. If a layperson decides to trust that contract without reading the code, does it matter whether the language used to implement the contract was Turing-complete or not?
I'd argue that trust of contracts is pragmatically more of a social concept than a computational concept, since at scale the vast majority of contract users would make their trust decision about a contract based on non-technical factors.
Um, yes? Literally the point of weaker languages in this context is that they can be statically provable.
Being Turing-complete means it's possible to write some contracts/programs for which certain features are undecidable by analysis.
It doesn't mean that programs that could be also be written in any more limited language can't have all the properties about then that could be proven in the non-Turing complete language proven when written in the Turing-complete language.
> It is possible to have trusted contracts, iff their logic is (mathematically) proven.
Trustworthiness of programs (including “smart contracts”, which are only loosely analogous to traditional contracts) is about whether the actual people using them get what they expect out of their behavior. Mathematical proofs of formal properties may be useful to that in some cases, but are not generally sufficient.
The idea that we will ever stop needing human arbiters is laughable and pure hubris.
Maybe if the contracts had more constrained semantics ETH programming would be less scary, at the cost of some bells and whistles or more verbose syntax.
Based on other comments here there certainly may be questionable decisions in the design of Solidity but that doesn't mean Turing-completeness is one of them.
Arguably unclear termination semantics would be a good reason not to trust a contract. Ideally trust mechanisms would exist such that closed source contracts were trustable via a pure insurance-based mechanism.
Ethereum programs aren't Turing complete. They always halt. Turing complete programs don't generally halt. That's the definition.
You should demonstrate your understanding by using these terms correctly!
This whole argument about Turing completeness is a huge red herring.
The Parity multisig attack was an extremely simple programming error that has nothing to do with Turing completeness.
That people put their trust in such a contract despite its source code being obviously wrong points to the real problem.
The real problem right now is the lack of convenient tools and established practices for formal verification. If you think formal verification is impossible for EVM, you're wrong and you fundamentally misunderstand computation.
I've seen this criticism over and over again on internet forums: "EVM is so stupid, it can't be formally verified because it's Turing complete."
It's totally wrong: EVM isn't Turing complete, and it doesn't matter.
Look at "The Art of Computer Programming." It's full of Knuth's proofs of the correctness of algorithms written in assembler and imperative code. Look at any proof of correctness of a sorting algorithm.
OBVIOUSLY you can prove the correctness of programs written in Turing complete languages. You just look at the specification of the language, formulate a specification of your program's intended behavior, and then prove that the code matches the specification. This is how formal verification works, regardless of Turing-completeness.
To clarify, what is the impact of Turing completeness on formal verification? It means that for some ARBITRARY program, you cannot ALWAYS prove that it halts.
But even with some non-Turing complete formalism, you obviously cannot automatically prove the correctness of an arbitrary program; that's just nonsense. You could be certain that the program halts, sure, but how valuable is that? Ethereum already guarantees that all programs halt using the very simple gas mechanism.
Did you actually read my post? I'm not claiming halting is a problem; it's merely an example of undecidability. The "gas limit" doesn't help in the cases where the program does halt with unexpected behavior.
> Turing complete programs don't generally halt. That's the definition.
Where did you get this nonsense? See [1] for the actual definition.
> attack was an extremely simple programming error
Yes, which is why it's stupid to use a language with a grammar that cannot be proven. If trivial mistakes happened in production code, how do you expect to find the subtle bugs that happen because of the complex interactions that occur in recursively enumerable grammars?
> prove the correctness of programs
You can do that for some programs, but not all. The point about grammars is there are classes of grammar that allow automatic verification. Using a recursively enumerable grammar instead of a regular or context-free grammar demonstrates a severe misunderstanding of either language theory, or secure/safe engineering practices.
int_19h description[2] of some of the insane parts of Solidity suggests a PHP-style fractal of bad design[3], not a platform for proving correctness.
[1] https://en.wikipedia.org/wiki/Turing_completeness#Formal_def...
[2] https://news.ycombinator.com/item?id=14810008
[3] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Here's how reasonable Ethereum contract development should happen. You construct the contract, either in some high level language or in bytecode. Then you prove, using some reasonable formalism (TLA+, Isabelle, paper, symbolic execution, or whatever), that the contract does what it should do. Then people who want to trust the contract look at this proof.
This is not at all hindered by the EVM being quasi Turing complete, because at no point do you have the question "How can I mechanically verify halting of an arbitrary program?"
If were really that bad to use Turing-complete code, then smart contracts would be the least of our problems, because Turing-complete code runs our airplanes, medical equipment, and nuclear reactors.
Of course, the code is deterministic and so the behavior was unambiguously defined in the contract's source code.
But there exist all sorts of semantic bugs, which can at times be pretty subtle, which means that even for an expert, the mental model of code execution may not match reality.
If there were nondeterministic behavior in the Ethereum VM that would necessitate a fix to the VM and would likely be completely uncontroversial.
> The crypto currency space is currently so fraught with fraud and crime
The lack of KYC requirements has led to some criminals using cryptocurrencies, but BTC is fully public and so money laundering, counterfeiting, and tax evasion both go away when we move to a public blockchain.
Those three crimes are all so much bigger and more costly to society than the petty crime that has fled KYC to use the blockchain that I think the truth is the opposite of your insinuation.
So you believe that all the public mixers are compromised? It's certainly possible, but even so, they clearly aren't publicly compromised, and as such, I'd argue that tracking down large amounts of money moved conventionally is easier than tracking down large amounts of money through the blockchain, as last I read, traditionally, btc was sent through mixers quite often.
If a person isn't linked to KYC in any way and the coins are anonyously owned, then it's a bit harder, but as BTC becomes more mainstream it becomes increasingly difficult to prevent most transactions from touching KYC-regulated accounts.
As a borderline anarchist I'm not arguing this is a great thing, but it nonetheless offers a much more efficient path to enforcing money laundering laws.
FWIW I suspect some are compromised. Also, mixing adds cost, and so even if money laundering happens but is heavily taxed by this additional cost there is some utility to the blockchain based system.
Adding on N redundant insurance contracts increases the total cost of insurance by N * value * r * time, assuming that the risk of insuring another insurance contract is extremely low. That number explodes extremely fast, and there's no obvious way to solve the problem apart from buying insurance without blockchain-based proof of solvency. But if you're doing that, why do it on the blockchain at all?
Your argument is valid, but consider that most contracts execute very quickly and so the scope of the insurance is quite limited. For more elaborate contracts, or for a set of inter-related contracts, insurance will be available for highly demanded combinations.
Also, since much of the insurance is against fraud, as parties became more trusted the price of insuring against their bad behavior would decrease.
Insurance is and has always been a profitable business simply because pooled risk is desirable in many circumstances. Blockchains don't alter this basic reality, and they make it far cheaper to offer proof of solvency and other meaningful transparency measures that benefit consumers.
Consider, for example, if employees could do a solvency audit of the PBGC at the click of a button.
We're basically in no true Scotsman territory here.
In a group of actors, trust is a good thing. It benefits everyone, and everyone has an incentive to foster its development.
In meatspace systems we rely on things like identity verification (id cards, green bar certs, fingerprints, retinal scans, etc.), reputation by affiliation (resumes, schools attended, firms worked for) and and testimonials from others we trust.
The key aspect of the above is that we don't have to trust any of those signals perfectly in order for it to be of some benefit. If I find out someone went to Harvard, is followed on Twitter by Marc Andreessen, has had five commits accepted by Linus, has a credit score of 675, uses Android, has bad breath, etc., I will take each of those signals as some indication of her credibility on various issues and formulate my meta-opinion about how/whether to trust her based on some heuristic.
When I order from a seller on Amazon with very few stars I take a similar risk, yet once in a while I do so. Some fraud is taking place on Amazon but on balance the system gets more trustworthy every day.
Which would make such contracts significantly more expensive than regular contracts that are reversible by trusted intermediaries and legal authorities.
Paying out insurance claims is much more expensive than simply reversing a transaction. This is part of the reason Bitcoin never took off as an alternative to credit cards. Consumer protections are much more expensive to wrap around immutable transactions.
You assert this but don't offer proof. The cost of fraud is baked into all areas of our economic system to the point where it's very difficult to establish how much it is costing society. Arguably the massive innovations in counterfeiting prevention in the past decades indicate that counterfeiting is a major problem. Money laundering and tax evasion are the other big crimes that impose significant social cost which public blockchain systems solve beautifully.
The larger a percentage of the economy that is transacted via a public blockchain, the less opportunity for all sorts of crime. The existence of the "trusted intermediaries and legal authorities" as well as the elaborate enforcement mechanisms that accompany them, are themselves a cost.
> This is part of the reason Bitcoin never took off as an alternative to credit cards
This does not make sense as Bitcoin is not a mechanism for extending consumer credit.
> Consumer protections are much more expensive to wrap around immutable transactions
Protections against what? Confusing interest rate terms or cards sold to college students? Bankruptcy or minimum payment rules? All these sorts of things would apply equally to a credit card denominated in BTC so I'm not sure what you mean.
Fraud is a function of humans not the currency. The reason large systems to protect from fraud are baked in, is because there are a lot of humans that commit fraud. The blockchain would only provide a well documented account of the fraud, with no tooling to remove the assets from the fraudster. Chargebacks are a blessing when you need them and a curse when you receive them, but something that the economy has deemed a necessary evil mostly because there are a lot of fraudsters in the world.
This is an excellent point, and I think it's an example of how an institutional mechanism evolved to help address fraud.
There's absolutely no reason to think chargebacks would not come to exist if commerce were dominated by ETH or BTC transactions.
The difference is that the infrastructure to do chargebacks, merchant account underwriting, etc., can be built very easily with relatively few lines of code.
I'd argue that rarely in meatspace finance is the consensus mechanism considered separately from the other aspects of a currency that matter. Consensus at changing aspects of a currency typically fall upon a government organization which has its own politically-driven, non-transparent consensus mechanism.
In meatspace, we have things like bankruptcy law and its derivatives to help preserve order when contracts unwind.
Of course, provisions for unwinding an agreement in an orderly way are part of any sophisticated financial deal. Meatspace contracts bootstrap on existing legal interpretations and regulations, but those things mainly add convention, repeatability, and predictability to the behavior of the contract.
So when (if ever) does the consensus mechanism in a fiat currency actually matter? I'd argue that it matters when the sh*t hits the fan, when there is an economic shock and widespread demand for action. This is when the stupidest decisions get made and the rule of law is the weakest.
Hedging against these stupid decisions adds tremendous cost and friction to meatspace financial deals. While it may feel right for regulators to "make whole" certain parties, that is not necessarily in the interest of the rule of law. It's far better if the various contingencies are addressed before the fact so that they can be priced in accurately.
Systems like Ethereum have the potential to create (over time) a set of useful and inviolable rules that can allow transactions to take place without the costly hedging against stupid, knee-jerk decisions by regulators.
In order for parties to willingly enter into contracts, the desirable state is not that later some wise overlords will take a look at the contract and make a fair decision about some yet-to-be-determined aspect of it. The desirable state is for the contract itself to be 100% trustworthy.
Of course, with the infamous hard fork, Ethereum failed at this once, but ETC exists now in tandem, so the two governance approaches can compete on their merits.
Distributed blockchain consensus give us a more transparent consensus mechanism than ever before, which is crucial to democracy. On this bedrock, it will likely be possible to create a world where we truly have the rule of law, not the rule of men.
The point here is not that smart contracts are "law", it's that the execution of a contract should take place in an unbiased VM, and the transparency and consensus mechanism of ETH ensures that.
This is exactly right. Once you empower trusted intermediaries to police and reverse transactions, you lose cryptocurrency's primary raison d'être.
I don't think this is accurate.
Let's talk about intermediaries:
I buy a shirt online using cryptocurrency. The merchant teams up with an intermediary to ship it to me.
I buy a shirt online. I team up with an intermediary to verify that the merchant ships the product as promised in exchange for a small fee.
I buy an electric skateboard online. I view reviews written by intermediaries about their experiences and watch some videos those intermediaries have posted of them riding the boards over various terrain.
I make a transaction where I am asked to commit money upfront without receipt of any goods. I use an intermediary (escrow service) to hold the funds in a specifically sanctioned way, to avoid the risk that my counter-party is dishonest.
None of these things are replaced by the core mechanisms of a cryptocurrency. Cryptocurrencies just make some kinds of trust more efficient to establish, but it still must be established and in most cases cryptocurrencies don't offer mechanisms for it. Ethereum does, but in a way that necessitates trusting the behavior of smart contracts, so it's a building block for efficiency and scale, but not a replacement to the core human institutions that involve intermediaries.
I take note that you have reduced the claimed value of cryptocurrency from decentralization and immutability to mere "efficient trust establishment". However you are still making a totally unsupported claim that it is more efficient that existing methods (e.g. getting a credit card or payment processor). Considering the enormous energy cost of mining you will need to offer some support for that. Otherwise it's just frothy hype.
Talk about unsupported assertions. You do realize the article you're commenting on is titled 153K Ether Stolen in Parity Multi-Sig Attack.
Others have noted your confusion about what "consumer protections" means. It is patently obvious that paying out $153,000 in insurance claims would be more expensive than reversing the fraudulent transactions.
I think if you examine all the assumptions leading up to your conclusion you may find that it is erroneous.
You simply believe that we "should" not trust intermediaries, which is fine, but you must accept the consequence that consumer protections will be weaker and/or costlier to implement. This is why Bitcoin was for the most part never more attractive to consumers than cards.
Does that argument still hold up if you're going to have human insurance and human arbitration?
I think it does. You don't need human arbitration, but there are so many cases where having it makes people more likely to transact.
Similarly, a hotel can put up a rack with brochures in the lobby, or can hire a concierge to smile and interact with guests as they walk by. The purpose of the concierge is to create more transactions than would have happened with a rack of brochures.
As for the question in the previous thread, I'm not sure if it's worth the energy expenditure or not, but predictions are that energy will cease to be scarce by 2030 or so.
1) moral hazard/information assymetry - If I insure you against fraud I have removed most of your financial incentive to protect yourself, so I need to have some other reason to think that you will. I also need protection against the fact that you have more information than I have about the risk of fraud (how do I know you won't collude with the fraudster, in effect defraud yourself and collect on the insurance?) In the normal world this category of concerns prevents lots of types of risks from being insurable, and we have criminal law to protect against collusion 2) Capital commitment - It's not sufficient to just get a promise from the vetters, the capital has to be committed (ie escrowed in some way) otherwise how do I (as an insured party) know they will make good on their payment when I need them to? As an insured party I have to be able to verify that you have done this. In the normal world, this is handled by regulatory capital guidelines for insurers and counterparty collateral posting in the world of OTC contracts. 3) Network effects - If I have capital in escrow, the contracts protecting that escrow would presumably themselves become extremely high-value targets for fraud. Can they be insured? How would you know that the capital is committed to pay out on these insurance contracts? Escrow again? This is a very significant bootstrapping problem - how do I as a participant somewhere in this chain know that in the last resort my insurance will be able to pay out so that if need by I can make good on my commitments. In the normal world this is handled by central counterparties demanding collateral posting against open contracts.
It's very tempting for engineering/technical people to assume that even though they don't really understand all the details, everything has an engineering/technical solution that would be so much better than what has been developed by their predecessors. This disruptor's hubris is necessary for progress to be made against very hard problems otherwise they would probably be to daunting to tackle.
Trust in the existing contract law system has grown organically over a very long period of time. Some of the smartest people going are lawyers and they've had a significant head start on these problems. It would be pretty difficult for trust to evolve organically given some of the poor decisions and scale of subsequent fraud that has already happened in the "smart" contract world.
You point out the non-trivial nature of building a system like we have today. I'd argue that Ethereum, with smart contracts and an immutable public blockchain is a useful innovation that I consider a useful building block for creating and improving the kinds of institutional relationships and interactions that you describe.
A system of insurance implemented on Ethereum would need to have the same sorts of moving parts that you describe. Ethereum would make some aspects of this harder and others far easier.
There would still be a need for collateral, escrow, etc. My comments are not meant to argue that these mechanisms become useless, they simply become more transparent and when viewed in terms of the rule of law, become significantly more resilient when markets become politicized and the rule of law is in danger of breaking down.
Things that would potentially be far easier in an Ethereum based system would be:
- assessing/auditing the books of an entity. Things like proof of solvency become much easier, and also looking at assets which are accounts receivable that depend on another entity's solvency. The modern financial system has very course-grained and inadequate ways of looking at this sort of systemic risk, which makes cascading firm failures truly devastating and nearly impossible to insure against, since any cascading firm failure will involve many ad-hoc regulatory interventions and rule changes that essentially nullify a large number of pre-existing contracts/hedges that might have existed.
- forcing precise regulations. One of the pre-2008 meatspace glitches was the too-little-too-late regulatory decision to force firms to mark certain types of assets to market even if their accounting approach determined that doing so inflated or deflated their balance sheets incorrectly. With a public ledger it would be possible to easily test a new accounting rule's impact on a firm's financial statements.
[1] https://blog.ethereum.org/2016/06/17/critical-update-re-dao-...
Inflexibility is not an advantage unless you're dealing with formally describable, proven systems. Human behavior and economics are not.
Printing money was part of how we got out of it. https://en.wikipedia.org/wiki/Quantitative_easing
Maybe you should replace the word "Ethereum" with "sotware". "Software in general makes sense is all the following are true"
Software in general doesn't exist in a vacuum - it's backed by all the centuries-old meatspace institutions like common law, courts, and lawyers that provide a recourse when something goes wrong. As I understand Ethereum's whole purpose is to replace a lot of these institutions with "smart contracts" (correct me if I'm wrong). If Ethereum has to rely on the same institutions as every other piece of software to deal with contract disputes isn't it just adding more complexity to transactions?
Now, I'm skeptical of Ethereum's suitability in this space - the design doesn't seem to be geared enough towards correctness. However, they've also done some things that I really like (e.g. rolling back The DAO), so I'm not counting them out just yet.
To clarify, my point isn't "software has bugs! don't trust it for anything". My point is "software has bugs! don't make it the forum of last resort for contractual disputes".
The theft wasn't due to an issue in the core protocol of Ethereum, it's due to faulty code in a single piece of software (as you can see throughout the rest of the thread).
It's a matter of poor engineering practices, not a flaw in the fundamentals of the protocol.
If an engineer designed a bridge, and it failed due to a flaw in the design -- say the math on a strut's angle was bad and the bridge collapsed causing millions in damages and took a few lives. Do you blame steel, all steel, and everybody who uses steel in construction as foolhardy? Or do you blame the engineer, the safety inspectors, and the company that oversaw the project?
Would you blame the the steel (or the concept of bridges in whole) for the Tacoma Narrows bridge waving in the wind?
In essence, TCP/IP is engineers trying their utmost to design a system where a single flaw doesn't result in the whole data stream being corrupted.
Add HTML browsers into it, which is extremely tolerant of input mistakes and you have a total system that will handle random losses pretty well.
The protocol doesn't offer any recourse itself, and the end user who might suffer because of such an attack has no defense. They rely on the ability of the engineers involved and some technical voodoo they don't understand to keep everything safe and working for them. That's my point -- I wasn't comparing the technologies directly, but their roles in a larger system.
True enough, but what the parent pointed out is that this class of problems is due to a flaw in the core concept of Ethereum - which is much worse than just a flaw in the protocol.
To extend your analogy - Ethereum is like if a company advocated for building bridges using a process that made the bridge's integrity unverifiable using traditional engineering means. Some bridges may hold up, some may fail, with no clear way to identify which bridges will do what.
Even so, any product designed for the network could be tested to death on any of the available testnets. It would be foolish not to ram any project up against everything in that environment, which is why I suggest poor practice as a primary cause.
It was an oversight, to be sure, and a major one. (that's not nearly strong enough language, but I want to be civil)
Let's assume you're right and smart contracts are verifiable. Verifiable by whom? I can assure you that my non-techie friends could not verify a smart contract themselves, so they will have to trust some authority that verifies the contract for them. The chain of trust now moves entirely into meatspace again and will be subject to the same economic and social forces as existing financial systems. So what has Ethereum accomplished other than adding an automated intermediary to transactions?
For a real-life example of what this might look like consider HTTPS. In theory SSL allows you to cryptographically verify the identity of the site you're looking at. In practice your ability to do this is still bounded by the competence of third parties like browser vendors and the integrity of CAs issuing certificates.
The code is verifiable by a skilled engineer (in good faith) -- so there is a catch. Any body that produces a smart contract requires the trust of those who take part. Alternatively, it requires trust in one's own expert engineer to verify the content and functioning of a smart contract.
Where Ethereum is trustless is in the execution of the contract once verified. There is then no course for non-delivery if the code is designed this way.
So, it's trustless at one level, and requires trust at another. When I say it's semantics it's just this last point.
Personally I don't see the problems other see with that, because I don't see blockhain tech and tokens replacing everything all in one go, including the need for governing bodies and law. I don't see it as a choice between one or the other. For what it's worth, I'm closer to a socialist than the usual libertarian ranks that flock to these things. I think the world would benefit from the efficiency it could bring about, once the kinks are worked through.
So, yes, in reposting I generalized from "smart contracts are a bad idea" to "Ethereum is a bad idea". Considering how essential the smart contract is to essence of Ethereum, I feel comfortable making that generalization.
Side note: "the essence of ethereum" would make a great subtitle for Drakkar Noir.
To use your analogy - I'd view the bridge design engineer as having guaranteed that the design process could not possibly result in construction of a bridge that fails. That seems closer to what Ethereum would have us believe.
A bridge design domain expert presumably understands: - that design process uses strut calculations (and therefore includes measures to guarantee those calculations can never be wrong); - that bridges may be built from steel (and therefore includes inspection routines that guarantee faulty steel can never be used); - that the environment acts on bridges through corrosion and earthquakes (and therefore includes routines that absolutely always preclude failures arising from the bridge's environment); - etc., etc., etc.
Maybe it's just my ignorance or misunderstanding of this domain, but I see Ethereum as naive in its guarantee of perfectly predictable behavior.
A guaranteed flawless protocol that fails (for whatever reason) when implemented in reality, isn't.
The engineer who wrote the contract appears to have made a critical logical error.
That does bring me to your conclusion, though. I've paid less attention to the marketing and promises and have assessed the technology as-is (within the confines of my knowledge) -- as such I see what's possible instead of seeing it as a product that under-delivers.
I wonder if a lot of people (especially on HN) would view it differently if it weren't for such bold claims on the developers' part. I mean, I think you're probably right in it being naive in its guarantee of predictability. I think any actors on the platform should assume its supposedly perfectly predictable behaviour is not quite so when they take to designing software or a contract. But that's part of what I meant when I've said it comes down to engineering practice -- when it comes to critical systems assumptions just shouldn't be made in young technology no matter what anybody tries to sell you.
If Ethereum becomes popular enough, one day the participants in an Ethereum contract are going to sue each other, and the judge is not going to be impressed by arguments that the contract is intended to be immutable. You can't opt out of contract law just by saying that you opt out of contract law.
It just doesn't work like this.
But civil society is the opposite: Contracts cannot violate the law; the law cannot violate the constitution. The justice system would care about the terms of the DAO only insofar as those terms fail to conflict with the law, which includes a massive body of precedent in contracts and torts.
Point being, immutability is not sufficient to demonstrate that a contract is in conflict with the law.
Agreement is not the only prerequisite for a legally enforceable contract. The contract also needs to avoid certain unenforceable things like unconscionable clauses, or agreements to do things that are illegal.
Because the purpose of a judge is to interpret the law, not enforce Ethereum software invariants.
But that's basically obvious to anyone not hinging their personal identities on peddling technocratic revolution.
In many cases I would assume the opposite will occur: plaintiffs will claim that there was no contract formation because because the technical mumbo-jumbo of computer code is incomprehensible to a layman.
I suspect that courts will react quite favorably to this argument seeing as how they have a natural interest in maintaining their jurisdiction.
Why give up those rights and let a computer program (or rather, it's creators) dictate that you're screwed if you make a mistake? I mean, contract law exists because that kind of strict arrangement proved unsatisfactory in real life in the past.
In that case the judge can't do shit.
If you want the protections of courts, there is already a perfectly easy way to do that. And that is to use a real contract.
But if you explicitly do NOT want that, and explicitly DO want code to be law, that is what ethereum is for.
a judge can't take away the crytocurrencies of some anonymous other party.
> In that case the judge can't do shit.
In the latter case, I'm pretty sure that (even leaving aside other mechanisms that might apply), judges and courts exist in Russia. Agreements where the parties are based indifferent countries have long been a thing, and long been enforceable by courts.
Unmasking anonymous parties, obviously, can be (though it is not always, even where it must be done) a prohibitive burden to legal action, OTOH.
Let's say we have an uncertainty scale scored 1-100. If 100 is "money in a bank" and 1 is "money that's already been set aflame, but there's a cup of water nearby", I'd put Ethereum in the low single digits =)
These newfangled experiments that I don't fully understand are still well above 10 for me, but they only have to get down to around 11-15 before I'll be interested.
Why is there no "pen-test" phase to any crytocurrency which hits the market.
So, let me understand; you're ostensibly smart enough to (perhaps as a body of contributors, even) develop a cryptocurrency offering - yet youre also fucking stupid enough to not have same/wider network of ppl attempt to hack the fuck out of your plan?
Does this already occur? or some savant comes and owns them?
We have fucking HIPPA FFS and the compliance systems for something as trivial as my stupid name.
so; ELI5: WTF are currencies doing/not-doing which allow for such hacks (1) and allow for exploits to go unseen (2)
It's more like a company's open source software allowing somebody to steal your bank password. It doesn't have anything to do with USD or the Fed, or even the bank's larger practices. It has to do with how negligent they were with regard to a particular feature.
Each of these situations is a painful learning experience, but moves the platform forward.
I remember it as "hippo", or "H-I-P-P-Oh darn, I spelled it wrong again!"
What?!? That seems like a pretty relaxed response for someone who just lost 8m dollars.
The initWallet function should have been marked internal, but was instead not marked. Unmarked functions default to public in Solidity, so anyone can call that function and reinitialize the wallet to be under their control
the work being done on public blockchains is unlike anything else done before. You don't have he luxury of keeping your db behind a vpn running on a vm platform secured and maintained by the worlds largest companies. These engineers put themselves out there, waaaaaaaay out there to try and make shit happen. And they mostly do good work. But if banks and major retailers who have huge budgets can get hacked, of course we can too.
They did put themselves way out there, and that takes ambition, but also hubris. I wish they were able to figure out which one was driving them at certain points a bit better, as while some of these problems are because they are doing new and interesting things, some are old as dirt for computing, and there's little defense.
If some company tried to tout a new language with all the pitfalls of C, but none of the benefits of being really inter-operable and known the same way, I'd like to think we could recognize that as having some very bad design choices given what we've learned from C, and at little benefit other than being different. Ignoring decades of research and experience on the topic through ignorance is not laudable, even if you've put yourself out there. I can't help but feel we have a similar scenario going on here.
I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually used. Some tried doing them in Bitcoin, but Ethereum's the first that gets lots of action. And so many other blockchains lift the smart contract functionality straight from Ethereum.
As far as I can remember, the EVM has never failed, just programmers.
The register globals issue could have been avoided at very little cost, if any cost at all, to the popularity and spread of the language and many millions of dollars and much personal information would have been saved.
Because it's a financial system, and normal sane people don't want money that is demonstrably worse for nearly all the things that normal sane people do with money.
Ethereum is a great political statement, and a fun toy... but when you recast the worse is better story into this context, you're just demonstrating that you don't really understand the meaning of the words that you are mindlessly parroting.
Thanks for warning us that you're about to release a terrible book, with an incredibly stupid central idea.
You might as well have just written that MySpace is the future of social networking. Because while crypto will have an interesting place in the future; only a complete moron would make the argument that Ethereum is a success, or that worse is better applies here. Congratulations on being that moron.
I spent about three thousand words on the smart contracts chapter, attempting to conclusively stab this bad idea in the face and supply a suitable rhetorical ammo dump for anyone faced with having to deal with these things to kill the idea stone dead. Absolutely everything about smart contracts is terrible and misconceived. I don't believe there is any way to do them right, because the idea is fundamentally wrong.
Here's (an older draft, need to update) what I actually say about Solidity and Ethereum smart contracts: https://davidgerard.co.uk/blockchain/ethereum-smart-contract...
So if you're talking about Ethereum as a bad implementation of a good idea, you're weighing up reality against something that was a hypothetical from 1994 to 2014.
In any case, there's plenty really obviously wrong with the idea of immutable smart contracts. Legal code is a bad match for computer code; immutability means changes in circumstances can't be allowed for; immutability means you must code with zero bugs; the oracle problem (getting real-world data in and out of your smart contract) ...
"Dr. Strangelove" is the story of a smart contract going wrong, unstoppably, immune to human intervention.
Szabo's stuff is better than the reality - he does actually understand law as well as code, and at least early on he considered there was a role for human intervention - but it's still the sort of thing that's "interesting" rather than "a good idea".
If it's important, you need to be good. If it's very important, you need to be good and sure.
The Ethereum developers sold a vision of smart contracts, where the code is the contract. However, their hubris lead to them attempting to implement a complex language, instead of starting the endeavor with a small, simple, verifiable language. Similarly, their belief in their own infallibility lead them to write code that is not tested, and to create capabilities that are literally untestable.
This was bound to result in multiple massive failures. The dao was one. This is another. There will be more, because it's an overly complex implementation.
It doesn't matter, though. Only dumb-fuck crypto futurist suckers have ether exposure, so it won't matter that they get zero'd out once a competent team enters the space. That said, the space attracts incompetence like lights attract moths, so it'll take a while to find a team that is technically competent and also has the marketing chops to get traction.
This space doesn't atract incompetence, it atracts everyone. When you have tech thats so transparent and accessible, degrees and diplomas don't get to decide who can or cannot work on it. Plus, the world most experience blockchain developer has at most, 9 years of experience. That's not a lot of time to work out the kinks.
https://news.ycombinator.com/item?id=12130282
It would be nice to see some sort of casual hawala-type federated micropayments system based on real national currency, with instant settlement, low fees, and no fake money value store. But, that would be a pre-9/11 idea. Nowadays that's basically illegal and useless.
Paypal is more or less good enough, and hopefully regulators and market forces will control the fees and abuses.
Thats the vision- a somalia like decline, but society moves on, with schools back uped to youtube, with contracts backed up to the block chain, with the currency back uped to bitcoin. I find the ideals of crypto-anarchy laughable (those guys would be gunned down on the first corner, in a real anarchic world), and yet, i can agree to the path we taken. Cellphones and facebook, to have a culture of shame, that fights wild mobs and public hysteria, because the internet does not forget your lowest point. Anyone in power in fear of getting caught in public, for the world to see as just another corrupt, well fed monkey?
Yes, that is something to work towards.
And in this Somalia 2.0 future of yours, how will the computers and networks be powered?
Here's the thing: banks and major retailers can't get hacked. At least, not in the sense you're using "hacked".
When Target's credit card systems were compromised, resulting in the CEO resigning and and about $300M in costs to the company to deal with the breach, not one customer lost a penny.
When $171M from Union Bank of India was fraudulently wired via NYC to two Cambodian banks and one Thai one, they got all the money wired back within a day.
The traditional banking system is designed to be unhackable, because the numbers on computers are not authoritative. They're a cache, and they're periodically reconciled, but humans (and other computers!) will look at the cache during reconciliation for obvious attacks like these. A bank can call up another bank, or a retailer can call up a credit card company, or whatever, and say, "Hey, these transactions were fraudulent, please reverse them," and it'll happen. Target did that. Union Bank did that. A hacker can get to some bank's MySQL database? Sure, whatever, it's not what matters. Definitely it's a greater headache than if they got to the bank's website, but at the end of the day it's exactly as fixable as hackers getting to the website.
There are a lot of bright people trying very hard and putting honest work into a problem that simply doesn't need to be solved and shouldn't be solved: making the computers authoritative. When you do that, you're suddenly hackable. When you do that, of course $16M gets actually stolen irrevocably from time to time, no matter how bright you are or how honest your work is.
However, whatever financial risk you would like to tolerate, you should make sure you're pursuing goals that do in fact match that financial risk, and that you're not concluding that something more or less risky than it is because you are uninformed. Also, if you are tolerating increased risk, you should do so because there is a purpose for it (e.g, better potential upside), not because high financial risk seems inherently cool. It isn't, and I will certainly defend that point, but it's just a lemma on the way to my actual point.
Arguing that it's okay that cryptocurrencies are hackable because the traditional financial system is hackable is simply factually incorrect: it's a misunderstanding of why the existing financial system looks the way it does, and why its risk tolerances are built the way it is (not a lot done to secure transactions, but a lot done to be able to reverse transactions if needed).
If you really want a simple point out of me, I think G. K. Chesterton made it in 1929:
> In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
If you do not understand the existing financial system, you cannot honestly claim that your new one is better. First figure out how it works and why, and get that right, then you can describe how your changes are improvements.
If cryptocurrencies think that they can provide this service for substantially cheaper than 2-3% (note that this is an additional service on top of simply making the transfer happen, so mining fees aren't the right thing to compare), that sounds awesome, but also I'd like to understand why it's possible.
If so, this seems terrifying, what if I had accepted stolen ETH to sell physical goods?
I.e. if you accept counterfeit money, it's on you, but your money should not become counterfeit overnight.
But yeah I admit, cryprocurrencies are good toy projects on which to learn real crypto, that's true. But then it's time to move on. And not to pour millions of dollars into that
You've done this repeatedly, it lowers the quality of discussion, and we're hoping for better than that here. If you have a substantive point to make, make it thoughtfully; otherwise please don't comment until you do.
But yes it seems pretty asinine to use global by default for (not so) smart contracts.
Anyway, I think parent's point was to say this behavior already has been seen in javascript. Actually, it may even be inherited from javascript. When I first looked at solidity last year, I was under the impression it was a modified version of javascript, like unity3d's one. Nowadays, solidity landing page reads "high-level language whose syntax is similar to that of JavaScript", so not sure if it still is (or has ever been, for the matter) derived from something like v8 or rhino.
The reason for that choice seems not far fetched : it's not uncommon, when wanting to add scripting to something, to go with javascript, since it's arguably the most known language, developers knowing "<their main language> and javascript", especially webdevs (a blockchain app project, lisk, even made html/css/js the defacto mean to build apps). Of course, fintech is an industry where the usual values from webdev (release early, release often) have disastrous results.
Language design is actually notoriously difficult in general[1], but if you're doing language design for a security-critical language[2]... well, that requires actual mechanized proof, IMO. Not just proof of "design", but proof of the implementation. Anything else is a huge gamble. (And I'm sure there are some 'investors'/gamblers who made off very well.)
[1] Beyond surface-level, obviously.
[2] We're talking about 0.0001% of the general population here.
Absolutely, few people really get this. Even those that do get it generally don't know what it looks like in practice because it's so rare.
In case you're curious about what it looks like in practice (at least one way), we presented direct user code compilation and verification[1] in Jan for our smart contract language Pact[2].
The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts. For the first few days that the system started working (I built the FV portion, Stuart the language + H-M type system) I thought it was broken... turned out we just had a bug in our demo code that we never noticed.
Usually, tests check the things you know to check so when they find something it's not a surprise what they find. Sometimes you can fuzz and randomly find something, which is cool but doesn't guarantee that there isn't a problem somewhere else. However, FV just feels uncanny (as a dev) because the test either finds a problem in the code -- and tells you how to replicate the bug -- OR proves that a problem cannot exist.
[1]: https://youtu.be/Nw1glriQYP8?t=1071
[2]: kadena.io/pact
I'm not sure I understand this sentence. Are you doing doctests, or are your doctests statements of formal properties, or have you abandoned that and are now doing formal specs->code type things?
(I mean, I understand the pressures of academia, but... ridiculously bad timing, yeah?)
At some point, it's time to blame the tool and not the user. Moreover, it's not like people didn't see this coming, myself included[1]. I mean, who really thought that basically taking JavaScript and swapping out the DOM for a bank account wasn't going to end badly? But then again, maybe I've spent too much time at in the SEC/finance where "move fast and break things" engineering gets you shown the door quite quickly. That mantra's fine for a number of domains but finance isn't one of them as one bug can bankrupt the company (see: knight capital).
It really just underlines the need for a safer/better approach. Formal Verification has to be part of that story. A language that was designed with safety in mind has to be another part.
Also, not an academic (yet at least). Cofounder here: http://kadena.io
[1]: https://goldsilverbitcoin.com/jp-morgans-blockchain-research...
I don't see any justification for this statement. The bug could easily have been discovered if there had been better auditing. That the auditing missed the bug doesn't prove that it's "practically impossible" to write secure code with Solidity.
In any case, nothing is stopping you from porting your formally verifiable language to Ethereum. The EVM is not Solidity. In fact there is already a project underway to create a verifiable programming language for the EVM.
Honest question, what would be required in your opinion for before we start considering if the tool is at fault? I ask because, if you're of the opinion that it's never the tools fault then I'll never be able to justify my point of view. Which is fine, we can disagree. I'm all for massive experimentation in this area and thus need people who disagree with me to do research down the other lines.
Also, it's not that I think it will always be practically impossible just that currently (and for the next several years at the very least) it is. We'd need way better tooling and the type of tooling needed is incredibly advanced stuff. We're not talking about a build system here, we're talking about formal verification which is one of the most advanced tools you can build. I can only think of one tool that can formally verify user generated code (cryptol) and even then it's only for a small subset of C/Java that applies to crypto work.
It's not that you can't write safe solidity contracts today but that IMO an element of luck is required. You need to get the right auditors, have them do a good enough job, implement the logic a certain way instead of another and thus avoid a bug no one has thought about before, etc... When people's money is on the line, needing luck is terrifying.
> nothing is stopping you from porting your formally verifiable language to Ethereum
I wish this were true but it isn't. We spent months trying to see if there was a way that it would work because we would have preferred this approach. The EVM itself is stopping us (as well as the shape of the Eth blockchain but we could probably have worked around that problem). Pact is interpreted, so while we could make an EVM version technically it's practically unworkable -- there's nowhere near enough gas to run the interpreter. We couldn't compile directly to EVM either as the EVM just doesn't do enough[1] for you. It's closer to a 1980's era CPU ASM than a modern VM (like the JVM). Moreover, the Pact runtime does a lot of things for you (as a safety feature) that the EVM just doesn't have a notion of. Even then, while all of the Pact-compiled-to-EVM code would work and be safe, we couldn't protect it that code from EVM code that doesn't play by Pact's rules. Moreover, supporting all the extra things that Pact does for you would make it, again, run out of gas on EVM.
This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.
That's the thing about having the EVM be Turing-complete, it makes people think that "it can do anything and thus abstracts over the problem thus solving it." This is technically true but not practically true -- all you are doing is punting a huge number problems/required features (like dispatch and module loading) down the road for the language to figure out. In a gas-metered context, every feature the language adds because the EVM lacks it costs gas and thus makes a number of features impossible in practice.
> In fact there is already a project underway to create a verifiable programming language for the EVM.
Mind linking me to it? I collect references to smart contract languages at this point and haven't heard of this one. I know the people working on the EVM + solidity formal verification project personally (well some of them at least) and it's still years away.
[1]: Great technical discussion about EVM here -- https://news.ycombinator.com/item?id=14689792
The programming language being partly at fault is not the same thing as it being "practically impossible" to write safe smart contracts that language, in my opinion.
I was taking issue with your wording, which I think gives a misleading impression of the attainability of secure Solidity code. Your follow up comment is more measured, as it doesn't characterise the need for some measure of luck to write a safe smart contract as writing a secure smart contract being "practically impossible".
Maybe we're using different definitions of "safe", but I think many use my definition, in which case your statement would give them a misleading impression.
>This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.
Yes I am aware of that. There is research being done on possibly switching the EVM to an Ethereum variant of Web Assembly, i.e. eWASM, which will be able to efficiently execute a wider range of functions.
Further on this point, I have to admit that I am not qualified enough to comment on the portability of Kadena to the EVM, so I'll take that back. What I meant to dispute was the notion that formally verifiable programming languages cannot be built for the EVM, which is the takeaway that I got from your comment. A PL of this type is in fact being developed [1].
Thanks for the link to the technical discussion on Solidity.
[1] https://github.com/pirapira/bamboo
Then, in another section of the documentation, when talking about function types [2], not specifying internal or external defaults visibility to internal.
It doesn't seem like the simplest or most consistent way to express these concepts, and certainly not the safest way.
[1] http://solidity.readthedocs.io/en/develop/contracts.html#vis... [2] http://solidity.readthedocs.io/en/develop/types.html#functio...
Your honour, in my defence, the contract clearly specified that anyone could reset the wallet, and if that's not what they wanted, they shouldn't have agreed to it.
So like most court cases, it will simply be a matter of human influence winning the case.
Calling initwallet: https://etherscan.io/tx/0xff261a49c61861884d0509dac46ed67577...
Executing: https://etherscan.io/tx/0x0e0d16475d2ac6a4802437a35a21776e5c...
What kind of brain-dead apes designed this language? This would be a stupid decision in any language, never mind one specifically intended for high-value transactions.
I only wish people had to do that. Shit like this are why professional and civil engineers roll their eyes at the mention of software "engineering". There are best practices and available tools but people employ them far less often than they probably should. In the space, take a look at Kadena's Pact smart contract language. It's not perfect by any means (lisp-religious syntax and its tight integration with Kadena internal constructions, for example) but it is at the least, working on formal verification support.
IIRC, the old Camllight VM was pretty similar (I might misremember, that was literally decades ago); an ML-like language to Michelson compiler is fairly straightforward to write and to prove sound.
I'm happy that they do things the sane way, i.e. focusing on sound foundations rather than on how Javascripty the syntax looks; but I'm afraid the communication isn't as clear as it could/should be. Blessing a compiler for some subset of ML, as a first high level language, would have cleared things up IMO.
The underlying DAG idea has potential. You could have two half-transactions happening on separate subtrees, where A is buying X from B and B is paying Y to A. So A broadcasts "A will buy X from B when B pays Y to A", and B broadcasts "B will pay Y to A when A buys X from B". When the matching half-transactions acquire a common child, the transaction commits. It's a true "meeting of the minds".
You can for example trade user-defined (possible private) assets (tokens) in that way - "Ill send you my bytes for your blackbytes, I send bytes to this address and me can sweep them back after 4 hours, or you can sweep them if payment of X amount of blackbytes is made to my address". It has oracles as well.
> This would be a stupid decision in any language
Facepalm
Wasn't this lesson learned long ago? C# defaults to private on unmarked members. Why would you ever want to default public?
Haskell is a good basis but the developers need to make the API fool proof. E.g. expose limited effects rather than a big fat "IO" type.
So I feel obligated to post the full bit (from wikiquote)
>Wonka: [angrily] Wrong, sir! Wrong! Under section 37B of the contract signed by him, it states quite clearly that all offers shall become null and void if - and you can read it for yourself in this photostatic copy - "I, the undersigned, shall forfeit all rights, privileges, and licenses herein and herein contained," et cetera, et cetera... "Fax mentis, incendium gloria cultum," et cetera, et cetera... Memo bis punitor delicatum! It's all there! Black and white, clear as crystal! You stole Fizzy-Lifting Drinks! You bumped into the ceiling, which now has to be washed and sterilized, so you get... NOTHING!!! You lose! GOOD DAY, SIR! [returns to work]
Yeah, as a kid, I too thought Wonka was serious. It took viewing it as a much older person to see the satire there.
[1] https://www.bloomberg.com/view/articles/2016-06-17/blockchai...
[1] https://www.reddit.com/r/badeconomics/comments/6cnzs8/matt_l...
But I think of this issue in slightly different terms that are more simple.
There's a ton of case law about what constitutes a contract that pretty much all countries have. Clearly understanding the contract you are getting into is a prerequisite for the contract being enforceable in most places.
The simple fact is that this is never going to hold up in court when people start suing.
No one gets into a contract with the understanding that they can be robbed, and that's just okay. No rational person would do that. And I think it's a fair case to say that no rational person did clearly understand the contract as presented and agree to it.
The courts are going to to shut this down, in my opinion.
You can't just write into a contract that you might get stolen from or murdered or whatever bad thing and then that bad thing is suddenly okay.
"Okay, this guy didn't read the fine print on that used car loan. Let's go rape his wife and kids now. He said it was okay!"
That's not how it works. Etherium deserves to get hammered for this.
One of the things that cyberpunks fail to grasp is that people don't want a perfectly immutable, fixed system. They want to feel that their sense of justice and moral righteousness can be satisfied. Stuff that drops people off right at "sucks to be you" doesn't really work; there must be some type of recourse available even if it doesn't have a 100% success rate.
Anyone who wants to maintain power in virtually any setting (communal, corporate, governmental) must create an impression of fairness and equity, at least to the extent that a good portion of the people are not willing to risk their [reputations/jobs/lives] to throw off the "oppressors".
It's not an accident that virtually all powerful corporate bosses and politicians are so image-conscious and superficial; it's a matter of survival for powerful people.
For all its warts, a legal system backed by a jury of your peers is still the best way of sorting out the actual intent of a contract when the shit hits the fan.
I did not assign any assertion or position to the OP, only followed up on his thread about the potential ramifications that ETH backers seriously advocate.
And many people do promote the "code is law, and nothing else" idea -- at least Ethereum Classic stuck to it!
It is fine if you don't like those features. But it turns out that a lot of people DO want them.
The people who want to court system can already use the court system. Now we just have more options and choices.
But if someone wants to, they can make it extremely for that to happen.
Good luck finding the anonymous contract creator that set up their contract by sending money through Monero.
Also, empirically, your claim that courts will get involved with ethereum smart contracts just isn't true.
It is not true, because gigantic scandals and contract theft have ALREADY happened on ethereum, and the courts haven't been able to do shit.
Specifically, in the DAO hack, the affected people had enough political influence to get the entire network to undo the ownership transfer that was the result of their own oversights:
https://www.reddit.com/r/ethereumfraud/comments/6bgvqv/faq_w...
If anything, Ethereum is worse because you have to get the entire network to fork (analogous to a revolution or constitutional convention) to fix a mistake, instead of just getting a judge to rule "okay, that's obviously not what anyone meant".
Furthermore, it's far more unequal, where mistakes only get fixed when they affect the most influential users. Seems like a step in the wrong direction.
A system of laws devoid of all ambiguity and emotion isn't even possible, let alone desirable, because at some point these contracts have to come into contact reality, and the humans in it. And these humans happen to be, well: human.
I guess there's an ideology at play that would love to change humans to fit within their neatly arranged algorithms. And if that means some grandmother loses her house because she signed the wrong smart contract when buying cat-food, there'd be a lot expressions of sympathy on Twitter, but she really needs to understand that it's just not possible to do anything about, because principles etc etc.
Here and there, some of these people may, very privately, consider it a feature of the system that others less intelligent than them sometimes happen to die on the streets because of that one Saturday morning where they didn't audit all 500k lines of brainfuck in that contract for chinese takeout.
With less snark: the idea of ambiguity or emotions as being something negative is a somewhat naive view of reality, somewhere on the spectrum between Star Trek's ideal of Spock and the social darwinism of Ayn Rand. It's most often seen in the currently popular misunderstanding of how judges should behave, and how journalism supposedly used to work.
For an example that maybe is a bit less inflammatory than anything about journalism, check any recent threat about the Google vs Uber lawsuit: the presiding judge is almost a legend for his diligence in learning the technology in the Oracle vs. Google lawsuit a few years back. Yet people criticise him for a lack of decorum whenever he uses language that doesn't pretend to be a robot following an algorithm: "This judge is clearly biased! The contract clearly only says $50,000, and there's no law that gives him the authority to say those are USD. When the defendant says it means Canadian Dollars, it's he-said-she-said and undecidable"
Ethereum, as well as things like IPFS that say "Your content is permanent and irrevocable, don't publish if you don't like that", are non-starters because they overlook this core desire to operate under forgiving systems.
Many unfair or distorted legal regimes exist (including, to some degree, the American one), but they all make overtures toward these principles in some form or another. Ethereum et al must correct this if they want widespread adoption.
Some people do.
Source: I am a person who wants this.
If it scales to be a relied upon social tool, their foot-down rhetoric would likely come under heavy scrutiny.
153,000 / 93,405,120[0] = 0.001638025838
[0] https://etherscan.io/stat/supply
“Churchill: "Madam, would you sleep with me for five million pounds?" Socialite: "My goodness, Mr. Churchill... Well, I suppose... we would have to discuss terms, of course... "
Churchill: "Would you sleep with me for five pounds?"
Socialite: "Mr. Churchill, what kind of woman do you think I am?!"
Churchill: "Madam, we've already established that. Now we are haggling about the price.”
We've already established that they will fork. Now we are haggling about the price.
[1] http://www.goodreads.com/quotes/300099-churchill-madam-would...
"Would you sleep with me?" "Maybe for a million dollars..."
Says it all, I think, whether sarcastic or not.
How do these smart contract deal with the real world? I can see how they can work for things that entirely involve activities that take place on the block chain (e.g., a smart contract that automatically pays a crowd funded project if and only if it meets a threshold for pledges by a deadline, and refunds the donors otherwise).
But suppose our contract is something like I will pay you $X in Ethereum when you deliver to me 125 bales of Surat cotton, guaranteed to be middling fair merchant's Dhollorah [1], delivered at the Liverpool docks from Bombay on the next sailing of the Peerless.
How do we put all of that into a smart contract? Can a smart contract trigger payment only when the cotton arrives? Can it check to make sure it arrived on the ship specified in the contract?
And what happens if it turns out that there are two ships named Peerless, unrelated to each other, one of which is sailing from Bombay to Liverpool in October, and one in December? I only know about the December one, and it is on that one that I'm expecting the cotton. You only know about the October one, and so it is on that one you send the cotton. The cotton arrives before I'm ready to deal with.
Unless dealing with all that can be included in the smart contract, and executed by the smart contract without human intervention, lawyers will still be needed...and they will be needed almost as much as they are now.
PS: my cotton hypothetical is based on a real case: Raffles v Wichelhaus, EWHC Exch J19, (1864) 2 Hurl & C 906. There really were two unrelated ships both having and neither deserving the name Peerless, and both working the India / England trade routes, both scheduled for Bombay to Liverpool, one in October and one in December.
[1] Dhollorah is a very dirty cotton of a longish staple, which when cleared is very white, as if bleached. For for more than you probably ever wanted to know on this and other types of cotton, see the book "Cotton Spinning and Weaving: A Practical and Theoretical Treatise" by Herbert Edward Walmsley, page 71. It's from the late 19th century and is public domain now I believe, and you can find it on Google Books.
Sir that is a prejudicial statement and I want it stricken from the record.
More relevantly, creating a synthetic language that's a subset of natural languages will mean that multiple natural concepts will map onto the same synthetic one.
At some point you have to ask yourself whether we really prefer that code be law, with the quality of code that's so common these days, or whether we actually like being able to specify something to a lawyer -- rather than a computer -- simply because the lawyer will return the contract and ask for clarification if something is ambiguous/unclear.
The human-to-lawyer interface is the best contract interface that exists, the only reason we use computers is because they're so cheap and fast. When we dream of AI we dream of having a computerized lawyer, who can ask clarifying questions and resolve ambiguity before it becomes a problem.
If tomorrow I sign a contract with my mobile phone carrier and it turns out that through some loophole in the contract they get entitled to the kidneys of my first born daughter then clearly I have a case to go to a tribunal and get it overturned as it's obviously not a reasonable clause.
I think people arguing that "code is law" (which is simply a modern form of "letter-ism") don't really know what they wish for. I guess is many are going to change their minds when those attacks get more and more common and they lose a ton of money because of an unforeseen and obviously unintended flaw in the contract code.
They can't deal with the real world by themselves, but where they have value in agreements involving real world events is that they allow the real world assessments to be debundled from those aspects of the agreement that can be formalized.
So in the cotton shipment example, the smart contract would have three parties assigned as Oracles that determine whether the correct ship arrives at the correct port on its correct trip. The smart contract would dictate that if 2 out of 3 of the Oracles agree that the condition has been met, then the smart contract will transfer the funds. There could also be a failsafe clause in the smart contract, that is controlled by a set of five oracles, who have the power to override the smart contract if the majority deem that an expected event occurred.
So yes you need human intervention, but only for those parts that cannot be automated. This explicit definition of what the human roles are may encourage better contracts, by forcing the counterparties to spend more time reasoning about which aspects of the smart contract are subject to ambiguity.
This is tautological and therefore means nothing.
I've not worked with smart contracts personally, so take it with a grain of salt, but...
This problem seems to be mostly solved by the information available in shipping manifests; the locations of loading and unloading, the consignee (buyer), container ids, description of goods... all there in a publicly available (at cost) record.
The real difficulty has more to do with verifying the quality - I'll admit I'm at a loss to how that's done today and I can't imagine quality assessors are at the port to verify that container #123 contains the shipment of Grade B+ cotton or map that to an API. As well, what happens when you disagree and your own independent assessor says its Grade B-? This seems like something that would remain up to legal debate; probably denoted in the contract but not verified by it such that lawyers and assessors can handle it should problems arise.
Just my two cents.
The problem with cryptocurrency is that they try to be better than the system, but have to relearn all the lessons the hard way. It probably won't take too long before all of it becomes exactly like what banks are now - heavily regulated, etc.
ETH and ETC have the same underlying technology and language to write the contracts. So if someone writes a contract it can be used in both variants. The contract may check that it is in ETH or ETC (probably looking for the contract that was added during the fork) but I think very few contracts check this, so almost all contracts are usable in both chains.
So if it was possible to use the Parity contract in ETH, then it's very probable that it was also possible to use it in ETC.
To answer your question: Probably the same bug that was used to steal ETH can be exploited to steal ETC, if someone is using these contracts in the ETC chain. But it's not a problem in ETH or ETC [1].
[1] As other commenters noted, it's a very bad design flaw to make all function public by default. It's not an error, but it makes much easier to write buggy code.
It's not even in the category of weird timing attacks or complicated internal states allowing unexpected state transitions -- this is a trivial bug that could be spotted by viewing the contract in Remix (the Solidity IDE).
There are certainly some weird edge cases in the Ethereum VM programming model that are hard to UT, and I think that dev efforts in this area are under-resourced (e.g. it's currently impossible to test time-dependent contracts as there's no way of mocking out the clock in the simulated blockchain).
If you are considering writing a smart contract, read and re-read https://github.com/ConsenSys/smart-contract-best-practices, and then write UTs for each of these cases so that you can convince yourself that you've covered them.
Relevant to this bug:
> Understand that your public functions are public, and may be called maliciously. Your private data is also viewable by anyone.
https://github.com/OpenZeppelin/zeppelin-solidity
[0] https://github.com/aragon/aragon-network-token
[1] https://github.com/Storj/storj-contracts
This philosophy permeates the community of Etherum development.
Bitcoin disabled most of the smart contracts op codes for a very good reason.
I wouldn't recommend putting anything of value into an Etherum smart contract and find a project with more responsible developers who take a more "wait and see" approach.
it should not be this easy to lose sixteen million dollars
Financial institutions are accurate to tiny tiny fractions of percentage points. Not "eh we got 99% of it right".
I'm amazed that otherwise intelligence people really believe this is a better system than fiat currencies + banks.
Now why hasn't there been as much publicity about this? Is it because Vitalik Buterin is a wunderkind genius who simply beat them to market? Nope, the Bitcoiners are simply being more responsible and making sure they get the formula right before rushing to market.
Please see this article to get an idea of the personalities involved:
http://www.newsbtc.com/2016/08/17/gregory-maxwell-vitalik-bu...
If HE can't get it right, what business do you have running around saying that anyone who can make a webpage can make a decentralized application?
We are playing with money. Dealing with attackers is not as simple as rebooting your server. Mistakes mean irreversible loss.
The devs in this industry are way over their heads and nobody is willing to admit it, because doing so destroys the entire core value prop of Ethereum, the poster child of the current bubble.
Though crypto has risen past the high point of each of these bubbles, each price point can be definitively classified as a bubble in it's own time, and was followed by a crash that wiped out >70% of the market cap over the coming months/years.
Though it did recover, that doesn't mean it wasn't a bubble.
I believe cryptocurrency is going to be bigger than e-commerce is today. But it's not there yet, and it shouldn't be valued as though it has changed the world. It hasn't yet, and it's still a few years away at least from doing so.
Don't short hopium.
"If the creator of Solidity, Gavin Wood, cannot write a secure multisig wallet in Solidity, pretty much confirms Ethereum is hacker paradise."
Parity devs may be academically brilliant, and they put out a fantastic client, but the wallet issue shows how lax their development lifecycle has been.
Bitcoin is also stuck in the past. Yes, Ethereum breaks things, but for me it's not about the money but about the technology stack. We're too early in the process to have the luxury of being able to stop innovating.
If I want to play with cool state-of-the-art technology I use Ethereum. For financial transactions I use my bank and/or Transferwise. Haven't quite yet figured out why I'd use Bitcoin for something.
Some projects have started sharing audit results publicly directly in their repos [1]. It's a great read to see common errors and yet unsolved issues that originate in the ERC20 token specification.
[0] https://github.com/ConsenSys/smart-contract-best-practices#i...
[1] https://github.com/status-im/status-network-token#reviewers-...
Based on the time of your post, I suspect you meant to link to:
https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...
The initial poster posted this link: https://github.com/paritytech/parity/blob/master/js/src/cont...
Where "master" is the branch which normally has the latest code. And #L216 automatically scrolls down to the 216th line.
The issue is that line isn't permanent since the code in the master branch is subject to change. So in order to make a reliable link, you can link to the ref [1].
Like this: https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...
You could also do it with the short ref (4c32177e): https://github.com/paritytech/parity/blob/4c32177e/js/src/co...
Normally you'd have to scroll up to the top right of the document and grab the short form it, e.g. "6b0e4f9" and replace it with master. Note that's only the ref of the last change for that blob (file) [2].
If you click the line number on a GitHub file, it will add the #LineNumber to your URL.
From there, press Y, this will replace master with the latest commit of the repo.
[1] https://git-scm.com/book/en/v2/Git-Internals-Git-References
[2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
parity.io, the company author of the bug, is a top-notch Ethereum actor. If they can neither get a wallet contract right, nor realise that it's faulty, then who can write and trust any non-trivial Ethereum contract?
How many DAO or Parity trainwrecks before people admit that Ethereum isn't a dependable platform?
- Who's the "white hat group"? Why do people have confidence in it?
- Why does everyone believe they'll give back $75M+? If they decided to just keep it, what could anyone do?
- How will people even be able to claim ownership of the ETH in a way that's verifiable so they know they're giving it back to the right person?
It definitely is an uncanny read.
They are just going to deploy new multi-sig contracts with a fix and make the original owners the owners of the new contracts. Pretty easy to do. They are actually paying for the gas to do the fix using donations they received for their work on The DAO attack so the original wallet owners aren't even out the gas the fix would charge (which isn't all that much but it's nice that they are being made completely whole).
The white hats will deploy a new contract without the faulty constructor with the old owners reinstated. These newly deployed contracts will have all the same information the old ones did but won't be exploitable.
$30M worth of BAT, $26M ICONOMI, $17M CFI, $1.4M EOS
historic episode here which is sure to spur many a conversation about what disclosure means in the blockchain era.
If you were the attacker and you now have the ETH in your wallet, how do you cash out without anyone identifying you and maximising your profits?
Also has the attacker broken a law by exploiting a bug in the contract?
If the hacker was entitled to those funds based on the agreement between the concerned parties (implicit OR explicit in the contract) it would not be theft. But it clearly isn't their Ether and the implicit agreement behind the contract stands.
Basically human ethics, morals and the legal system will always trump code.
The comparison to murder doesn't work because you can't consent to murder, but you can consent to theft.
It's not clear to me whether that situation would be taken as consent, but unless you know something I don't, it probably shouldn't be clear to you either.
I mean, legally, what happens is not "consenting to theft". Unlike say assault, which you can consent to, and legally speaking an assault actually happens but consent makes it okay; but with theft, if you consent what happens is not legally theft. (IANAL, but this is my recollection from law A-levels.)
But that distinction is irrelevant here. The point is that there's basically no way for someone to deliberately kill someone and have it not be a crime. But there are ways for someone to take someone else's stuff and have it not be a crime, and one way is if the owner consents.
https://news.ycombinator.com/item?id=14129613
e.g. Facebook isn't perfect, but it sure obliterated MySpace.
It's true that a system doesn't have to be perfect to win, but I don't see how monero has the edge on any dimension. It's not necessarily the most secure, its not the furthest along in development, not the most user friendly, not the fastest mover, etc. The overall bullishness people have for monero is because its supposedly better in terms of privacy than its rivals. But this is dubious without the right kinds of proofs when the competition does have proofs.
Exchange to BTC, mix it, exchange to USD.
> Also has the attacker broken a law by exploiting a bug in the contract?
There are no laws. Only contracts.
You could use localbitcoins to offload one coin at a time on an as-needed basis. That'd be pretty sweet, and the IRS won't be able to know anything strange is happening if you avoid depositing your USD into a bank. But paying rent in all-cash is rather sketchy. I wonder if drug dealers deal with similar problems.
I don't know how plausible this is, but the localbitcoins route might also open you up to being kidnapped. You'd need some pretty decent opsec to avoid revealing that you have a massive amount of BTC you're trying to offload.
> And then the IRS will want to know where you are suddenly getting a huge amount of money from.
In my experience, the IRS is largely unconcerned with where you are getting money from. They just want you to declare it, and pay taxes on it.
If you treat Bitcoin as ordinary income and pay taxes on it at the highest available rate, the IRS will largely be satisfied. If you treat Bitcoin as a long term investment and attempt to only pay capital gains tax.... well then the IRS will become curious enough to ask for 'proof of origin'.
I'd personally call them and get a contract out before funneling this kind of money through their system.
Though that's pretty normal. A regular brick and mortar bank would likely want additional assurances before funneling $30 million into or out of an account that doesn't see that regular volume.
I mean, I don't personally know which alarms would be tripped, or what effect that would have. But that just seems so unlikely.
It'd be fascinating if this were true, though, so any info would be appreciated.
Re: coinbase, it'd be foolish to use them because they have a history of disabling accounts for any reason they feel like. A friend of mine had their account disabled, so I know firsthand this is true. Also it's unlikely they'd send you such a large amount of money unless you were a business in good standing or had a long history with them. (I'm just guessing, though.)
It is perfectly reasonable to be a cryto trade that never withdraws to USD, and just makes money by transferring between crypto currencies and ICOs or something.
I am sure there are a whole lot of people out there who spent a thousand dollars or so back in 2009, and now they have 10 mill in the bank. It is not like any of that could be tracked.
And then you pay long term capital gains on that money, and you are set.
> https://www.irs.gov/publications/p17/ch12.html#en_US_2016_pu...
Illegal activities. Income from illegal activities, such as money from dealing illegal drugs, must be included in your income on Form 1040, line 21, or on Schedule C or Schedule C-EZ (Form 1040) if from your self-employment activity.
Technically, it's illegal for the IRS to do so without third parties coming to them or suspicions of terrorism. In practice, they probably rat people out to LE agencies regularly.
Keep sending cash to bank accounts you have opened by depositing cash in person. Use round robin to distribute money across multiple of your hidden bank accounts so suspiciously large volumes of incoming money doesn't get noticed.
Keep moving around, mixing coins and using localbitcoins to get cash and deposit. Also diversify outside of cash to not raise suspicion of the banks by depositing every day / regularly.
Buy physical gold from pawn shops. Then you can turn gold into cash in banks and deposit it to your account like that. You can also use cash to buy prepaid travel debit cards with like 5k on them at a time from post offices or so. Use that for daily expenses.
That might work. If you are not a US citizen but let's say citizen of China that makes it easier to pull off.
Of course, getting that money back to US to your home bank account would be near impossible (without some way to launder the money).
But you could live off your hidden bank account in tax haven. Just don't flash your millions too publicly so people don't get suspicious. Be humble and pretend to live regular life.
Also you could try to launder the money via setting up some fake ICO project and investing your mixed coins into your own ICO, then cash out your custom tokens on exchanges. Just make sure to do this from some unregulated tax haven and it should work (most of these ICOs create their businesses in dodgy tax havens for this reason).
This is how I'd imagine these scammers are doing it.
https://etherscan.io/address/0xb3764761e297d6f121e79c32a6582...
I guess I am just wondering how this contract can be updated, given its on the blockchain and considered immutable.
When it's about your money, you should be able to do all that.
And yes, Solidity is pretty horrible. I hope there will be better options such as Idris in the future.
In this case, by some stupid mistake the contract allowed anyone at all to change who was considered an owner of a wallet.
The code wasn't changed; one of the functions it specified was used to change a variable.
https://mobile.twitter.com/IamNomad/status/88777698177709261...
"incredible plot twist: whitehat hacker supposedly saved most tokens from being stolen using the same vuln."
https://mobile.twitter.com/bcrypt/status/887775417406431232?...
"Multisig wallets affected by this hack: - Edgeless Casino (@edgelessproject) - Swarm City (@swarmcitydapp) - æternity blockchain (@aetrnty)"
https://mobile.twitter.com/maraoz/status/887755889897295872?...
Any proof of this?
EDIT: This appears to be false. From https://blog.ethereum.org/2016/06/17/critical-update-re-dao-...
The leaked ether is in a child DAO at https://etherchain.org/account/0x304a554a310c7e546dfe434669c...
But that site shows the account hasn't received anything since July 8.
Parity bug: https://github.com/paritytech/parity/pull/6102
If there is sufficient consensus among Ethereum users for a hard fork, then it can happen.
That's not how it works. Even if you had 99.99% of the hash rate, you still have to work within the rules of the chain, so a "give me your money" without a valid signature would still be rejected as invalid by every full node (and you just wasted your hashing power). What having 51% or more of the hash rate allows is a double spend attack: you can undo recent transactions, so you can spend a coin twice.
But the rules of the chain can be changed. If for instance 90% of the full nodes decide to change their software so that "give me your money" is now valid in some special circumstance X even without a valid signature, and that "give me your money" transaction is sent to the network, these 90% of the nodes will allow it to be added to the chain, and let the chain grow on top of it; while the other 10% will grow a separate chain on top of the last block without the "give me your money" transaction. Soon, each side has an incompatible view of which transactions are in the blockchain; this is called a "hard fork". And if the minority side is small enough, it will no longer matter if they still say you have your money, since everyone else you want to transact with will say you don't.
That's what blockchain proponents tend to omit: the blockchain is a social construct. Its rules are fixed as long as the majority of participants want them to be. When they decide to change the rules, like that time when the Bitcoin developers fixed a database bug which changed the validity of some blocks, the rules will change. Even retroactively.
The law is written in code, and clearly code can be changed by human intervention. It's even open source, so technically anyone can change the Ethereum protocol, at any time.
Of course, changes to the law are effective only when there is overwhelming consensus, otherwise they're called minority forks.
Sure, the core team / devs are using the rollback for good. But will that always be the same in the future? It's an avenue for abuse and one of the primary reasons ether isn't going to take off.
Discontent users simply switch to a different branch maintained by different developers. If there's enough consensus, people will call it "real" blockchain and the other one will be left behind with few users and hence no meaningful way to spend the balances.
The moment that happens, the currency loses any influential power.
Bitcoin is currently in a state of disarray because groups of developers, miners, industry and users disagree on fundamental aspects of the scaling debate.
There are no fewer than 4 competing Bitcoin fork proposals on the horizon, each one with an unknown number of supporters. The only thing we can measure accurately is "signaling" in blocks, where miners declare their intention to follow one fork when the designated time comes: https://coin.dance/blocks
However, there is such a thing as "false signaling" for strategic reasons, and hashing power can rapidly shift (or just appear, if new mining rigs come online) in favor of a different proposal at any time.
This is indeed a deeply flawed voting system. In contrast, Ethereum still has a capable leadership with sufficient consensus that they can propose and execute hard-forks whenever they feel it's needed, without this level of uncertainty and drama.
The same laws which apply to stealing tangible things and cash also apply to stealing cryptocurrency.
In the very unlikely event that the perpetrators came out and sued the Ethereum developers for violating their contract and taking "their" money back, a judge would look at the facts and then decide how the law applies to this particular case. IANAL, but I'm ready to bet that the thieves will go to jail for a while :-)
This means that ETH has no actual value. It adds nothing to the legal or economic landscape because it does nothing new (if we repeatedly rollback and hard fork because of "hacks" like this). This isn't a hack. This isn't theft. This is morons who don't know how to code coding in a crappy language meant to run on an even crappier VM. The only victims here are the people who were duped into investing in ETH in the first place. Poor saps.
To dispute that de-facto centralization requires miners to collectively decide to abstain from updates to these primary clients en masse. That just won't happen, people don't organize or coordinate like that. The status quo has tremendous inertia beyond what can be reasonably expected of independent actors trying to act in their own self interest.
Yeah, tell that to Bitcoin on August 1st.
Vitalik on why there will be no hard fork for this: https://twitter.com/VitalikButerin/status/887783867129745412 (not to suggest that Vitalik can just decree there won't be one like some people think, he's just listing the reasons why the community is very unlikely to support a hard fork).