Hacker News Reader

Comment by mbrock | Hacker News Reader

You know Bitcoin is useful. One of the useful things in Bitcoin is that you can make a transaction conditional on a multiparty approval ("multisig"). This is used by many organizations to control funds in a safe way. Ethereum lets you construct even more interesting types of transactions. For example you can easily implement the logic of a crowdfunding (unless X is raised by time Y everyone is refunded). In that context, "smart contract" is just a way of saying that you're not relying on the promise of a third party to perform the refund—it's automatic.

View on HN

> In that context, "smart contract" is just a way of saying that you're not relying on the promise of a third party to perform the refund—it's automatic

What if the code is malicious, and instead of auto refund it steals the money? I mean, not everyone would read the code to see what it really does, so what happens in that case?

That is a very good question that is the subject of a lot of denial. You might want to read about the DAO hack and the Parity wallet hack. You will notice there are two different possible outcomes: in the first case, some of the Ethereum founders were major victims, and they used their influence to persuade a majority of the miners to implement a 'hard fork' to essentially roll back the blockchain. In the second case, the victims do not appear to be well-connected, and it seems their missing ~$30M of Eth is irretrievably lost (and it is not clear to me that a second hard fork would be feasible at this point, regardless of who the victims are.)

> I mean, not everyone would read the code to see what it really does, so what happens in that case?

This is true with real world contracts too, that's why people hire lawyers - they understand the "code" of contract law.

Except that in real-world contract and criminal law, there are various mechanisms that attempt, with some degree of success, to dissuade fraudulent behavior and allow for some form of restitution. Blockchain currencies, on the other hand, have been promoted partly on the premise that they are free of this sort of governmental interference.

Promoters gonna promote. Governments gonna govern.

You can put anything in "real world" contracts (in a 'put words on the paper' sense), but there are things that would be considered illegal if brought to court. In a sense there are reasonable defaults. So if you sign without reading a contract that 'you sell your self as a slave to me' this contract would have no power because slavery is illegal.

But real world contracts are never 100% clear, and can be modified retroactively in court when their terms violate the law, are vague, or are otherwise deemed unenforceable.

So can "smart contracts".

Unless the attacker is careless enough to reveal his identity, or puts his ill-gotten gains at risk of being hacked back, or the victims are Ethereum foundation members, your chances of restoration are slim to none.

So I'm actually at a disadvantage here, compared to plain old contracts.

Yes. If one party makes a mistake, or does something underhanded/surreptitious, you have no recourse. This exact situation (a bug in the DAO contract leading to a malicious actor stealing from the DAO) led to the recent Ethereum fork: https://news.ycombinator.com/item?id=14819268

Well, the Ethereun fork itself reveals that there is some recourse.

It may be less attractive recourse than exists with plain contracts for many potential participants, though.

Sort of, but it's also insane. Forking Ethereum because of the DAO hack is a bit like forking the US dollar after the crash of 1929.

Which is just my point. It's not that no means of recourse exists outside the contract code; it's that there exists no option between zero and global thermonuclear war. The broad range of subtleties that contract law has developed to answer complex situations, and the option to exercise judgment in those cases not yet captured by precedent, is completely absent in Ethereum, because the people who designed it saw no reason why any such thing should be needed.

Unfortunately, that they failed to see it doesn't mean it isn't so, and now every new conflict among blockchain participants is an exciting new opportunity to reinvent another piece of several hundred years' worth of too hastily discarded prior art.

We did devalue the dollar against the gold standard significantly in 1934. Not entirely unlike a "fork", since it's a declaration that, whoops, your dollars are now worth 40% less gold than you thought.

In 1931 Britain floated the pound, which arguably the US ought to have done too. Suddenly, your paper is no longer convertible to gold at a fixed rate. That's an even more dramatic change than the Ethereum fork.

More accurately - judges and lawyers interpret law, contract and otherwise. This sort of interpretation is explicitly ruled out in Ethereum's case, except when enough stakeholders decide it's not.

