
What is Ethereum? - mode80
http://etherscripter.com/what_is_ethereum.html
======
vezzy-fnord
Isn't fuzziness a _feature_ of most legal codes? Treating the law like an
absolute immutable contract sounds anathema to a healthy judicial system.

I'm not sure why some technologists have such a fascination with legalism.

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.

~~~
ewzimm
Ethereum is a currency and enforcement system built for computers. Initially,
ambiguity isn't a feature because it's meant for contracts and things which
are meant to be precise. Room for ambiguity in ethereum can be added later,
once computers are intelligent enough to negotiate ambiguity.

The main feature of this system is removing the need for enforcement. Think
about how much goes into maintaining police, bounty hunters, debt collection
services, reposession services, prisons. In many people's opinions, if
enforcing a contract is possible through software rather than physical force,
software is always preferable. It brings its own issues of course and isn't
instantly perfect, but the possibility of a world with much less need for
violence to enforce the law is worth pursuing.

The biggest advantage of this is that it can be completely automated.
Corporations can be programmed to run themselves and negotiate enforcable
contracts with each other without any human intervention. You could have a
personal digital assistant which interacts with other digital assistants to
manage your finances and investments, and everything can be enforced by
software. As long as enough people are running free software, everyone can
share mutually beneficial enhancements to the algorithms which govern their
behavior.

You might not want this kind of thing today instead of a trained financial
advisor, but 30 years from now, it's likely that software will be better able
to make financial decisions than any unaugmented human. Even more important
would be movement of commodities around the world between people who need
them. Instead of relying on profit-motivated markets to distribute goods, we
could have optimal algorithms for moving resources where they're most needed,
and enforcement of these agreements will not depend on the strength of a
nation's military or economic power but rather smart contracts which are
perfectly enforcable whether they belong to a first or third-world nation.

None of this comes free, and there are real challenges to overcome. People
will try to exploit them for personal profit. Software will have bugs and make
bad decisions. Those are some of the growing pains we'll need to work through
to get to a more fair, less violent world.

~~~
mempko
You misunderstand why contract enforcement leads to violence. In the real
world, contracts among equals are always fungable and rarely enforced with
violence. It is different when the contracts are between powerful and the not
so powerful. Violence propagates down.

Ethereum, by automating contract enforcement is going to end up being a tool
for the powerful against the weak. A tool which brings the cost of lowering
contract enforcement will lead to powerful organizations using Contracts more
often against the weak.

~~~
ewzimm
You're right in general, but if two groups use a common software platform and
write the rules of the contract into it, there's less need to build up an
enforcement regime.

I'm not sure exactly how you're interpreting contract enforcement leading to
violence, so I'll try to explain a little more. Two people make a financial
agreement, hire lawyers, and depend on a powerful police force and and penal
system to enforce the terms of their contract. This increases the need for
armed police, prisons, etc. As more people and institutions are given the
right to enact violence to enforce these contracts, people become more
desensitized to violence and arrest and more opportunities for abuse present
themselves. Abstracting this enforcement into software also distances the
enforcement from the culture and removes some of the negative psychological
effects on people of carrying out that enforcement.

That's on the smaller scale. On the larger scale, nations feel pressure into
increasingly more arms races to keep themselves on an even level. Abstracting
enforcement of agreements into software can have the same effect as the
introduction of diplomacy into international trade. While it didn't eliminate
war, it offered an alternative to straight-out aggression between tribes.
Groups that used to stay to themselves and interact with each other only on
disputed borders were able to cooperate on a much higher level by establishing
representatives inside each others borders.

A smart contract system is a neutral, diplomatic ground for the Internet.
Today, the Internet resembles in many ways the world before diplomacy. There
is a persistent, escalating cyber-war between nations. People can move in
between nations, but there's no real neutral territory that every nation would
consider fair. By having a mutually-agreed and verifiably trustworthy software
platform to enact contracts, there can be opportunities for new types of deals
that are more mutually beneficial.

Will this suddenly eliminate war and hostility? Of course not. Neither did
diplomacy. But almost nobody thinks we should go back to a world without any
diplomacy, and once we have neutral and fair systems to conduct electronic
business, few will want to give it up.

~~~
mempko
Contracts that are mutually beneficial typically don't need to be enforced
because they are not often broken. People who consider themselves equals give
each other slack in contracts. The only use case this software fits with is is
handling contracts where one party does not trust the other. Typically the
more powerful party is at an advantage.

There are two scenarios I see. This software is useful to powerful groups to
make contract enforcement cheaper in which case they will essentially force
the weaker party into compliance. Or this gives the weaker party an advantage,
in which case this software never takes off. Because let's face it, I would
never use this with people I like.

~~~
sirclueless

        Contracts that are mutually beneficial typically
        don't need to be enforced because they are not
        often broken.
    

This is a fundamental misunderstanding the purpose of contracts. Contracts are
almost by definition mutually beneficial, at least nominally. Otherwise the
only reason parties would enter into them is under duress or out of ignorance.
And in fact, contracts backed by a legal system are routinely struck down if
either of those cases occur.

What you are describing is a situation where neither party has an incentive to
defect or default on the contract. And if that is the case then there was no
need for a contract in the first place. For example, you and I agree to meet
Friday night for dinner. This is a beneficial arrangement for both of us,
neither of us need sign anything.

The purpose of contracts is to solve a game-theoretic problem: it is to our
mutual benefit to cooperate in some way. But if we cooperate, then one of us
can do even better by defecting. For example, it might be mutually beneficial
for me to give you $1,000 today, and for you to give me 100 widgets on
Thursday. But if I give you $1,000 today, you can do better than the original
agreement by keeping the money _and_ the widgets. So the only reason I would
ever give you $1,000 is if there was some way to _enforce_ that you give me
100 widgets. That can be by legal means, or technological means. The threat of
punishment under a legal system is one traditionally effective way to
incentivize you to hold your end of the bargain, and in many ways is at the
very heart of what makes modern society work. A technological solution, that
avoided law enforcement and judiciary systems, has the potential to be even
better because there are obvious negative effects to having a large and over-
reaching police force, for example.

TL;DR The enforceability of the contract is the whole point. The only reason
you need a contract in the first place is because someone has an incentive to
defect.

~~~
ewzimm
Thanks. That's exactly it. People might try to counter by saying that specific
cases don't work that way, but that's not what game theory predicts. It won't
tell you the outcome of a specific instance of a conflict, but it will predict
the overall trend when a winning strategy exists. Traditionally, the counter
to exploitable strategies was the honor system. You trusted the people you
interacted with not to take advantage of you because you believed in their
character. While that can work in specific cases, it's not an overall good
system for running a large-scale system of social interactions because it
invites exploitation. We tend to think of corruption as inevitable, but the
degree of corruption in a system is actually somewhat predictable by the
incentives for it built into the rules of the system when that system runs at
a large scale.

~~~
EublepharisRex
Thanks for some fascinating contributions to this thread.

I see both sides of the debate, and lean toward your side. But I also think
both sides are probably wrong to speak as if we will have either one system or
the other in the foreseeable future. I think it is more likely that government
resources and law enforcement will exist alongside any trustless contract
system, acting as a failsafe (or guarantor of exploitation, depending on your
POV I suppose). Few contracts would be irreversible, and few holders of
contracts would resist reversal, if physical violence from the state were
brought to be bear, even if the issue had already been "settled" by software.
I believe the reality is that Ethereum-style contracts would increase
efficiencies in more routine, less controversial contracts and the state would
remain the final recourse in more extreme cases. As some have said, 30 years
down the road when machines are more intelligent, all bets are off. But for
the foreseeable future, the state isn't going to wither away just yet.

