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.

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...

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.

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?"

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.

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.

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.

It is possible to have trusted contracts, iff their logic is (mathematically) proven. But the VM can't make contracts more secure by itself.

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.

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.

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.

As I attempted to say in my previous comment, undecidability[1] isn't limited to deciding if a program will halt (or even the weaker question of if it will halt in a given finite time). Recursively enumerable[2] languages that require a Turing machine to automate have an intrinsic complexity (i.e. any Turing-complete language). This isn't a "work harder to solve it" level of complexity; some behavior will always be undecidable.

You might experience this problem in the traditional form of the "Halting Problem" where the question "Will this program halt?" may be answered with "I don't know, it's still running" in addition to "yes" or "no". However, this level of complexity can also cause unexpected output due to subtle interactions inside the program that are difficult to predict from the source. Some behaviors are provably unknowable.

You can avoid this problem by using a simpler class of language. Regular languages (which "regular expression" match[3]) are safe, as are deterministic context-free[4] languages. You may find the lack of loops limiting.

[1] https://en.wikipedia.org/wiki/Undecidable_problem

[2] https://en.wikipedia.org/wiki/Chomsky_hierarchy#Type-0_gramm...

[3] basic regexp, not PCRE or other language-sepcific extensions!

[4] https://en.wikipedia.org/wiki/Context-free_grammar#Undecidab...

What if Ethereum offered a non-turning-complete subset of Solidity (that included formal verification) which could optionally be used in smart contracts. Would this cause you to view the platform differently?

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.

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.

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.

> 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

But that's basically obvious to anyone not hinging their personal identities on peddling technocratic revolution.

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".

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.

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?

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.

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.

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.

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.

[1] https://blog.ethereum.org/2016/06/17/critical-update-re-dao-...

Printing money was part of how we got out of it. https://en.wikipedia.org/wiki/Quantitative_easing

Inflexibility is not an advantage unless you're dealing with formally describable, proven systems. Human behavior and economics are not.