Hacker News Reader

It amazes me that an alpha product (The DAO) is control of ~$150,000,000.

Plus the way that "The DAO" operates is going to be crazy. Basically people submit proposals of things they want the DAO to build, then "The DAO" "hires" contractors to build it (A roundabout way of investment). So Slock.it would be a contractor of "The DAO", but could theoretically be replaced.

But Slock.it is a DAO itself. So basically the chain would look at minimum something like this.

"The DAO" <-> "Proposal" <-> "Contractor Agreement" <-> Slock.it

Bear in mind that "The DAO" and Slock.it are managed by distributed consensus. And what if a company was a contractor to >1 DAO?

Add in all of smart contracts contained in each DAO, the amount of interconnected unmodifiable software that will run these organizations will become staggering. Attempting to design something to be fault free in a normal network is insane, but then you add possibilities for social faults in voting and consensus.

I am sure something like Ethereum will be the future. But the current state is extremely alpha to be handling that sort of financial power.

EDIT:

To prevent a takeover many ethereum contracts will implement an exit strategy, like splitting the minority into a new contract.

You're mostly right, but for the sake of clarity, Slock.it is not a DAO, but a physical corporation in Germany. The actual chain looks something like

"The DAO" <-> "Proposal" <-> Slock.it

The idea is that the DAO 'hires' a contractor, which is Slock.it in this case, which can have all sorts of legal rights/protections/etc. and is a corporation in the physical sense. It gets hired by this nebulous entity, so instead of working for another corporation or individual, it gets hired by the DAO.

And the DAO is also backed by a physical corporation for the purpose of contract signing, I think it's based in Switzerland.

> Even worse, voting on updates is broken by design... a majority of participants could collectively decide to screw over a minority and simply steal their assets by voting in a code update.

Such is life though. It is not just ethereum. Bitcoin cannot survive a majority attack. In the long run, I can't see how even a government can survive a majority attack. One obvious solution to the problem is to try to prevent any one bloc from gaining majority status. I'm sure there are more elaborate solutions though and if any of them is elegant, I'd like to learn about it.

Bitcoin cannot survive a majority attack.

Proof of work is a different kind of majority though.

> I can't see how even a government can survive a majority attack.

https://en.wikipedia.org/wiki/Gerrymandering_in_the_United_S...

Governments might not be immune from a sustained majority attack, but that's the point... governments are large entities that (hopefully) operate at large timescales and have some degree of inertia and stability.

In turn, governments provide recourse and security for smaller, constituent systems (companies and individuals.) As long as the government remains intact (or intact enough), it can be a an arbiter and enforcer between the smaller entities (i.e, the entire legal system).

With Ethereum, there is no arbiter. There is only the exact code of the contract. It is entirely possible that the code is flawed in a way that is disadvantageous to all parties, such that they cannot change it, or that a mistake was made that allows one or more parties to act in violation of the "spirit" of the agreement.

Of course, some of these situations can be foreseen and accounted for (exit clauses, consensus code updates, etc.) But not everything can be foreseen, and the irony is that the more situations are explicitly accommodated for, the more surface area there will be for difficult-to-detect edge cases.

The legal system has built in resiliency, due to multiple fallback layers of (hopefully) impartial arbiters to add a layer of empathy and judgement on top of the strict letter of the law. It's not perfect, but it works.

Unless Ethereum can find some equivalent, I cannot see it taking over anything but certain types of very well-understood transactions. Don't get me wrong, that still has value... automated escrow, options & futures trading (etc.) is huge. But until this problem is solved, effective DAOs are a pipe dream.

Computer programming is so error prone, it's hard to see how it could ever be used for critical applications.

Can't tell if this is sarcasm or not

Not

>Bitcoin cannot survive a majority attack.

This is true bitcoin cannot survive a majority attack. But the amount of resources needed to form a majority attack would be better used to just mine bitcoin.

Attacking the network for the sake of attacking it would be very expensive and would basically devalue BTC, which I'm assuming would remove any initial incentive.

In theory. Who said an attack would happen by allocating computing resources? That strikes me as https://xkcd.com/538/. Suppose that the majority of the miners are allied with a small number of organizations. People/organizations with sufficient influence can strike deals with those organizations to orchestrate a majority attack.

> Who said an attack would happen by allocating computing resources?

> Suppose that the majority of miners

Doesn't the "majority of miners" being in on it mean the same thing as "allocating computing resources"?

I suppose that's a matter of definition. I read "allocating computing resources" as "building/buying more hardware". That should indeed be unfeasible. But using social means to gather support from other people who have already allocated computing resources should be a lot more feasible.

Yeah, a lot more feasible but not less suicidal. The idea is that if miners were to band together to abuse their power and rig the system, the larger population would lose faith in Bitcoin's ability to accurately serve as an accounting mechanism, no longer value it, and Bitcoins would be worthless. Now the money the miners stole is worthless and their equipment is worthless. So it's suicidal for them to try to rig the system. They can't gain from it.

One solution would be to have "curators" with an expanded role. These curators would have dictatorial powers (via a supermajority vote of the curators) to nullify and replace the entire contract. However, they would promise to do this only in case of a genuine software bug, or if ordered to do so by a court with jurisdiction over them, not for any other reason. There would be many curators. Many of them would be professional curators, similar to professional accountants or trust executors, who work for huge firms which, like Big Four accounting firms, have a lot to lose if any of their members are caught misusing their power.

Yes, the Turing completeness of Ethereum means it suffers from the unsolvable halting problem. There is no way to prove that a given Ethereum program does not have a bug that will cause it to halt at some point in the future. Thus it is dangerous to rely on an Ethereum contract as the sole means of releasing funds.

The voting problem is a more obvious flaw. There seems to be a naive optimism on the part of certain developers that simple voting rules will surface the best quality viewpoints. This is fine in hackernews, but is not OK for open source software development.

All Ethereum contracts halt. Performing operations requires spending ether (which is paid to miners) and there's a maximum amount of ether which can be spent per transaction. The more operations your contract performs, the more you have to pay. If you try to perform too many operations, the miner will bail.

OK, but that is not "halting" in the sense of the halting problem. That is a design feature of ETH.

But wasn't your argument that "Ethereum ... suffers from the unsolvable halting problem" and that "there is no way to prove that a given Ethereum program does not have a bug that will cause it to halt at some point in the future"?

All Ethereum transactions can be proven to halt.

That does of course mean Ethereum isn't really Turing complete, just an approximation.

Any program running on a Turing machine is subject to the halting problem. You may very well find a bug or feature that causes such a program to stop running or halt. This discovery still does not disprove the statement, that it is impossible to prove a program will not halt. Thus your observation does not flow logically.

As pointed out, Ethereum is not infinite, thus not a Turing machine, and therefore does not exhibit a "halting problem".

There's a limit to the number of "cycles" spent on each program in proportion to how much funding they have. It's like a smaller version of the halting problem where you only have to say if a program will halt in five seconds or not.

Turing machines are a theoretical construct, be careful when trying to reason about the real world based on them.