As far as people obfuscating with complex contracts, yes, of course they will
do that. But the obvious implication is that a class of techno-jurists will
have to arise to help advise users. Again, that's not much different than the
current system of clueless folk consulting attorneys, and I imagine both
systems would coexist for some time to come.

~~~
ewzimm
I definitely agree that smart contracts are going to be implemented as another
layer. They'll erode the need for traditional enforcement slowly. And while
there's a need for resolution when there's a bad contract, that resolution
system doesn't always have to be a person.

Here's a simple theoretical example. People operate under a common, universal
law system that defines the most basic rights. The rules of this system are
only those which everyone who participates can agree to. For example, everyone
agrees not to kill each other. People who do not accept these rules can form
alternative societies, but they will not be able to access areas under common
law through the use of smart locks and the like which restrict access to
public spaces only to those who accept basic terms of behavior.

These rules can be under constant revision because the code that runs the base
social platform is publicly audited, and anyone can submit a request to edit
it. These revisions can be tested at smaller scales just by running the rules
in private spaces. In your home, you can set whatever rules you want, but
anyone running software with conflicting preferences will be alerted to the
changes when they enter. If your home rules become popular with your friends,
they may choose to implement them in their home. If enough people adopt them,
the community may choose to implement them in certain spaces, and they can
propagate outward.

The basis of this type of system would be mutual consent, and what a person
consents to do can be adjusted at any time by their own software. It would be
important that a person's personal platform was entirely under their control
and only interacted with the outside world through approved protocols. Likely
this would require a direct brain connection that could not be hacked because
of physical safeguards.

Business could be conducted between communities that operated under entirely
different rules through automatic contract negotiation. New ideas could spread
from private to public spaces automatically through smart social contracts.

This is just one, very basic example of a society run by smart contracts.
There's plenty of ways for these types of systems to be exploited, but that's
part of the design process of any system. Particularly difficult is the
problem of letting a machine which can be manipulated dictate so much of life.

But people's brains can be hacked already. Look at advertising, religious
cults, mob mentality. People have always been vulnerable to manipulation, and
we have developed an interconnected financial system where almost anything can
be bought, especially power. We can learn from existing flaws as we develop
new systems to fix the bugs in our biology and political systems that have
made us vulnerable. We will definitely introduce new vulnerabilities. We just
have to make sure we have a robust plan for continued development to respond
to them.

------
TheMagicHorsey
This is a terrible description of Ethereum and trivializes what it is.

The interesting parts of a contract are not the deadline and the transfer of
funds. Even an escrow service can provide those functions.

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.

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.

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.

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.

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.

~~~
platz
> outsourcing of third-party verifiers

Since people using the network will be in control of constructing their own
contracts, they will have an incentive to draft the contract in such a way as
to make sure they'll have control over this "outside verifier"; it could even
be same company which it chooses to be the "verifier".

> trusted third-party institutions

The defeats the previous attempt at decentralization, by re-centralizing the
information the network needs to do it's job.

This is what the network hinges on to gain information about the outside world
(and remember, companies will have an incentive to build the contract in such
a way to control these trusted third-party institutions as mentioned above).

(I'm aware of schelling coin/contracts; I'm don't think it will work unless
it's made a mandatory part of all contracts for all third-party verifiers. For
applications that need data that is publicity verifiable, such as the weather
or sports outcomes, it could work, but if the information is not is publicity
verifiable, e.g. a transaction amongst private parties, I don't see it. And
that's only if you force the use of Schelling coin/contracts, which is usually
never the first thing Ethereum folks talk about when pitching this; I'm not
sure if there are actually plans to implement that.)

~~~
TheMagicHorsey
Your counterparty will not agree to an arbitrator that is not neutral, so
there is market for third-party verifiers who have a reputation for
trustworthiness.

~~~
platz
In some cases yes, but if your counterparty is Facebook (or commercial svc)
you don't have any negotiating power. Either you accept their terms or don't
use their Service

~~~
TheMagicHorsey
That problem is orthogonal to the discussion and not absent in real contracts
either.

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

