What is Ethereum?

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

Yes, there are some things that make me uneasy about this attitude of Ethereum being used as a kind of law. The problem is, traditional law has a some room for the idea of something being "reasonable" or not. I fear it would be quite easy for an disreputable dealer to draw up contracts in code in an obfuscated way, perhaps having hidden subversive behaviour, or clauses that behave in a way different from how a brief inspection would suggest.

This is of course possible in standard law too, hiding clauses in impenetrable legalese. However, in standard law (as far as I know), such tricks don't tend to stand up in court as the behaviour is considered "unreasonable".

Ethereum, being self-enforcing, gives no recourse to victims of tricksters. It's all set in stone.

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.

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

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.