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

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.

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.

  "use strict";
  foo = 1;
  var bar = 1;

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.

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.

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

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.

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.

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 it's important, you need to be good. If it's very important, you need to be good and sure.

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

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.

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?

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

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.

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.

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

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.

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.

it should not be this easy to lose sixteen million dollars

I'm amazed that otherwise intelligence people really believe this is a better system than fiat currencies + banks.

Financial institutions are accurate to tiny tiny fractions of percentage points. Not "eh we got 99% of it right".

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

https://github.com/OpenZeppelin/zeppelin-solidity

[0] https://github.com/aragon/aragon-network-token

[1] https://github.com/Storj/storj-contracts

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

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.

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.

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.

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.

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.

Sir that is a prejudicial statement and I want it stricken from the record.

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.

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.

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.

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.

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.

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!

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.

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.

[1] https://www.bloomberg.com/view/articles/2016-06-17/blockchai...

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.

[1] https://www.reddit.com/r/badeconomics/comments/6cnzs8/matt_l...

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.

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.

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.

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.

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 would be a stupid decision in any language

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.

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?

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.