One approach is that contracts can be associated with their hash. It is a bit silly for everyone to be writing the same smart contract over and over, with some versions being erroneous or malicious. So instead of having to run a potentially malicious contract, you are given a hash that points to one of a few different smart contracts that are known to be safe. The community has "white listed" a bunch of these known contracts and their hashes, so you are relatively safe using any contracts in these lists. Most miners in various cryptocurrencies will only run code that is on their communities version of the whitelist. Of course this only helps with some issues, not all.

*edit: and this is not ethereum specific. This approach was one way bitcoin tried to solve the problem and it has spread to most other cryptocurrencies I believe.

There's no good solution for that problem yet. It's still in some sense better than centralized trust, because you can in principle understand the contract code. But we need to develop much better tools for auditing. Fortunately that's a really fun and interesting problem to work on!

Ok but that raises a lot of technical questions. Do I myself host that logic or is the logic itself distributed? While creating a crowdfunding contract, I am the host in my mind so assuming that the smart contract is hosted on my machines this must mean that when people are sending Ethereum to my wallet the logic does it's thing?

Another version of that could be that the logic is sent out to all interested peers and they only actually send Ethereum to the correct wallet after the logic in the contract they got sent is executed.

This is the parts of Ethereum that is so very confusing. People are simply swinging around with words like "smart contracts" but there are little to no actual description on how it actually works.

The logic exists on the block chain. It is executed on each and every machine that follows the chain. This is how executions are verified, 'everyone' has to agree on the outcome.

Sorry for being so uninformed but what happens if there is an error in the logic? Doesn't that mean that it's not possible to update the smart contract?

There have already been multiple incidents involving bugs in "smart contract" code being exploited to steal funds, one within the past few days[1]. A particularly nasty case involved something called "the DAO", which was an attempt to do something like a distributed VC fund, but had a bug which allowed any participant to steal all funds contributed. That one got backed out by a hard fork of the Ethereum blockchain, but that's obviously not a stable or scalable solution to dealing with these types of situations going forward.

[1] https://www.theregister.co.uk/2017/07/20/us30_million_below_...

Basically yes, and this is reasonable from a security perspective, otherwise every smart contract would basically have a trusted administrator.

But in many cases you do want some ability to upgrade the code, and then you simply program in that ability by creating a repointable proxy with whatever authorization logic you want.

Yes the block chain is by definition immutable. So no means to update the contract the only way if it is a ENORMOUS mistake would be to fork it: read about DAO hack FYI

>what happens if there is an error in the logic?

If you are a big name in the Ethereum community, they will soft fork Ethereum so that your mistake is rolled back.

That isn’t true. Nowadays you can’t fork Ethereum like that by fear of losing legitimate transactions.

>That isn’t true

Precedent seems to indicate otherwise.

Of course there are a lot of technical questions. To answer this one, the logic is distributed and executed on every full node. It's like one big distributed database where a transaction can also create a stored procedure.

No the smart contract is on the blockchain and executed by the nodes. Never on your specific host alone

When you write a smart contract, the natural route is to deploy it into the Ethereum public network. Otherwise, your contract is only accessible to your own private channel and uses your own tokens (as opposed to Ether), etc.

Some clarifications: Ethereum = the project or the foundation itself Ether = unit of (crypto)currency used in Ethereum

Just shifting the problem. Okay, so the money is raised... you still never get your vaporware product.

You could program a smart contract to say "unless greater than half of funders agree tbat the product was shipped, refund everyone's money"

It's a programmable decentralized escrow

What incentive do the funders have to agree that the product was shipped?

I mean, it's pretty obvious that such agreement on the part of the funders increases the likelihood that they will lose their money. So why agree?

I guess the person shipping the product could hope that the funders aren't assholes or theives and actually will agree that the product was shipped when it ships, but isn't the smart contract supposed to make such human signs of good will unnecessary? Otherwise, why have a smart contract (or any contract, really), as you can just rely on the good will of the participants?

Reply on news.ycombinator.com