Isn't fuzziness a <i>feature</i> of most legal codes? Treating the law like an absolute immutable contract sounds anathema to a healthy judicial system.<p>I'm not sure why some technologists have such a fascination with legalism.<p>I'm not against the idea of digital government and having laws be distributed under a free documentation license with the ability for citizens to discuss and amend laws. A standard version control and issue tracker model sounds much more appropriate, however. Perhaps even just email and diffs, so as to have a barrier to entry.
This is a terrible description of Ethereum and trivializes what it is.<p>The interesting parts of a contract are not the deadline and the transfer of funds. Even an escrow service can provide those functions.<p>The interesting parts of the contract are the conditions of the transfer of funds, and how those are evaluated prior to effectuating the transfer, and how the obligations are enforced after the transfer.<p>What makes Ethereum interesting is that it creates a public, decentralized infrastructure for standardized outsourcing of third-party verifiers for each conditional precursor of a contract, and each subsequent obligation.<p>A contract can specify a set of payments and deadlines, as in OPs example, but it can also specify Boolean inputs from trusted third-party institutions that provide various named state inputs into the contract.<p>For example, you could have an input that is Boolean, which says, "Website transferred from Seller to Buyer: Verified by Verisign: True/False", etc. Those conditions can be part of the verification process. AND even more excitingly, small micro payments can be made part of the contract, to the third-party verifiers, as part of the contract itself.<p>I am kind of sick of people who don't understand what the value of smart contracts is, messing up other people's perception of what it is. I award OP zero points, and may god have mercy on his soul.
Bitcoin transactions are scripts that execute sequentially and are very restrictive. Ethereum instead took bitcoin and replaced that scripting language with a turing-complete language.<p>Now, consider the conditional operator in the given example.<p>"If a transaction occurs.." is the condition. ONLY the conditional of transaction types can be verified by the program because it is inherent in the network. For every other conditional, for example, "if team A wins.." the program has to consult a third-party. These are known as 'oracles' in ethereum lingo.<p>Now since we are trusting a third-party, why can't we simply use bitcoin and even let the decision script be hosted on the third party?<p>For the program to be able to take decision on a real-life event, only the occurring of a transaction is the type of event it does not need a third-party for. And trusting is all the problem there is.<p><i></i>*<p>Bitcoin's script not being turing-complete is a feature because it specializes the use-case. Theoretically, if ethereum allows a turing-complete language to be executed, a code could be written to hack the system itself. Ethereum handles this by executing in a virtual environment.<p>Thus ethereum is essentially a abstraction on bitcoin and introduction of a new currency token (ether) is unnecessary.<p><i></i>*<p>The vision of ethereum is very desirable. Although Ethereum does not make it possible I want such a system to exist. My limited understanding is that for a system to exist, we need an algorithm to be able exchange private keys between two parties without trusting each other.<p>We need a homomorphic secret sharing but without a dealer. In a Blakley scheme, both parties chose their own planes; we need the intersection of planes, the line, to be our private key and for everyone to be able to know the public key for the same without the private key being known to anyone.<p>Does anyone know of such an algorithm, because solving this problem will also truly decentralise cryptocurrencies like email.
The example contract is very vague and seemingly pointless. The stated problem is 'if the buyer pays before 1st April, then they own the website'. Fair enough, but usually you'd just deal with this without any kind of contract in place. We don't need contracts for simple cases of 'buyer pays money, gets purchase.'<p>A contract would only be interesting in the example if it was structured as an option: The buyer has promised to pay for the item by 1st April, and in return, you have promised that you won't sell the item to someone else before then.<p>How would this be handled? How would be example contract react if you set 'WEBSITE_ADMIN' to someone else prior to the purchase? Does the example contract mean that WEBSITE_ADMIN cannot be altered by anyone else? What are the access controls to this storage slot WEBSITE_ADMIN? Does the seller lose write-access to it after the deal completes? Does the buyer gain read access? If not, what's to stop anyone changing this value and breaking the deal?
"You might even imagine a nation defined not by geography but by the rules and benefits of citizenship. Imagine that people of the future could opt-in to the virtual nation that suits them best." . I wonder if we will ever get there . But its eye opening just to think about it.
This is one of the clearest and understandable-without-prior-knowledge descriptions of the project I've seen so far, can anyone familiar with the details weigh in on how accurate it is?<p>EDIT: not-so-happy sibling comment: <a href="https://news.ycombinator.com/item?id=9987351" rel="nofollow">https://news.ycombinator.com/item?id=9987351</a>
Presumably smart contracts would very often depend on input external to the system - for example, imagine a will that says if Person A dies, Person B inherits the millions of dollars worth of Ether at a particular address that Person A owns.<p>Somebody (or some other system) has to be in charge of the input to the Ethereum system to tell it that Person A has died. This seems like a huge single point of failure that doesn't exist with current contracts, if it gets hacked then the money gets transferred irreversibly and that's that.<p>Trying to build a smart contract with any kind of "real world" dependency like this seems equivalent to using a crypto system with an extra key that the government controls, there's a single point of failure that could compromise the whole system.
So it's a currency, a contract system, a new form of law, a distributed computing system... I think I need to lie down.<p>These explainers I keep reading are not helping.<p>Can anyone tell me whether this is some giant boondoggle circlejerk, or something that is really going to be used widely and perhaps lead to things changing?
Ether is law, but the example contract says nothing about websites, nor has any provisions to enforce the transfer of said site.<p>I think it's more appropriate to say that ethereum is naive
I have not seen any clear explanation of how these networks of interacting contracts will be verified, so you know they will work the way you intend. Anyone with any knowledge of the formal verification of software written in Turing-complete languages knows that it is difficult, and it is something that not even many programmers know how to do. Until I see a plausible answer to this question, I have to regard the sort of future presented here as a flight of fantasy.
This will never be unbreakable because no complex system is unbreakable.<p>The reason contracts are messy is because they're a system that has vulnerabilities. Lawyers are just hackers with different tools and training.<p>So moving to another system, equally complex or dynamic, will not solve anything in the long run.<p>A system that must support contracts between humans would be dynamic enough to allow for vulnerabilities that will eventually be discovered.<p>In fact I find it laughable that these guys are trying to replace a legal system with a computer system. When computer systems get hacked all the time.
It's very cool that you know exactly what is going to happen. Or, at least, you could simulate exactly what should happen. And, if there was some repository of contracts, you could simulate the effects of the system. Such higher-order possibilities are so opaque most of the time.<p>But, I'm not sure ambiguity is a bad thing. Or, at least, there is a dose-specific effect. A lot of ambiguity is bad, but so is none. The flexible Goldilocks Zone is the least fragile -- <i>to society</i> that is, not to law.
Smart contracts are one of the worst ideas ever conceived.<p>Nobody actually wants smart contracts, for excellent and obvious reasons. Nerds think they're a good idea because they'll sort out all the annoying grey areas in social human interaction.<p>Dr. Strangelove is literally about an unstoppable smart contract going wrong.<p>No business actually wants smart contracts - they always, always want the option of lawyering out of a bad deal. Or stopping it if the government gets pissed off and says it will penalise you to a crisp if you proceed with that smart-arse contract you just put on the blockchain.<p>No consumer wants smart contracts, for the same reason "no chargebacks" is a loser. You always want a human to be able to fix the problem.<p>The only use I can think of for smart contracts is for businesses to screw over customers who have no other option, c.f. mandatory arbitration clauses. Note how the standard example of a smart contract is a car that stops working if your payment fails. Or the Internet fails. Unstoppably. Immune to human intercession, circumstances, etc. (Such locked cars already exist, only bought by people who have no other choice.)
This explanation subtly forgets to explain which agent is responsible for executing the contract-programs. Obviously you don't want the contract to be processed (and the money spent) two or more times at its deadline. Who is doing the processing and ensuring the execution only occurs once?
Perhaps I'm wrong, but the simplest explanation of Ethereum appears to be that it's a way of specifying and sharing contracts.<p>I think the whole digital currency thing muddies the waters. People, myself included, hear the word currency and think of something we earn and spend, but then you hear about all the other uses of Ethereum and wonder what that has to do with money.<p>What I've just realised by reading this article is that contracts are what Ethereum is all about, the currency aspect is just one of the many use cases. Laws are another example of a contract. The base class is contracts, everything else is a subclass on top of that.
It comes down to prior restraint.<p>With most laws, there is the possibility of breaking them and maybe you have to face the consequences.<p>With this stuff, you won't be able to use the stuff for what it wasn't designed for. Stronger guarantees. It's like a car that slows down in a construction zone, and is unable to go any faster, instead of cops giving tickets. Like the 90 year old engineer guy behind the Venus project says in his interviews.<p>That can be useful. Not for everything, but for a whole lot. The current DRM stuff works like this.
For a less instrumental account, my article with Bill Maurer might be of interest: <a href="http://kingsreview.co.uk/magazine/blog/2015/06/23/ledgers-and-law-in-the-blockchain/#top" rel="nofollow">http://kingsreview.co.uk/magazine/blog/2015/06/23/ledgers-an...</a><p>It interrogates the intersections between law and contracts as it pertains to the shift from Bitcoin to Ethereum.
Such a system needs integration with subjective variable sources. For example let's say the website also needs to meet some basic code quality level. They could agree to give a third party exclusive access to set some "quality check" variable.<p>If that's implemented it can be a great way to codify all sorts of legal docs and laws since a lot of legal stuff requires human interpretation at the time of execution.
I wonder if it is possible to pass an actual law which would render digital 'contracts' illegal. So all lawyers become coders/analysts? I find the idea interesting, but in reality this is never going to go further than an academic or research project ...
This seems like a neat idea and seems quite ambitious. I guess I'm jaded from all the other crypto-currency and I just can't get excited about this. I fear that this will be the only time I ever hear of Ethereum again, this moment when I read this article.
I wonder how such things as "the tyranny of the majority" will be handled, because if you make a poll at a gang rape, 9 out of ten will vote to continue the rape.
The author falls into many traps of the law vs code debate. There is a big difference between wet and dry code, as Nick Szabo, the original inventor of 'smart contracts' put it.<p>Admittedly, it is very stimulating to entertain thoughts in the direction the author takes his description. But in the end it is not a fruitful approach to understand ethereum and other smart contract systems.<p>Law has an open texture. It is deliberately broad and ambiguous to allow specific real life events to be subsumed under the conditions of a given regulation. Legal provisions do not have to be formulated in a natural language. They can be expressed in pictures or even in (pseudo) programming code. What is important is who (or what) parses and interprets the code. Wet code, i.e. legal provisions, are interpreted by humans. Nothing else can (currently) understand the "actual meaning" of a legal provision. Dry code is the opposite in that it is not interpreted by humans but by machines. Smart contracts - the official (but historically inaccurate) name of those programms that are hosted and executed on the ethereum distributed virtual machine - are written in dry code.<p>Ethereum is a 'rich and trusted' execution environment for software. 'Rich' because the ethereum virtual machine has access to a whole bunch of data that carries deep meaning to specific individuals and human society in general (or rather might some day). Trusted because the code execution is performed in a way that is extremely reliable. Whatever the competing interests behind the outcome of a specific computation may be, influence over the network may only be gained through computational resources (and at a later point probably stake/ether) which - in the real world - means economic resources. The achilles heel of a network such as ethereum (and bitcoin) is that "the crypto-economy" needs to stay causally disconnected from the other economy, that uses blockchains as a tool to run trusted fiduciary code (currency, insurance, identity, reputation).<p>"Law vs Code" is a very interesting talk to be had but there is no room for a "doomsday argument". Both are separate but intertwined domains. A fruitful approach to understanding the relationship between code and law may be Luhmann's system theory.<p>[further reading]
<a href="https://en.wikipedia.org/wiki/Niklas_Luhmann" rel="nofollow">https://en.wikipedia.org/wiki/Niklas_Luhmann</a>
<a href="https://medium.com/@heckerhut/smart-contracts-platforms-and-intermediaries-c3d30f5182a6" rel="nofollow">https://medium.com/@heckerhut/smart-contracts-platforms-and-...</a>
It will be hard enough to get widespread social adoption of either blockchain currency or contracts written in programming languages without making them tied to each other.<p>A better choice for an initial compile target for EtherScript would simply be English.
This convinced me to not waste another second on Ethereum. It serves a self-defeating purpose, and I think it's diametric to the hacker ethos. Bitcoin is neat because it can't be controlled, nobody can tax it or pose fees on it. It's free market at it's very best. The bitcoin protocol is weak, but luckily developers are strengthening it all the time.<p>Laws as a general concept are diametric to human nature, and they should be avoided whenever possible, especially in regards to social realms like bartering and contracting and the like.