Now, consider the conditional operator in the given example.

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

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?

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.

 __*

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.

Thus ethereum is essentially a abstraction on bitcoin and introduction of a
new currency token (ether) is unnecessary.

 __*

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.

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.

Does anyone know of such an algorithm, because solving this problem will also
truly decentralise cryptocurrencies like email.

~~~
chriswarbo
> 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?

One reason which springs to mind immediately: the entity running the script
always has complete control, whilst we may choose to grant limited control to
third parties. For example, we might define a set of separate, potentially
independent, verification conditions, and perform some action when 2/3 of
those conditions are met. Manipulating such a contract would require collusion
by many of those third-parties; and it would also make contracts more robust
against technical problems.

~~~
kang
The bits of a cryptocurrency transaction cannot be changed. Its like a signed
cheque, can only be read. So since the flag from third party is being used to
decide which transaction is relayed, it is as good as handing over the
transactions to the third party to relay them. Majority consensus can still be
done by using multiple third-parties.

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

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.

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?

~~~
kordless
The data for WEBSITE_ADMIN is set _inside the Ethereum network_. I think the
term 'website' is tripping people up here. It's actually better defined as
'site with data' which can be accessed via the Ethereum APIs. If you are
interested in playing around with the API calls, there is a Docker image for
it. I put together a hosted version of this as well, so you don't have install
anything to play with it: [https://github.com/giantswarm/swarm-
ethereum](https://github.com/giantswarm/swarm-ethereum)

~~~
joosters
Are you saying that Ethereum is a web hosting platform?

~~~
natrius
Ethereum is not a web hosting platform. It is not similar to Amazon's EC2 or
anything like that. Conceptually, it is a single global computer that anyone
can access. It's not the same kind of computer you're familiar with, though.

Programs on this computer can't be changed, and nothing can write to the
program's storage except for the program itself. You don't have to trust a
service provider to maintain their guarantees: it is impossible to break a
guarantee.

These characteristics are useful for writing programs that coordinate
interactions between humans. They're also useful for letting devices publish
and access information about the world long after their manufacturers go out
of business.

Entirely new kinds of software can be built to coordinate social and financial
systems.

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

~~~
616c
I am sure I have brought it up here before, but I will again. Here it goes.

My father is an intellectual property attorney. Among colorful clients was a
very active entrepeneur/inventor.

One year he insisted the future was a digital nation. You see how people drool
or get excited even with 1/4-of-the-way-there e-Estonia system? He was talking
about this years ago, when I was finishing high school and starting college.

My father even drafted letters to the UN on his behalf pitching the notion of
offciail recognition, and he was laughed off completely.

Mark my words, if govts still antagonize their people and an alternative of
this form exists, a vocal minority will popularize the notion.

As an American, I cannot wait.

~~~
jsprogrammer
How would a distributed "digital nation" (which is, rather conveniently, very
poorly defined) exercise force to enforce its "rules" on the physical world?

~~~
natrius
You'd probably have to limit the use of force to things almost everyone agrees
on, like detaining people to prevent imminent harm. For other things,
sanctions are probably effective enough. Given universal, stable,
cryptographic identities, you as an individual would "enforce" your rules and
desired contributions to public goods by consulting your chosen sanction list
before trading with someone.

~~~
jsprogrammer
Ah the slippery slope of imminent harm.

I'm not sure I understand why I need a cryptographic identity to boycott
certain vendors? I can already do that today.

~~~
natrius
You need cryptographic identities for automated boycotts. Boycotts aren't very
effective today because they're hard to organize, and some vendors have
relative monopolies. I think Ethereum enables both effective boycott
coordination and monopoly elimination.

Also, these sanctions apply to both sellers and buyers. I think economic
isolation will be an effective deterrent to undesirable behavior. It's
basically prison, just without force.

Imminent harm may be a slippery slope, but it's really all up to the
individuals who support the enforcers. If someone detains someone who
shouldn't have been detained, stop funding their activities and sanction them.
Fund a different enforcement organization instead.

~~~
jsprogrammer
I can see the boycott coordination angle (except, the offensive vendor can
just change its identity).

By what mechanism does Ethereum enable monopoly elimination? (sorry, I don't
know too much about Ethereum)

The problem with detainment, collective detainment, sanctions, etc. is that
the local conditions when a detainment occurs may be far from the theoretical
situation. What if everyone around you believes that you should be detained,
but you actually shouldn't (according to the theoretical 'rule')? You just
threaten to "stop funding" them and they let you go? What is to stop them from
escalating the violence? Nothing.

~~~
natrius
_" I can see the boycott coordination angle (except, the offensive vendor can
just change its identity)."_

