Valid uses cases for Smart Contracts, Dapps, and DAOs?

[iamnotback]

Research paper has a section that mentions some smart contract use cases:

http://publications.lib.chalmers.se/records/fulltext/234939/234939.pdf#page=12

Note that paper above is claiming some classes of programming errors can be avoided in smart contracts by using dependent and polymorphic types. But as I wrote upthread, that won't eliminate semantic bugs such as game theory bugs. See for example §4.3 Misaligned Incentives in the following paper:

http://eprint.iacr.org/2015/460.pdf#page8

Generally speaking, as I explained by example of the Halting problem, the runtime entropy of a Turing-complete machine is unbounded. Thus there are an unbounded number of ways to create errors, regardless of any fancy typing system and programming paradigm.

I totally agree with you. More to follow...

I don't think there is any fail-proof encapsulation for Turing-complete smart contract failure. Each smart contract needs to be extremely well vetted before people invest a lot of money in that specific smart contract. The market will eventually learn this.

[iamnotback]

An Uber (ArcadeCity) example use of a smart contract, explained by Gavin Wood.

The key factor in terms of viability are the data feeds external to the block chain for the GPS coordinates. This is what I had already stated (in the Ethereum Paradox thread) would break Nash equilibrium, because different miners could be gamed by lies about external data.

What I realized recently is that the contract can be set up to trust a set of M-of-N signers to confirm the external data feed and those signatures are final (regardless if the data is a lie). The problem with this of course is the same problem as The DAO failure has revealed. Which is that a big enough lie (theft) can destroy the Nash equilibrium, causing the majority consensus to decide between several imperfect courses of action. This is what we mean by broken Nash equilibrium, because the miners no longer have just one optimum strategy.

So I still maintain what I had originally concluded in the Ethereum Paradox thread, which is that smart contracts with external data feeds break Nash equilibrium, unless we can be sure the validation of those data feeds can't be aggregated and become Too Big To Fail. So if we can insure that validation by M-of-N of external data is decentralized and granular, then we can use data feeds. Otherwise we can not.

[thaaanos]

One use case I expect to become a reality is the following:
As we see our economies drift into deflation more and more products will be produced on demand to minimize inventory.
So customers will be required to pre-order stuff instead of taking stuff of the shelf.

Now producer in order to minimize supply risk can pre-arrange a smart-contract that will split funds from his input directly  to the supplier at a determined price. Likewise the supplier has contracts with his suppliers etc.
So the moment a customer pays up a contract funds flow across this network of suppliers and production is triggered with minimum overhead. A contract may also choose from various suppliers based on price, production time, location etc so as to minimize price or delivery time based on end-user preference.

[CoinHoarder]

I haven't read the thread, but one use case that probably hasn't been mentioned is market pegged cryptocurrencies (IE. Bitshares' bitUSD, bitEURO bitGOLD, bitAPPLE, bitOIL, bitGOOG, etc.)

[iamnotback]

Valid use cases, layman's explanation:

http://www.coindesk.com/ethereum-overwhelmed-layman/

Here comes MIT's ChainAnchor to Ethereum:

https://www.cs.cornell.edu/people/egs/papers/2016-06-21-dao-meetup.pdf
http://initc3.org/
http://hackingdistributed.com/2016/06/22/smart-contract-escape-hatches/

[iamnotback]

https://www.reddit.com/r/ethereum/comments/4pyk1d/balaji_srinivasan_on_bitcoin_vs_ethereum/

https://www.linkedin.com/in/balajissrinivasan

[funkenstein]

Valid use cases, layman's explanation:

http://www.coindesk.com/ethereum-overwhelmed-layman/

Lol!  What a pile of garbage.  Apparently the only valid use-case is a set of different computers which use it to somehow open and unlock a door to an apartment. 

You couldn't make this shit up!! 

[iamnotback]

Technical issue:

For brevity it’s worth to explain that in the process of soft fork application it appeared that there’s a gas problem leading to the attacker being able to DoS miners. Shortly, the attacker could send very computation expensive transactions with declared high gas to be paid (to be prioritized), but as the soft fork would make miners reject all such transactions, no gas will be billed while computation will be performed (and empty blocks added). The network could deal with it. But the load would be high as well as a bloat of empty blocks. Perhaps other adverse effects could also take place.

Speaking about adverse effects, almost a year ago a paper was published by Luu, Teutsch, Kulkarni and Saxena regarding “verifiers dillema”. It was discussed by Vitalik on reddit here. While at the time it was purely academic divagation it appears that with soft fork applied it would cause really important issues. Given an example scenario when the attacker starts spamming the network, some miners could even cease processing transactions (miners cannot be considered network friendly actors by default, only by incentive). If the ratio of miners with soft fork applied would fall below the limit the attacker’s transactions would eventually pass.

The above exposes both strong and weak points of Ethereum network. And actually strong points, as ingenious gas economy and Turing completness are also weak ones. On one hand for instance gas economy precisely regulates computing, on the other it must be fine tuned and is very fragile. So fragile that can lead to network-wide problems.
In parallel, Turing completness gives enormous possibilities in terms of possible computations performed by the network, at the same time contributing to unpredictability of computations before they are performed, thus inability to halt malicious ones (in easy way).

I’m afraid that there is no good scenario for any soft fork that could cover all possible side effects. Exactly because of the two factors mentioned above.

[iamnotback]

My analysis of Paul Sztorc's blog post about oracles, smart contracts, and side-chains is relevant to this thread.