iamnotback (OP)
|
|
June 21, 2016, 01:27:49 PM Last edit: June 21, 2016, 01:37:51 PM by iamnotback |
|
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.
|
|
|
|
|
|
"Bitcoin: mining our own business since 2009" -- Pieter Wuille
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
iamnotback (OP)
|
|
June 21, 2016, 04:53:07 PM |
|
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
|
|
June 21, 2016, 05:44:35 PM |
|
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
Legendary
Offline
Activity: 1484
Merit: 1026
In Cryptocoins I Trust
|
|
June 21, 2016, 06:01:22 PM |
|
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 (OP)
|
|
June 27, 2016, 01:02:14 AM Last edit: June 27, 2016, 02:12:46 AM by iamnotback |
|
|
|
|
|
|
funkenstein
Legendary
Offline
Activity: 1066
Merit: 1050
Khazad ai-menu!
|
|
June 27, 2016, 07:45:05 AM |
|
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 (OP)
|
|
July 03, 2016, 12:11:32 PM |
|
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 (OP)
|
|
July 12, 2016, 08:29:34 PM |
|
My analysis of Paul Sztorc's blog post about oracles, smart contracts, and side-chains is relevant to this thread.
|
|
|
|
|