If the vendor changes its identity but the public is still aware of the
connection, the new identity goes on the sanction list. If the new identity
can't be linked, then it has absolutely no reputation and has to start from
scratch to convince people to buy from them. That is an effective deterrent.

 _" What if everyone around you believes that you should be detained, but you
actually shouldn't (according to the theoretical 'rule')?_"

There are no "rules". What I'm describing is a society organized via voluntary
actions, but by following prescribed rules. If everyone around you thinks you
should be detained, you get detained. That's how society works.

Sanctions don't prevent bad behavior, they punish bad behavior as a deterrent.
Separately, a police force exists only as long as people fund it, and as long
as people approve of their uses of force.

I'm not saying this is all bulletproof, but I think it's going to be fun to
explore as we build the foundations for these sorts of systems.

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

EDIT: not-so-happy sibling comment:
[https://news.ycombinator.com/item?id=9987351](https://news.ycombinator.com/item?id=9987351)

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

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.

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.

~~~
szx
While I generally agree with your point, it seems to me like that specific
scenario could be solved with a dead man's switch contract. Not ideal, but
still better than other cases.

I got the impression that the answer you'd get from the Ethereum team is: at
the _worst case_ , this is just as bad/good as the current system - i.e. real
world effects have to be mediated by an executing authority, same as a real
world contract. They would add (and I agree) that smart contracts still have
advantages, even in this case.

~~~
dcosson
You're right, the dead man's switch is interesting here. I wasn't thinking
about the ability to reference a fairly precise point in the future via block
number instead of an external input to the system.

Don't get me wrong, I'm pretty excited about smart contracts. It just seems
like there are a lot of things that we don't think much about currently
because our current system is generally pretty forgiving in its fuzziness, but
that could have big consequences (and introduce new incentives to act badly)
in the world of script-controlled, irreversible contracts.

------
serve_yay
So it's a currency, a contract system, a new form of law, a distributed
computing system... I think I need to lie down.

These explainers I keep reading are not helping.

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?

~~~
zorked
Is this going to be widely used? No. It's early technology.

Will a successor of this idea change things? Yes.

------
fleitz
Ether is law, but the example contract says nothing about websites, nor has
any provisions to enforce the transfer of said site.

I think it's more appropriate to say that ethereum is naive

~~~
zaphar
If we are being fair here neither does a traditional contract. The enforcement
of a that contract falls to person (i.e Policeperson, Bailiff).

The benefit of etherscript in theory at least is that the wording of the
contract is unambiguous, with the caveat that there may still be some areas
where ambiguity is unavoidable. Which means that in the case of a website a
digital bailiff _could_ enforce the transfer. This _is_ a clear benefit in
some sense at least. How many times have you read about a court case and been
bewildered about how someone could possibly be arguing over something that
should be clear cut.

For contracts like a website domain transfer this sounds at least initially
doable. What etherscript will have trouble handling is establishing what
actually happened. It will undoubtedly be very good at specifying what the
outcome of a sequence of events should be but as soon as it hits the real
world the problem of establishing what that sequence of events was will still
require some form of investigation and enforcement mechanism composed of
people and thus there will still be an unavoidable amount of ambiguity there.

~~~
fleitz
The debate in law is usually about what the words mean rather than what words
appear in the contract. (Of course there are always issues where contracts
have been lost, etc)

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

------
natch
In the samples there is an unbreakable marriage contract where divorce is only
possible if both parties agree. Scary.

------
INTPenis
This will never be unbreakable because no complex system is unbreakable.

The reason contracts are messy is because they're a system that has
vulnerabilities. Lawyers are just hackers with different tools and training.

So moving to another system, equally complex or dynamic, will not solve
anything in the long run.

A system that must support contracts between humans would be dynamic enough to
allow for vulnerabilities that will eventually be discovered.

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.

~~~
crucialfelix
Skilled programmers will be hired to write these contracts in a complex and
verbose way such that the other party is unable to understand it and may not
be able to afford to hire programmers to analyze it. They will then be taken
advantage of.

So pretty much the same as the current legal and financial system.

~~~
gweinberg
Maybe. Nobody is going to sign a contract he can't understand if he get the
same goods and services from somebody else with a contract he can understand.

~~~
crucialfelix
People do exactly that all the time.

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

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 -- _to society_ that is, not to law.

------
paulsutter
I'd be a lot more interested to see statistics on adoption, and actual use
cases by real people.

~~~
lukateake
Stats: [https://stats.ethdev.com/](https://stats.ethdev.com/)

Transactions go live on Monday, if I remember correctly.

------
davidgerard
Smart contracts are one of the worst ideas ever conceived.

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.

Dr. Strangelove is literally about an unstoppable smart contract going wrong.

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.

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.

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

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

~~~
chriswarbo
As far as I understand, it's a distributed consensus system. Scripts don't
perform their effects in the "real world"; instead, they append values to a
blockchain. External systems can inspect the most recent values in the
blockchain and act accordingly. This is how bank accounts work, conceptually.

Many programming courses use bank accounts as examples of race conditions in
concurrent systems, eg.

    
    
        User withdraws £10 from ATM           User receives £1000 salary           Balance
        ---------------------------           --------------------------           -------
        ATM looks up balance (£100)           Bank looks up balance (£100)         £100
        ATM subtracts £10 from value (£90)    Bank adds £1000 to value (£1100)     £100
        ATM dispenses £10 note                Bank sets balance to value (£1100)   £1100
        ATM sets balance to value (£90)                                            £90
        

This race condition has blown away the user's salary! However, this is a
_terrible_ example, since it is nothing like the actual operation of a bank
account!

An account is exactly that: an _account_ (log) of what has happened:

    
    
        Debits              Credits
        ------              -------
        ATM withdraws £10   Salary adds £1000
    

The _balance_ is exactly that: the balance of (difference between) the credits
and debits. The balance is _derived_ from the account as needed, taking new
entries into account as they get added.

Blockchains are a way to keep such accounts, in a consistent way without
giving any one entity control over updates.

For example, the article's Web site ownership system might keep an account
with entries like this:

    
    
        User A transfers example.com to User B
        User B sets example.com IP to 123.123.123.123
    

When contracts are executed, they can inspect the latest values on the
blockchain and append alterations. For example, if user B sets up a contract
to transfer ownership of example.com to user C, one of the pre-conditions is
that user B owns the domain. Hence after execution we get:

    
    
        User A transfers example.com to User B
        User B sets example.com IP to 123.123.123.123
        User B transfers example.com to User C
    

Anyone can execute the same contract on their local copy of the blockchain to
get the same result, hence everyone can reach a consensus about what the new
blockchain should contain. The contract also can't be run twice in a row,
because the resulting blockchain says that User C owns the domain, and hence
user B doesn't have permission to transfer it. The same thing happens to any
currency which B and C might transfer in exchange for the domain.

To actually _use_ such a value, we can imagine a DNS-like system which
resolves names by looking up the latest IP address from the blockchain; in the
same way that an ATM displays our current balance by looking at the
credits/debits in the account. All of this can also be cached, of course;
provided we either trust the cache to provide the right value, or that we
don't care enough about the value to verify it ourselves (eg. transactions
between third parties which do not affect us).

------
termain
Looks like someone is trying to bring about the Diamond Age.

------
ZenoArrow
Perhaps I'm wrong, but the simplest explanation of Ethereum appears to be that
it's a way of specifying and sharing contracts.

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.

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.

~~~
iMark
What's a contract? (Playing devil's advocate a little)

(edit: for the sake of pedantry, assume I did indeed mean contract)

~~~
ZenoArrow
Assuming you meant contract, I'd say it was a formal agreement between two or
more parties. Will that do?

~~~
iMark
Not really, no.

I actually have a decent understanding of what's involved regarding Ethereum,
but assume for a moment that I don't.

Statements like "a formal agreement between two or more parties" are of little
use to someone starting from ground zero.

~~~
ZenoArrow
I can try to put it in plain English if you think it'll be confusing to a
newcomer.

Before I try, let's explore how Ethereum is described by those who develop it.
The home page seems as good a place as any.

[https://www.ethereum.org/](https://www.ethereum.org/)

Here's what the first paragraph on the homepage describes Ethereum as...

"Ethereum is a decentralized platform that runs smart contracts: applications
that run exactly as programmed without any possibility of downtime,
censorship, fraud or third party interference."

So even the Ethereum developers describe the core use as contracts. It doesn't
strike me as a controversial idea.

How would you describe Ethereum?

------
EGreg
It comes down to prior restraint.

With most laws, there is the possibility of breaking them and maybe you have
to face the consequences.

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.

That can be useful. Not for everything, but for a whole lot. The current DRM
stuff works like this.

------
quinndupont
For a less instrumental account, my article with Bill Maurer might be of
interest: [http://kingsreview.co.uk/magazine/blog/2015/06/23/ledgers-
an...](http://kingsreview.co.uk/magazine/blog/2015/06/23/ledgers-and-law-in-
the-blockchain/#top)

It interrogates the intersections between law and contracts as it pertains to
the shift from Bitcoin to Ethereum.

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

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.

~~~
jmcmichael
The event calculus could be used to specify the behavior of the agents
instantiated by ethereum smart contracts. This formalized description of the
smart contract (e.g. a legal system) could then be used to verify its actual
behavior in the wild.

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

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

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

------
bernardvds
Who is behind this? I'm interested in talking to them.

~~~
lukateake
[https://angel.co/ethereum-1](https://angel.co/ethereum-1)

------
swehner
Might work in some areas, but not the ones mentioned.

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

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.

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.

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

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

[further reading]
[https://en.wikipedia.org/wiki/Niklas_Luhmann](https://en.wikipedia.org/wiki/Niklas_Luhmann)
[https://medium.com/@heckerhut/smart-contracts-platforms-
and-...](https://medium.com/@heckerhut/smart-contracts-platforms-and-
intermediaries-c3d30f5182a6)

------
burritofanatic
What is really interesting is when parties sue each other in court over
Ethereum contracts. Courts will always be involved.

------
koudi
Definitely interesting, but how does it help with this?

> even if you "win", you have the problem of collecting.

~~~
lytedev
I think because the actual procedure is included in the script, so
"collection" takes place automatically in the code when it's processed.

------
oafitupa
[http://intheoreum.org](http://intheoreum.org)

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

A better choice for an initial compile target for EtherScript would simply be
English.

~~~
rout39574
English is ridiculously colonized by obfuscators already. Think about the
Clinton I debates on what the meaning of 'is' is.

I think those same obfuscators will be happy to emigrate to any new linguistic
country in which their skills can be put to use, but I think the Etherium
folks are fantasizing that they can make contracts non-ambiguous. Good luck
trying.

I think the problem comes in that the contracts must eventually have impact in
human minds. However you slice it, there's still an interpretation step.
Efforts to make those interpretations unambiguous will be opposed.

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

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.

