Topic: Valid uses cases for Smart Contracts, Dapps, and DAOs? (Read 4686 times)
My analysis of Paul Sztorc's blog post about oracles, smart contracts, and side-chains is relevant to this thread.
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.
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.
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!!
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/
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/
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.)
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.
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.
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.
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.
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.
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.
Mircea Popescu, the pragmatic genius hacker who drained the DAO in order to defend crypto-currency against retards who want to centralize crypto-currency, has written something about contracts which I entirely agree with. In fact, my conceptualization of the way a DAO should be constructed is based on the similar insight, and I arrived at my insight independently and before reading the following epistle.
Let's not forget the Spaniards traded to the native a mirror for his acreage, then employed the force of contracts to enforce the absurdity.
Techno-anarchism. Amen!
Let's not forget the Spaniards traded to the native a mirror for his acreage, then employed the force of contracts to enforce the absurdity.
Quote from: http://trilema.com/2012/gpg-contracts/
Traditionally, contracts are instruments of torture. People agree to be married (thus entering into, of course, a Marriage Contract) and then have to suffer their spouse whether they'd like to or not.
...
The problem with this holy institution that has carried us so very far and fed us so very well is that it has costs, and those costs have the unfortunate property that they mount with use.
...
Why would the cost of enforcing a contract increase with the amount of contracts already entered into ? Well, because as people use them people also look for ways to abuse them. As these ways are found they have to be patched. As the patches are applied new holes are found, so new patches are issued. Sometimes the patches work better in some cases than others, in the end it's not even obvious which would be the proper case a contract falls into, the administration of all this has some costs and moreover due to the adversarial nature of contractsvii there's always someone with an incentive to argue absolutely anything, no matter how "insane". Besides, what's insane anymore once we have contracts ?
...
I know plenty of people who have dispensed with even entering into contracts altogether, as a point of principle. Silicon Valley deals would be anywhere between one third and two thirds undocumented to any degree - only when companies are about to go public does a mad rush commence to retroactively document years' worth of... contracts, they would be, except they weren't. Why not ? Because contracts are just too damned expensive, both to enter into rationally and then to enforce against the other party. The attempts mostly end up as a competition of "who has the largest bank account" and therefore can afford the best lawyers, and since this is known at the outset the only real believers in the entire contract-with-enforcement construct are, predictably, the very large corporations.
...
And so here we are today : contract litigation is a great way to earn a living as a lawyer, a premier way to generate that mostly fake "social mobility" and a great way for Apple, Samsung and obviously the US government to fill their otherwise idle time during board meetings. Most common claims are not pressed, and in the rare instance they are pressed would end up in something called "Small Claims", which is much akin to the lost and found box they used to keep in train stations and movie theatres.
...
Who today would or will be able to set aside the perhaps justified objections of the disenfranchised parties (which would necessarily exist) to create a new code, and somewhat reset the clock ? Nobody, practically speaking, it'd have to be done by "consensus" and "negotiation" which is to say it'd be much better for it to not be done at all. In short, this great dragon called Contract has flown as far as he can. He is old now, and tired. His bones ache, his mood is sour, he will soon go below the ground. We will forever remember it, or at any rate I will, but for what he was in his youth, and that youth was much, much before your parents were being born I would think.
So what now ?
Well... I'm glad you asked. There's a spiffy young fellow I'm betting on : the GPG Contract. He's also a. an agreement b. reached by willing participants. But that's all.
What do I mean "that's all" ? I literally mean, that's all. A contract which is entered into by willing participants and won't be enforced. Nonsense ? IKR!
Except not really. Obviously entering into a GPG Contract thinking it's an Old Contract is nonsense, and will get you burned. In fact the history of "scams" in the Bitcoin space is pretty much this, people behaving with what should really be GPG Contracts as if they were Old Contracts, and then discovering midway through that... well... it doesn't really work that way.
All this aside, non-enforced contracts, contracts which the participants uphold out of their own free will rather than at the behest of some third party or by the point of the sword of some blind demigoddess are a thoroughly fascinating turn of events. For one, they are fundamentally human, they're one step up on the stairwell of freedom. Do it if you think it's right is certainly a lot more empowering, civilised and overall good than "do it or else". For the other, they allow all the enforcing to happen before the actual contract is entered into. Old contracts contain unknown future costs, nobody can ever tell you exactly how much will you have to pay in legal fees to recoup this five hundred owed on whatever deal. GPG Contracts don't have any future costs at all. The cost of enforcing one after the fact is always going to be zero, pretty much because there's never going to be anything you need (or indeed can) do.
And it doesn't stop here. I have always thought the principal utility of Bitcoin is that it renders any sort of mandatory taxation model unviable. I am firmly persuaded that as Bitcoin takes holdix taxes will have to return to what they were in ancient Greece : willing donations to the state treasury, and something people openly took pride in. This shift will bring about all the improvements we were vainly trying to achieve in the old money paradigm, such as public accountability and reasonable expenditure in one fell swoop : good luck getting people to donate to the police department if they don't like the police. And good luck with the welfare programs, for sure.
Add to that a shift of contracts from the old model to the new and suddenly you have - and I mean this quite literally - a new Renaissance. Man at the center of all things. Man, the willing enforcer of his own promises. Man, the willing contributor to the wealth of an obviously much reduced, but by that fact probably much nicer, lovable and huggable cute little state.
I'm crying with joy over here, my toes are curling in untold glee, I have little doubt that I shall live to see this, all of it. And for the first time in many, many years I feel again like the world is worth living in.
...
The problem with this holy institution that has carried us so very far and fed us so very well is that it has costs, and those costs have the unfortunate property that they mount with use.
...
Why would the cost of enforcing a contract increase with the amount of contracts already entered into ? Well, because as people use them people also look for ways to abuse them. As these ways are found they have to be patched. As the patches are applied new holes are found, so new patches are issued. Sometimes the patches work better in some cases than others, in the end it's not even obvious which would be the proper case a contract falls into, the administration of all this has some costs and moreover due to the adversarial nature of contractsvii there's always someone with an incentive to argue absolutely anything, no matter how "insane". Besides, what's insane anymore once we have contracts ?
...
I know plenty of people who have dispensed with even entering into contracts altogether, as a point of principle. Silicon Valley deals would be anywhere between one third and two thirds undocumented to any degree - only when companies are about to go public does a mad rush commence to retroactively document years' worth of... contracts, they would be, except they weren't. Why not ? Because contracts are just too damned expensive, both to enter into rationally and then to enforce against the other party. The attempts mostly end up as a competition of "who has the largest bank account" and therefore can afford the best lawyers, and since this is known at the outset the only real believers in the entire contract-with-enforcement construct are, predictably, the very large corporations.
...
And so here we are today : contract litigation is a great way to earn a living as a lawyer, a premier way to generate that mostly fake "social mobility" and a great way for Apple, Samsung and obviously the US government to fill their otherwise idle time during board meetings. Most common claims are not pressed, and in the rare instance they are pressed would end up in something called "Small Claims", which is much akin to the lost and found box they used to keep in train stations and movie theatres.
...
Who today would or will be able to set aside the perhaps justified objections of the disenfranchised parties (which would necessarily exist) to create a new code, and somewhat reset the clock ? Nobody, practically speaking, it'd have to be done by "consensus" and "negotiation" which is to say it'd be much better for it to not be done at all. In short, this great dragon called Contract has flown as far as he can. He is old now, and tired. His bones ache, his mood is sour, he will soon go below the ground. We will forever remember it, or at any rate I will, but for what he was in his youth, and that youth was much, much before your parents were being born I would think.
So what now ?
Well... I'm glad you asked. There's a spiffy young fellow I'm betting on : the GPG Contract. He's also a. an agreement b. reached by willing participants. But that's all.
What do I mean "that's all" ? I literally mean, that's all. A contract which is entered into by willing participants and won't be enforced. Nonsense ? IKR!
Except not really. Obviously entering into a GPG Contract thinking it's an Old Contract is nonsense, and will get you burned. In fact the history of "scams" in the Bitcoin space is pretty much this, people behaving with what should really be GPG Contracts as if they were Old Contracts, and then discovering midway through that... well... it doesn't really work that way.
All this aside, non-enforced contracts, contracts which the participants uphold out of their own free will rather than at the behest of some third party or by the point of the sword of some blind demigoddess are a thoroughly fascinating turn of events. For one, they are fundamentally human, they're one step up on the stairwell of freedom. Do it if you think it's right is certainly a lot more empowering, civilised and overall good than "do it or else". For the other, they allow all the enforcing to happen before the actual contract is entered into. Old contracts contain unknown future costs, nobody can ever tell you exactly how much will you have to pay in legal fees to recoup this five hundred owed on whatever deal. GPG Contracts don't have any future costs at all. The cost of enforcing one after the fact is always going to be zero, pretty much because there's never going to be anything you need (or indeed can) do.
And it doesn't stop here. I have always thought the principal utility of Bitcoin is that it renders any sort of mandatory taxation model unviable. I am firmly persuaded that as Bitcoin takes holdix taxes will have to return to what they were in ancient Greece : willing donations to the state treasury, and something people openly took pride in. This shift will bring about all the improvements we were vainly trying to achieve in the old money paradigm, such as public accountability and reasonable expenditure in one fell swoop : good luck getting people to donate to the police department if they don't like the police. And good luck with the welfare programs, for sure.
Add to that a shift of contracts from the old model to the new and suddenly you have - and I mean this quite literally - a new Renaissance. Man at the center of all things. Man, the willing enforcer of his own promises. Man, the willing contributor to the wealth of an obviously much reduced, but by that fact probably much nicer, lovable and huggable cute little state.
I'm crying with joy over here, my toes are curling in untold glee, I have little doubt that I shall live to see this, all of it. And for the first time in many, many years I feel again like the world is worth living in.
Techno-anarchism. Amen!
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.
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...
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.
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.
Smooth and I discussing the optimum way of funding/launching development, and the Nash equilibrium of block chains.
Ethereum, Blockstream (Bitcoin core), BitShares, DASH all break Nash equilibrium.
Ethereum, Blockstream (Bitcoin core), BitShares, DASH all break Nash equilibrium.
I agree with smooth, there should be no DAO nor governance (i.e. no voting, not even from miners) in control of forking the block chain. The DAOs should only be for decentralizing projects and organizations (including corporations). DASH and Bitshares have this incorrect PoS+governance design and Ira Miller@DASH is incorrect about automation being unrealistic or evil:
so how can you shut down a decentralized autonomous organization?
Do you know any decentralized autonomous organization ?
I don't ..
Yes, DASH.org. The first DAO.
The difference: Marketing that feature is taking a backseat to development. Doing it right I'd say.
DASH does seem to be a functioning DAO where D is distributed but sure if it is decentralized control. The stakeholders apparently vote on the actions or management of the development of the open source. The stakeholders apparently approved to have % of the mining rewards paid to a foundation which then distributes the funds according to projects approved by votes of the stakeholders. However what is not clear to me is to what degree this is all enforced by smart contract protocol or done manually by the foundation.
There are allegations however that the distribution of the DASH tokens were highly concentrated by an alleged instamine and subsequent masternode ROI scheme which may have further concentrated the tokens held by the core insiders. But I don't know if anyone has been able to prove conclusively that DASH is not really decentralized, although the suspicion is apparently strong amongst some especially Monero supporters.
Just turing complete...
https://www.reddit.com/r/btc/comments/4op2es/the_bug_which_the_dao_hacker_exploited_was_not/
https://www.reddit.com/r/btc/comments/4op2es/the_bug_which_the_dao_hacker_exploited_was_not/
I haven't studied the specific vulnerability in this case[1], but I think it has to do with the contract code doing mutability aliasing on global state. So this is an issue of synchronizing mutability aliasing.
For example, imagine if some intended to be atomic operation[1] of a check for sending of ETH out of the contract had not set a global count of sent before some recursion which enabled sending more ETH out, thus exceeding the threshold.
So the Reddit post seems to be somewhat clueless...
So now the experts finally figure out that the vulnerability is more general as I had written above as quoted. So who is the expert here.
So any state influencing the logic of any procedure non-atomically is vulnerable to attack if interrupted by a call to an arbitrary contract. This goes far beyond the “write functions that are reentrant” suggestion: instead write functions that either don’t call out to arbitrary contracts or make no assumptions about their control flow or state after doing so.
Okay. That is too technical. It is beyond my understanding. Do you mind explaining it in layman terms or, at least in bachelor's level?
Does this help?
http://ebiquity.umbc.edu/blogger/2008/01/19/how-dr-suess-would-prove-the-halting-problem-undecidable/
Scooping the Loop Snooper
an elementary proof of the undecidability of the halting problem
Geoffrey K. Pullum, University of Edinburgh
No program can say what another will do.
Now, I won’t just assert that, I’ll prove it to you:
I will prove that although you might work til you drop,
you can’t predict whether a program will stop.
Imagine we have a procedure called P
that will snoop in the source code of programs to see
there aren’t infinite loops that go round and around;
and P prints the word “Fine!” if no looping is found.
You feed in your code, and the input it needs,
and then P takes them both and it studies and reads
and computes whether things will all end as they should
(as opposed to going loopy the way that they could).
Well, the truth is that P cannot possibly be,
because if you wrote it and gave it to me,
I could use it to set up a logical bind
that would shatter your reason and scramble your mind.
Here’s the trick I would use – and it’s simple to do.
I’d define a procedure – we’ll name the thing Q –
that would take any program and call P (of course!)
to tell if it looped, by reading the source;
And if so, Q would simply print “Loop!” and then stop;
but if no, Q would go right back to the top,
and start off again, looping endlessly back,
til the universe dies and is frozen and black.
And this program called Q wouldn’t stay on the shelf;
I would run it, and (fiendishly) feed it itself.
What behaviour results when I do this with Q?
When it reads its own source, just what will it do?
If P warns of loops, Q will print “Loop!” and quit;
yet P is supposed to speak truly of it.
So if Q’s going to quit, then P should say, “Fine!” –
which will make Q go back to its very first line!
No matter what P would have done, Q will scoop it:
Q uses P’s output to make P look stupid.
If P gets things right then it lies in its tooth;
and if it speaks falsely, it’s telling the truth!
I’ve created a paradox, neat as can be –
and simply by using your putative P.
When you assumed P you stepped into a snare;
Your assumptions have led you right into my lair.
So, how to escape from this logical mess?
I don’t have to tell you; I’m sure you can guess.
By reductio, there cannot possibly be
a procedure that acts like the mythical P.
You can never discover mechanical means
for predicting the acts of computing machines.
It’s something that cannot be done. So we users
must find our own bugs; our computers are losers!
Too long, did actually read; now head hurts and nose is bleeding.
But seriously, thank you, that Turing completeness shit was jibber jabber nonsense until that poem. I get it now
Let me provide a simplistic explanation of the Halting problem.
We have a program P which inputs the source code of other programs and the result of P is the result of the analysis of whether the input source code loops forever or terminates (i.e. halts).
We have another program Q which inputs the source code of a program and calls P, then prints "Loop" and terminates if P reports "Loop", otherwise Q loops.
So we call Q passing the source code of Q to itself, but this is a paradox because P can't decide what the result would be. If P's result is "Loop", then Q terminates. If P's result is "terminates", then Q loops. We have an inconsistency in both cases.
This shows that it is impossible to make a compiler that acts like P, i.e. it is impossible to analyze whether programs with unbounded recursion terminate or not, because recursion is decided (unbounded) at runtime and not at compile-time. Thus at compile-time the result of the question is undecideable.
QED.
I'm with you and thanks for putting it more eloquently than I ever could. I invested in DAO and agree that it should cut its loses for now. I still believe in a DAO and all that it will stand for, basically giving the little man the opportunity to invest whee only VC funds could in the past. Why others are so virulently against this right is beyond me. One day I expect after all this is blown over there will be a DAO2.0. Just with better coders.
Also, I don't know if better coding is the answer ultimately. Things need to progress on the basis that smart contract code will fail, not that it won't. There are a huge amount of use cases where the value doesn't actually have to be held by the contract.
toknormal, very astute. That is indeed part of the solution.
Minecache, the problem with The DAO is not only bad code, but also the design was game theory broken as well.
Okay. That is too technical. It is beyond my understanding. Do you mind explaining it in layman terms or, at least in bachelor's level?
Does this help?
http://ebiquity.umbc.edu/blogger/2008/01/19/how-dr-suess-would-prove-the-halting-problem-undecidable/
Scooping the Loop Snooper
an elementary proof of the undecidability of the halting problem
Geoffrey K. Pullum, University of Edinburgh
No program can say what another will do.
Now, I won’t just assert that, I’ll prove it to you:
I will prove that although you might work til you drop,
you can’t predict whether a program will stop.
Imagine we have a procedure called P
that will snoop in the source code of programs to see
there aren’t infinite loops that go round and around;
and P prints the word “Fine!” if no looping is found.
You feed in your code, and the input it needs,
and then P takes them both and it studies and reads
and computes whether things will all end as they should
(as opposed to going loopy the way that they could).
Well, the truth is that P cannot possibly be,
because if you wrote it and gave it to me,
I could use it to set up a logical bind
that would shatter your reason and scramble your mind.
Here’s the trick I would use – and it’s simple to do.
I’d define a procedure – we’ll name the thing Q –
that would take any program and call P (of course!)
to tell if it looped, by reading the source;
And if so, Q would simply print “Loop!” and then stop;
but if no, Q would go right back to the top,
and start off again, looping endlessly back,
til the universe dies and is frozen and black.
And this program called Q wouldn’t stay on the shelf;
I would run it, and (fiendishly) feed it itself.
What behaviour results when I do this with Q?
When it reads its own source, just what will it do?
If P warns of loops, Q will print “Loop!” and quit;
yet P is supposed to speak truly of it.
So if Q’s going to quit, then P should say, “Fine!” –
which will make Q go back to its very first line!
No matter what P would have done, Q will scoop it:
Q uses P’s output to make P look stupid.
If P gets things right then it lies in its tooth;
and if it speaks falsely, it’s telling the truth!
I’ve created a paradox, neat as can be –
and simply by using your putative P.
When you assumed P you stepped into a snare;
Your assumptions have led you right into my lair.
So, how to escape from this logical mess?
I don’t have to tell you; I’m sure you can guess.
By reductio, there cannot possibly be
a procedure that acts like the mythical P.
You can never discover mechanical means
for predicting the acts of computing machines.
It’s something that cannot be done. So we users
must find our own bugs; our computers are losers!
Too long, did actually read; now head hurts and nose is bleeding.
But seriously, thank you, that Turing completeness shit was jibber jabber nonsense until that poem. I get it now
Okay. That is too technical. It is beyond my understanding. Do you mind explaining it in layman terms or, at least in bachelor's level?
Does this help?
http://ebiquity.umbc.edu/blogger/2008/01/19/how-dr-suess-would-prove-the-halting-problem-undecidable/
Scooping the Loop Snooper
an elementary proof of the undecidability of the halting problem
Geoffrey K. Pullum, University of Edinburgh
No program can say what another will do.
Now, I won’t just assert that, I’ll prove it to you:
I will prove that although you might work til you drop,
you can’t predict whether a program will stop.
Imagine we have a procedure called P
that will snoop in the source code of programs to see
there aren’t infinite loops that go round and around;
and P prints the word “Fine!” if no looping is found.
You feed in your code, and the input it needs,
and then P takes them both and it studies and reads
and computes whether things will all end as they should
(as opposed to going loopy the way that they could).
Well, the truth is that P cannot possibly be,
because if you wrote it and gave it to me,
I could use it to set up a logical bind
that would shatter your reason and scramble your mind.
Here’s the trick I would use – and it’s simple to do.
I’d define a procedure – we’ll name the thing Q –
that would take any program and call P (of course!)
to tell if it looped, by reading the source;
And if so, Q would simply print “Loop!” and then stop;
but if no, Q would go right back to the top,
and start off again, looping endlessly back,
til the universe dies and is frozen and black.
And this program called Q wouldn’t stay on the shelf;
I would run it, and (fiendishly) feed it itself.
What behaviour results when I do this with Q?
When it reads its own source, just what will it do?
If P warns of loops, Q will print “Loop!” and quit;
yet P is supposed to speak truly of it.
So if Q’s going to quit, then P should say, “Fine!” –
which will make Q go back to its very first line!
No matter what P would have done, Q will scoop it:
Q uses P’s output to make P look stupid.
If P gets things right then it lies in its tooth;
and if it speaks falsely, it’s telling the truth!
I’ve created a paradox, neat as can be –
and simply by using your putative P.
When you assumed P you stepped into a snare;
Your assumptions have led you right into my lair.
So, how to escape from this logical mess?
I don’t have to tell you; I’m sure you can guess.
By reductio, there cannot possibly be
a procedure that acts like the mythical P.
You can never discover mechanical means
for predicting the acts of computing machines.
It’s something that cannot be done. So we users
must find our own bugs; our computers are losers!
Vitalik
https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/
"However, it does show that there is a fundamental barrier to what can be accomplished, and “fairness” is not something that can be mathematically proven in a theorem"
well yes it can:
If you hold a system will function in a particular way and it does then that is fair, and you can mathematically prove it
https://www.reddit.com/r/ethereum/comments/4opjov/the_bug_which_the_dao_hacker_exploited_was_not/
TL;DR - Complexity and "Turing completeness" are not the real culprit here...
https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/
"However, it does show that there is a fundamental barrier to what can be accomplished, and “fairness” is not something that can be mathematically proven in a theorem"
well yes it can:
If you hold a system will function in a particular way and it does then that is fair, and you can mathematically prove it
https://www.reddit.com/r/ethereum/comments/4opjov/the_bug_which_the_dao_hacker_exploited_was_not/
TL;DR - Complexity and "Turing completeness" are not the real culprit here...
How many times am I going to have to repeat myself and link to my explanation that the quoted Reddit above is INCORRECT!
https://bitcointalksearch.org/topic/m.15273470 <--- click & read please
Vitalik is correct. The Reddit post is not. Period.
Turning-complete programming on a block chain can't be guaranteed to be secure. There will always be a gap between "intent" and "execution".
The fundamental reason is tied into the Halting problem, in that one can't prove an absolute negative, e.g. prove that no dinosaurs are still alive any where in the universe. It is undecideable.
Fundamentally this is the Second Law of Thermodynamics and the fact that time is irreversible so entropy is unbounded. The only way that wouldn't be the case would be if the speed-of-light was not finite, but then the past and future would collapse into the same infinitesimal point of nothingness and nothing could exist.
Theorem provers such as Coq produce output that is not Turing-complete. Yet that isn't even relevant, because "intent" can't be absolutely quantified in code or specification because interpretation is relative, i.e. the only account of history which is 100% certain doesn't exist (people will disagree on what happened because no one was every where in real-time, i.e. the speed-of-light is finite).
If you can't grasp this, don't fret. It requires a high level of intellect and also understanding of several fields including computer science and physics.
The bottom line is that Turing-complete programming on a block chain is "a can of worms" which is what we all told Ethereum since back in 2013 when Vitalik first proposed it.
Another attack occurring?
https://www.reddit.com/r/ethtrader/comments/4ot3vi/warning_another_successful_attack_recursive_split/
https://www.reddit.com/r/ethtrader/comments/4ot3vi/warning_another_successful_attack_recursive_split/
Published on may 18th
http://vessenes.com/ethereum-contracts-are-going-to-be-candy-for-hackers/
Ethereum Contracts Are Going To Be Candy For Hackers
http://vessenes.com/ethereum-contracts-are-going-to-be-candy-for-hackers/
It isn't "tarnished forever" if the problem is confined to where it originated. That was the whole point of a "Turing Complete" scripting language - to isolate one contract from another and from the underlying platform itself as I've explained here and in previous posts in that thread.
I responded to your linked post as quoted above:
The very architecture of a smart contract blockchain makes the logic of the "Turing Complete" scripting language independent of the logic of the blockchain on which it runs. Kind of like the separation of executive a legislative powers in states. If you decide to p*ss all over that principle just to save yourself embarrassment and investors in a known risky asset from taking a haircut then you just kill it for everybody.
Incorrect! Turing-completeness is unbounded recursion. Thus it makes it impossible to encapsulate scripts from each other and from internal recursion, etc.. It is the opposite of your incorrect assumption!
You should stop spreading lies about computer science that you do not understand.
An interesting read from a guy reddit. He gave compelling arguments and it does make you think twice about the viability and security of the current smart contract plaforms and DAOs currently in circulation.
Source: The bug which the "DAO hacker" exploited was *not* "merely in the DAO itself" (ie, *separate* from Ethereum). The bug was in Ethereum's *language design* itself (Solidity / EVM - Ethereum Virtual Machine) - shown by the "recursive call bug discovery" divulged (and dismissed) on slock.it last week.
Here's an excerpt of the post.
Source: The bug which the "DAO hacker" exploited was *not* "merely in the DAO itself" (ie, *separate* from Ethereum). The bug was in Ethereum's *language design* itself (Solidity / EVM - Ethereum Virtual Machine) - shown by the "recursive call bug discovery" divulged (and dismissed) on slock.it last week.
Here's an excerpt of the post.
Quote
Complexity and "Turing completeness" are not the real culprit here - those are all good things that we can have someday. The real culprit is poor language design. Specifically, I would recommend using "functional" (rather than "procedural") languages for mission-critical code which will be driving "smart contracts" - and even better if a high-level "specification" language could be used, allowing formal derivation of a (verifiably correct) program in a low-level "implementation" language (ie, providing mathematical proof that the implementation satisfies the specification - and mitigating the problem where the high-level human-readable "description" is different from the low-level machine-runnable "code"). I suspect many people (raised in a world where JavaScript is the "assembly language of the web") might not know about some of the history and possibly related work. So take this as a stern lecture telling you to take a good look at the history of functional languages (and specification vs implementation languages) as used in mission-critical projects, including finance - which, even when using such tools, are still very hard to get right - as we can see from the decades-long history of failures of major projects in defense, healthcare, aerospace, etc.
I don't think language design can fix "reentrancy-safety". The problem is Turing-completeness which is unbounded recursion. That is not something you can entirely solve with the language design.
If your smart block chain project doesn't know how to explain what I am talking about here, then you should not be investing because they probably don't really know what they are doing. They think they can just slap on a programming language to a block chain. Sorry! The problem is fundamentally insoluble and any breakthrough will have to be a paradigm-shift!
All these Block Chain Alt devs are recreating the mistakes that mathematicians and software engineers have discovered years ago.
And that we all told them back in late 2013 not to do it. I personally told Charles. Vitalik invented "gas" and thought that was sufficient.
Quoting myself from 2011:
Fundamentally, Turing-completeness is one concise requirement, unbounded recursion.
I had already explained why that Reddit post is incorrect:
Just turing complete...
https://www.reddit.com/r/btc/comments/4op2es/the_bug_which_the_dao_hacker_exploited_was_not/
https://www.reddit.com/r/btc/comments/4op2es/the_bug_which_the_dao_hacker_exploited_was_not/
I haven't studied the specific vulnerability in this case[1], but I think it has to do with the contract code doing mutability aliasing on global state. So this is an issue of synchronizing mutability aliasing.
For example, imagine if some intended to be atomic operation[1] of a check for sending of ETH out of the contract had not set a global count of sent before some recursion which enabled sending more ETH out, thus exceeding the threshold.
So the Reddit post seems to be somewhat clueless about the actual issue. Functional programming and static typing is orthogonal to the issue of dealing with global state and mutability aliasing. I had just finished analyzing this issue at the Rust-lang forum and in my private discussion with keane recently. Although Rust can statically check mutability aliasing, this is restricted to disjoint data structures. We concluded that some semantics can't be modelled with a static checker. Mutability aliasing is thorny issue and I am not familiar enough with Coq to know if it can model it. I would need to really dig into the details of this and study it before I can comment with high degree of confidence.
Jump to: