I just cant believe people are dumb enough to invest in a platform that can run untrusted code.
The nr.1. priority for money is to be safe, but when millions of hackers will try to figure out how to hack the ethereum network because of it's vulnerability, and if they succeed, then these smartass investors will realize what was coming for them.
Bitcoin is simple (and even complex to my standard) but it is necessary to become a world reserve currency. Ethereum at this point is too bloated, and risky to start any serious project on it.
C`mon guys even the ETH blockchain is growing rapidly, sooner or later only a handful of datacenters will be able to store it, and at that point what would be a difference between a blockchain and a centralized database?
Topic: ETH = Game Over - page 8. (Read 40467 times)
You kind of lose me a bit when it comes to differentiating what is possible with turing complete code as compared with non-turning complete code, but I think I kind of get your point.
It is extremely important and the core of my ethereum critique, which, I admit, only realized myself after the DAO failure ; before, I was a relative ethereum enthusiast, and was only criticising the transparency of the block chain.
To some extent, I rely upon assessments like yours to assist in supporting my conclusions that there are some critical things wrong with Ethereum and/or its implementation, even though I have my own separate additional reasons for skepticism, which I believe that I have already described in various ways.
Actually, "code" is not Turing complete, but "instruction set" is. "code" is a list of instructions out of an instruction set.
Now, there is a fundamental theorem in computer science that says that, given an arbitrary list of instructions (of code) in a Turing-complete language, it is *fundamentally impossible* to find out whether the execution of that list will come to an end or not. It is called the Halting problem. I give you some arbitrary code, and by looking at the code, or by doing whatever you want with the code, there's NO UNIVERSAL decision procedure that will tell you whether the execution of that code will come to a halt or not.
But that doesn't mean that for *specific* pieces of code, one cannot find ways to demonstrate that it will always come to a halt. Of course there are pieces of code, for which one can find proofs that they will stop. But the METHOD for that proof cannot be universal.
An example is the code that implements the Mandelbrot set. I don't know if you know the Mandelbrot set. It is mathematically defined as that piece of the complex plane such that an element of that set, C, is such, that the series defined by the iteration formula:
z(n+1) = z(n)^2 + C and z(0) = 0, does not diverge.
A property is that the series diverges for sure once abs(z) is larger than 2.
If you want to find out whether a particular complex number C is part of the Mandelbrot set or not, you do the following:
put z = 0.
while ( abs(z) < 2 ) do
{
z := z^2 + c
}
If this piece of code stops, then, for the given value of C, C does NOT belong to the Mandelbrot set. If the code doesn't stop, then C belongs to the Mandelbrot set, but we will never find out !
The trick is that, apart from running the code for hours, days, years, centuries, there's NO WAY to find out if the code is going to stop or not. And it is only a few lines !
We know mathematical properties of the Mandelbrot set, and because of those properties, we CAN conclude that certain values of C will be such that the code will never stop ; we can also conclude that for certain other values of C, the code WILL stop, and for others, when we enter the "hairy" part, we simply can't say in advance.
In order to have an approximation to the Mandelbrot set, we apply a "gas limit". We say that if the code ran for more than, say, an hour, it will "most probably not diverge". But this is in fact making some errors. There are points on the Mandelbrot set that diverge *arbitrary late*. Some will run for an hour before crossing the abs(z) < 2 limit. Others, a day. And some points, a million years.
So essentially, the Mandelbrot set is NOT CALCULABLE.
If we were to have a universal solution to the Halting problem (which can be mathematically demonstrated not to exist), then this solution would give us directly the answer to the Mandelbrot set. We put in the value of C under scrutiny, and apply the universal test to decide whether the program stops or not.
This demonstrates that even very small programs, well written, in Turing complete languages cannot be demonstrated to stop or not. If a program doesn't stop, it has an "infinite state tree". You cannot analyse all outcomes. It can generate an infinite amount of pseudo-entropy. SO YOU CANNOT VERIFY EVERY CASE IT WILL BE IN, because it is a potentially infinite list.
But of course, another program:
set n = 0;
while (n < 100) do
{
n := n^2 + 1;
}
with natural numbers, this time, will provably stop. So for SOME programs, you can prove that they stop, and analyse their state tree.
However, the problem with smart contracts is that the contract is given, and hence to be considered as an "arbitrary piece of code". You can hence not hope to ever develop a tool that will analyse any given existing contract and tell you exactly in what different states it will come out ; what the different possible outcomes are. For some, you can do so, but not for any given one.
Imagine I put some Mandelbrot-like calculation in a contract, applied to a piece of address. Whether an address will pass or not will depend on that address, and the gas limit applied.
With non-Turing complete instruction sets, these problems don't appear, and it IS possible to have full state tree mappings automatically from a random piece of code.
As it is essential, in a contract, to "understand all possible cases", it must hence be possible to LIST all possible cases given an arbitrary contract. And this is only possible if the instruction set is non-Turing complete.
So it is a very, very bad idea to have a Turing complete instruction set (byte code) to write smart contracts.
Now, there is a fundamental theorem in computer science that says that, given an arbitrary list of instructions (of code) in a Turing-complete language, it is *fundamentally impossible* to find out whether the execution of that list will come to an end or not. It is called the Halting problem. I give you some arbitrary code, and by looking at the code, or by doing whatever you want with the code, there's NO UNIVERSAL decision procedure that will tell you whether the execution of that code will come to a halt or not.
But that doesn't mean that for *specific* pieces of code, one cannot find ways to demonstrate that it will always come to a halt. Of course there are pieces of code, for which one can find proofs that they will stop. But the METHOD for that proof cannot be universal.
An example is the code that implements the Mandelbrot set. I don't know if you know the Mandelbrot set. It is mathematically defined as that piece of the complex plane such that an element of that set, C, is such, that the series defined by the iteration formula:
z(n+1) = z(n)^2 + C and z(0) = 0, does not diverge.
A property is that the series diverges for sure once abs(z) is larger than 2.
If you want to find out whether a particular complex number C is part of the Mandelbrot set or not, you do the following:
put z = 0.
while ( abs(z) < 2 ) do
{
z := z^2 + c
}
If this piece of code stops, then, for the given value of C, C does NOT belong to the Mandelbrot set. If the code doesn't stop, then C belongs to the Mandelbrot set, but we will never find out !
The trick is that, apart from running the code for hours, days, years, centuries, there's NO WAY to find out if the code is going to stop or not. And it is only a few lines !
We know mathematical properties of the Mandelbrot set, and because of those properties, we CAN conclude that certain values of C will be such that the code will never stop ; we can also conclude that for certain other values of C, the code WILL stop, and for others, when we enter the "hairy" part, we simply can't say in advance.
In order to have an approximation to the Mandelbrot set, we apply a "gas limit". We say that if the code ran for more than, say, an hour, it will "most probably not diverge". But this is in fact making some errors. There are points on the Mandelbrot set that diverge *arbitrary late*. Some will run for an hour before crossing the abs(z) < 2 limit. Others, a day. And some points, a million years.
So essentially, the Mandelbrot set is NOT CALCULABLE.
If we were to have a universal solution to the Halting problem (which can be mathematically demonstrated not to exist), then this solution would give us directly the answer to the Mandelbrot set. We put in the value of C under scrutiny, and apply the universal test to decide whether the program stops or not.
This demonstrates that even very small programs, well written, in Turing complete languages cannot be demonstrated to stop or not. If a program doesn't stop, it has an "infinite state tree". You cannot analyse all outcomes. It can generate an infinite amount of pseudo-entropy. SO YOU CANNOT VERIFY EVERY CASE IT WILL BE IN, because it is a potentially infinite list.
But of course, another program:
set n = 0;
while (n < 100) do
{
n := n^2 + 1;
}
with natural numbers, this time, will provably stop. So for SOME programs, you can prove that they stop, and analyse their state tree.
However, the problem with smart contracts is that the contract is given, and hence to be considered as an "arbitrary piece of code". You can hence not hope to ever develop a tool that will analyse any given existing contract and tell you exactly in what different states it will come out ; what the different possible outcomes are. For some, you can do so, but not for any given one.
Imagine I put some Mandelbrot-like calculation in a contract, applied to a piece of address. Whether an address will pass or not will depend on that address, and the gas limit applied.
With non-Turing complete instruction sets, these problems don't appear, and it IS possible to have full state tree mappings automatically from a random piece of code.
As it is essential, in a contract, to "understand all possible cases", it must hence be possible to LIST all possible cases given an arbitrary contract. And this is only possible if the instruction set is non-Turing complete.
So it is a very, very bad idea to have a Turing complete instruction set (byte code) to write smart contracts.
Even though I do not understand all of the specific points that you are making in reference to code, it remains good to point out these kinds of points for other people and also, I appreciate that you are sharing your perspective of the matter in such specific detailed justification.
There is a big conference about the Etheruem. So I think the Ethereum will last a bit longer.
This could be part of the reason for various recent ETH pumping articles.
I kind of question whether there is any merit to give any recognition to recent articles that more or less describe the impending doom of ETC and the considerable upside potential of ETH.
Even though I do not really believe in either coins, my assessment tends towards the opposite of the assessments and conclusions of the articles pumping ETH and denigrating ETC, at least in terms that ETC seems to be a better value because in the longer run, the two are likely going to approach parity in pricing... yet how long will it take for such parity to occur is beyond any kind of insight that I have.
ETH pump article 1)
https://cointelegraph.com/news/ethereum-eth-and-etc-price-trends-week-of-september-19th
ETH pump article 2)
http://www.newsbtc.com/2016/09/20/ethereum-classic-price-technical-analysis-etc-breaks/
You kind of lose me a bit when it comes to differentiating what is possible with turing complete code as compared with non-turning complete code, but I think I kind of get your point.
It is extremely important and the core of my ethereum critique, which, I admit, only realized myself after the DAO failure ; before, I was a relative ethereum enthusiast, and was only criticising the transparency of the block chain.
Actually, "code" is not Turing complete, but "instruction set" is. "code" is a list of instructions out of an instruction set.
Now, there is a fundamental theorem in computer science that says that, given an arbitrary list of instructions (of code) in a Turing-complete language, it is *fundamentally impossible* to find out whether the execution of that list will come to an end or not. It is called the Halting problem. I give you some arbitrary code, and by looking at the code, or by doing whatever you want with the code, there's NO UNIVERSAL decision procedure that will tell you whether the execution of that code will come to a halt or not.
But that doesn't mean that for *specific* pieces of code, one cannot find ways to demonstrate that it will always come to a halt. Of course there are pieces of code, for which one can find proofs that they will stop. But the METHOD for that proof cannot be universal.
An example is the code that implements the Mandelbrot set. I don't know if you know the Mandelbrot set. It is mathematically defined as that piece of the complex plane such that an element of that set, C, is such, that the series defined by the iteration formula:
z(n+1) = z(n)^2 + C and z(0) = 0, does not diverge.
A property is that the series diverges for sure once abs(z) is larger than 2.
If you want to find out whether a particular complex number C is part of the Mandelbrot set or not, you do the following:
put z = 0.
while ( abs(z) < 2 ) do
{
z := z^2 + c
}
If this piece of code stops, then, for the given value of C, C does NOT belong to the Mandelbrot set. If the code doesn't stop, then C belongs to the Mandelbrot set, but we will never find out !
The trick is that, apart from running the code for hours, days, years, centuries, there's NO WAY to find out if the code is going to stop or not. And it is only a few lines !
We know mathematical properties of the Mandelbrot set, and because of those properties, we CAN conclude that certain values of C will be such that the code will never stop ; we can also conclude that for certain other values of C, the code WILL stop, and for others, when we enter the "hairy" part, we simply can't say in advance.
In order to have an approximation to the Mandelbrot set, we apply a "gas limit". We say that if the code ran for more than, say, an hour, it will "most probably not diverge". But this is in fact making some errors. There are points on the Mandelbrot set that diverge *arbitrary late*. Some will run for an hour before crossing the abs(z) < 2 limit. Others, a day. And some points, a million years.
So essentially, the Mandelbrot set is NOT CALCULABLE.
If we were to have a universal solution to the Halting problem (which can be mathematically demonstrated not to exist), then this solution would give us directly the answer to the Mandelbrot set. We put in the value of C under scrutiny, and apply the universal test to decide whether the program stops or not.
This demonstrates that even very small programs, well written, in Turing complete languages cannot be demonstrated to stop or not. If a program doesn't stop, it has an "infinite state tree". You cannot analyse all outcomes. It can generate an infinite amount of pseudo-entropy. SO YOU CANNOT VERIFY EVERY CASE IT WILL BE IN, because it is a potentially infinite list.
But of course, another program:
set n = 0;
while (n < 100) do
{
n := n^2 + 1;
}
with natural numbers, this time, will provably stop. So for SOME programs, you can prove that they stop, and analyse their state tree.
However, the problem with smart contracts is that the contract is given, and hence to be considered as an "arbitrary piece of code". You can hence not hope to ever develop a tool that will analyse any given existing contract and tell you exactly in what different states it will come out ; what the different possible outcomes are. For some, you can do so, but not for any given one.
Imagine I put some Mandelbrot-like calculation in a contract, applied to a piece of address. Whether an address will pass or not will depend on that address, and the gas limit applied.
With non-Turing complete instruction sets, these problems don't appear, and it IS possible to have full state tree mappings automatically from a random piece of code.
As it is essential, in a contract, to "understand all possible cases", it must hence be possible to LIST all possible cases given an arbitrary contract. And this is only possible if the instruction set is non-Turing complete.
So it is a very, very bad idea to have a Turing complete instruction set (byte code) to write smart contracts.
Surely it's game over, they're close to fixing the biggest issue in blockchain technology, scaling ( no project was ever close of fixing scaling ), they got over 50 promising projects soon to be deployed on the network, and this one would be the latest news: http://www.coindesk.com/santander-vies-become-first-bank-issue-digital-cash-blockchain/ . So yeah, listen to the fud trolls and die poor.
There is a big conference about the Etheruem. So I think the Ethereum will last a bit longer.
Ethereum Community Buzzing after Opening Day at Devcon2
Those who made the trip to Shanghai for Devcon2, were treated to an action-filled day of forward-thinking presentations from leaders all over the world in Ethereum and blockchain technology. This is the Opening Day recap.
Those who made the trip to Shanghai for Devcon2, were treated to an action-filled day of forward-thinking presentations from leaders all over the world in Ethereum and blockchain technology.
Ethereum already leads the blockchain space. In terms of transaction speed, energy efficiency, ease of use, the availability of user and developer tools, a great leadership team, thriving community, and real-world applicability and legal and regulatory foresight, Ethereum has maintained its innovative structure. It’s certainly distanced itself from other blockchains which have (assumed) dominance in the crypto space and are often associated with specific evasive use-cases that Ethereum wants to step away from. But Ethereum is not just about fast, efficient, scalable and near zero-cost value transfer. Ethereum’s major distinguishing feature is its virtual machine (the EVM) which enables blockchain programmability or “smart contracts”. That’s where the main utility and value of Ethereum technology will come from in the future. As we look forward, we realize we are moving beyond the traditional blockchain technology which has led us here and served us so well. All of this innovation is made even more apparent at this year’s second annual Devcon2 event.
The opening day of Devcon2 was awe inspiring. The highlight for me was Vitalik’s “Mauve Revolution” overview of Casper and the relentless progress of Ethereum moving from proof-of-work to proof-of-stake. Vitalik’s “Mauve Revolution" presentation showed that the limitations previously associated with Ethereum technology have been addressed: privacy (particularly at the base protocol layer), scalability (moving from dozens of tx/sec to millions), cost (it currently costs ~$360,000 a day to run the network) and high transaction latency (currently 14 seconds).
Lightweight Clients
Vitalik didn’t just talk about the roadmap and future of Ethereum over the coming months and years. He also spoke very highly of the recent work done by Ethcore and Parity. Parity is a “lightweight” Ethereum client which, as Vitalik explained (to those who didn’t know already), takes advantage of Merkle Tree hashing which allows for efficiently verifiable proofs that a transaction was included in a block without requiring high-performance hardware.
The availability of a fast and efficient lightweight client has opened up a wide range of possibilities for wearable devices, and low power, single board computers, and (most importantly) IoT devices. The Internet of Things is a market sector that’s growing rapidly. Bob Summerwill, Vancouver-based Ethereum Foundation developer wowed the audience with a photograph of his very cool desk which featured his own Java ring (Google it), Raspberry Pi, oDroid, C64 and Atari. He even managed to get Ethereum running on a Raspberry Pi Model A board!
Porting of EVM to Wasm
Other notable developments from the opening day at Devcon2 was the work done in transpiling EVM code to the W3C’s web assembly. This is a huge contribution to the community and will pay dividends over the coming months and years. These benefits will unfold as the major Javascript engines from Microsoft Edge, Chrome, Firefox, node.js, etc. enable web assembly protocols in their stable releases.
Ethereum is at the cutting edge of next-generation web and it was made clear while listening to Martin Becze and Alex Beregszaszi when they presented their panel, “Ethereum <3 WebAssembly.” (EVM2wasm is available at https://github.com/ewasm/evm2wasm.)
There were so many other exemplary presentations. One from Dr. Philip Daian of Cornell University (project page: initc3.org) who works on smart contract research, presented "Writing Secure and Correct Smart Contracts". He made a number of very important points to the community on formal verification/specification of Ethereum code, the role of escape hatch/kill switch functionality in real-world mission-critical systems, and bug bounty schemes to incentivize defenders and remove financial incentives from attackers. Heiko Hees’s presentation of the Raiden network applied to Ethereum was also very well received. Ethereum now meets and exceeds similar networks running on rival blockchains. Raiden for Ethereum currently works and will be available to the public very soon.
Socializing was in full swing after the event, with numerous people networking at the rooftop Vue Bar. The networking opportunities at Devcon2 are one of the reasons developers, corporations, banks, government agencies, legal experts, academics, etc. come to this event. This is the place to be if you want a high concentration of Ethereum domain experts who all share big hopes and dreams for the future. Tomorrow night, the official Devcon2 party takes place at Upmarket Bar Rouge by the Bund where there are many more opportunities for Ethereum leaders to have fun and unwind from the buzz of the conference venue.
Ethereum Community Buzzing after Opening Day at Devcon2
Those who made the trip to Shanghai for Devcon2, were treated to an action-filled day of forward-thinking presentations from leaders all over the world in Ethereum and blockchain technology. This is the Opening Day recap.
Those who made the trip to Shanghai for Devcon2, were treated to an action-filled day of forward-thinking presentations from leaders all over the world in Ethereum and blockchain technology.
Ethereum already leads the blockchain space. In terms of transaction speed, energy efficiency, ease of use, the availability of user and developer tools, a great leadership team, thriving community, and real-world applicability and legal and regulatory foresight, Ethereum has maintained its innovative structure. It’s certainly distanced itself from other blockchains which have (assumed) dominance in the crypto space and are often associated with specific evasive use-cases that Ethereum wants to step away from. But Ethereum is not just about fast, efficient, scalable and near zero-cost value transfer. Ethereum’s major distinguishing feature is its virtual machine (the EVM) which enables blockchain programmability or “smart contracts”. That’s where the main utility and value of Ethereum technology will come from in the future. As we look forward, we realize we are moving beyond the traditional blockchain technology which has led us here and served us so well. All of this innovation is made even more apparent at this year’s second annual Devcon2 event.
The opening day of Devcon2 was awe inspiring. The highlight for me was Vitalik’s “Mauve Revolution” overview of Casper and the relentless progress of Ethereum moving from proof-of-work to proof-of-stake. Vitalik’s “Mauve Revolution" presentation showed that the limitations previously associated with Ethereum technology have been addressed: privacy (particularly at the base protocol layer), scalability (moving from dozens of tx/sec to millions), cost (it currently costs ~$360,000 a day to run the network) and high transaction latency (currently 14 seconds).
Lightweight Clients
Vitalik didn’t just talk about the roadmap and future of Ethereum over the coming months and years. He also spoke very highly of the recent work done by Ethcore and Parity. Parity is a “lightweight” Ethereum client which, as Vitalik explained (to those who didn’t know already), takes advantage of Merkle Tree hashing which allows for efficiently verifiable proofs that a transaction was included in a block without requiring high-performance hardware.
The availability of a fast and efficient lightweight client has opened up a wide range of possibilities for wearable devices, and low power, single board computers, and (most importantly) IoT devices. The Internet of Things is a market sector that’s growing rapidly. Bob Summerwill, Vancouver-based Ethereum Foundation developer wowed the audience with a photograph of his very cool desk which featured his own Java ring (Google it), Raspberry Pi, oDroid, C64 and Atari. He even managed to get Ethereum running on a Raspberry Pi Model A board!
Porting of EVM to Wasm
Other notable developments from the opening day at Devcon2 was the work done in transpiling EVM code to the W3C’s web assembly. This is a huge contribution to the community and will pay dividends over the coming months and years. These benefits will unfold as the major Javascript engines from Microsoft Edge, Chrome, Firefox, node.js, etc. enable web assembly protocols in their stable releases.
Ethereum is at the cutting edge of next-generation web and it was made clear while listening to Martin Becze and Alex Beregszaszi when they presented their panel, “Ethereum <3 WebAssembly.” (EVM2wasm is available at https://github.com/ewasm/evm2wasm.)
There were so many other exemplary presentations. One from Dr. Philip Daian of Cornell University (project page: initc3.org) who works on smart contract research, presented "Writing Secure and Correct Smart Contracts". He made a number of very important points to the community on formal verification/specification of Ethereum code, the role of escape hatch/kill switch functionality in real-world mission-critical systems, and bug bounty schemes to incentivize defenders and remove financial incentives from attackers. Heiko Hees’s presentation of the Raiden network applied to Ethereum was also very well received. Ethereum now meets and exceeds similar networks running on rival blockchains. Raiden for Ethereum currently works and will be available to the public very soon.
Socializing was in full swing after the event, with numerous people networking at the rooftop Vue Bar. The networking opportunities at Devcon2 are one of the reasons developers, corporations, banks, government agencies, legal experts, academics, etc. come to this event. This is the place to be if you want a high concentration of Ethereum domain experts who all share big hopes and dreams for the future. Tomorrow night, the official Devcon2 party takes place at Upmarket Bar Rouge by the Bund where there are many more opportunities for Ethereum leaders to have fun and unwind from the buzz of the conference venue.
...
Oops, I added a lot to my previous post, sorry about that. The editing took too much time and you replied in the mean time.
hahahahaha
I'm too quick, and yeah, such a thing happens. The topic is not exactly simple, and many of us, including yours truly, are attempting to wrap our minds around various aspects of this area, our opinions about it, and maybe even changing our opinions from time to time...
TL;DR
There is a difference between an application that is supposed to automate a paper contract with intend as we know it, and a smart contract which is a totally new beast, of which intend is to be derived from code, and not the other way around, as we are used to in software.
There is a difference between an application that is supposed to automate a paper contract with intend as we know it, and a smart contract which is a totally new beast, of which intend is to be derived from code, and not the other way around, as we are used to in software.
I don't think that this is going to stop courts from attempting to make actual people responsible, even if there would likely exist a kind of inability for actual people to change the smart contract once it goes into effect.
As such, this derivation must be *provable* and automatic (the derivation of intend from code). And this is mathematically impossible with code written in a Turing-complete language, but is perfectly doable when the code is written in a language which is not Turing complete. The bitcoin byte code is perfectly analysable and it must be possible to build tools that analyse the full state tree of any bitcoin script. From that state tree, intend follows.
You can perfectly analyse any multisig script, and there will be no surprises.
You can perfectly analyse any multisig script, and there will be no surprises.
You kind of lose me a bit when it comes to differentiating what is possible with turing complete code as compared with non-turning complete code, but I think I kind of get your point.
We've never done such a thing before and that's why smart contracts are strange beasts, and we keep ignoring their nature, by referring to things like "intend", "law", "thieves and frauds".
I guess that is why I am saying that courts are going to attempt to analyse and to apply principles within accepted norms - and yeah there will likely be some growing pains in this transition and maybe even some realization that the old rules may not be able to be applied. However, in the Ethereum (dao context), when individuals come up to the plate and they intervene, they are showing the court that there are intervention possibilities and even folks that could either be held responsible or forced to undo the undoable.
You could compare a smart contract as a "law of nature" and a normal contract as "a rule of a game". Quantum mechanics aside, when playing soccer, it is not possible to shoot the ball in the two goals of the two parties at the same time. So nobody can "cheat" on that rule. On the other hand, it is not allowed to carry the ball with your hands, but you can physically do so: if you do, you're a cheater. You might erroneously *think* that the laws of nature forbid you to shoot from the corner position directly into the goal because no straight line can do so. But you can use a spin on the ball, which makes it follow a curved trajectory and enters the goal all right. If you do so, you are not a cheater, simply because someone thought that the laws of nature (the smart contract) was different.
These are decent illustrative examples.. Thanks.
TL;DR
There is a difference between an application that is supposed to automate a paper contract with intend as we know it, and a smart contract which is a totally new beast, of which intend is to be derived from code, and not the other way around, as we are used to in software.
As such, this derivation must be *provable* and automatic (the derivation of intend from code). And this is mathematically impossible with code written in a Turing-complete language, but is perfectly doable when the code is written in a language which is not Turing complete. The bitcoin byte code is perfectly analysable and it must be possible to build tools that analyse the full state tree of any bitcoin script. From that state tree, intend follows.
You can perfectly analyse any multisig script, and there will be no surprises.
We've never done such a thing before and that's why smart contracts are strange beasts, and we keep ignoring their nature, by referring to things like "intend", "law", "thieves and frauds".
You could compare a smart contract as a "law of nature" and a normal contract as "a rule of a game". Quantum mechanics aside, when playing soccer, it is not possible to shoot the ball in the two goals of the two parties at the same time. So nobody can "cheat" on that rule. On the other hand, it is not allowed to carry the ball with your hands, but you can physically do so: if you do, you're a cheater. You might erroneously *think* that the laws of nature forbid you to shoot from the corner position directly into the goal because no straight line can do so. But you can use a spin on the ball, which makes it follow a curved trajectory and enters the goal all right. If you do so, you are not a cheater, simply because someone thought that the laws of nature (the smart contract) was different.
There is a difference between an application that is supposed to automate a paper contract with intend as we know it, and a smart contract which is a totally new beast, of which intend is to be derived from code, and not the other way around, as we are used to in software.
As such, this derivation must be *provable* and automatic (the derivation of intend from code). And this is mathematically impossible with code written in a Turing-complete language, but is perfectly doable when the code is written in a language which is not Turing complete. The bitcoin byte code is perfectly analysable and it must be possible to build tools that analyse the full state tree of any bitcoin script. From that state tree, intend follows.
You can perfectly analyse any multisig script, and there will be no surprises.
We've never done such a thing before and that's why smart contracts are strange beasts, and we keep ignoring their nature, by referring to things like "intend", "law", "thieves and frauds".
You could compare a smart contract as a "law of nature" and a normal contract as "a rule of a game". Quantum mechanics aside, when playing soccer, it is not possible to shoot the ball in the two goals of the two parties at the same time. So nobody can "cheat" on that rule. On the other hand, it is not allowed to carry the ball with your hands, but you can physically do so: if you do, you're a cheater. You might erroneously *think* that the laws of nature forbid you to shoot from the corner position directly into the goal because no straight line can do so. But you can use a spin on the ball, which makes it follow a curved trajectory and enters the goal all right. If you do so, you are not a cheater, simply because someone thought that the laws of nature (the smart contract) was different.
...
Oops, I added a lot to my previous post, sorry about that. The editing took too much time and you replied in the mean time.
I agree with a lot of dinofelis's responses to this, yet I would also add that there are concepts of unjust enrichment, fraud, etc... in common law.
Even if technically and specifically, the DAO hacker was following the technical language of the contract, in the law there are potential remedies for these kinds of unintended and unexpected contracts that could cause the DAO attacker not to profit from the technical loophole that he found. On the other hand, such DAO attacker and loopholes and technical flaws in the contract does not, in my opinion, justify a hardfork of ETH.. that is a bit of a different story and attempting to take the law into your own hands and at the same time denigrate any potential value that may have existed with the ETH ecosystem prior to the hardfork.
Well, this is, again, because the Slock-it people were selling *intend*. If the Slock-it people had only published the byte code, then what the DAO hacker did, was not "exploiting a loophole", because for certain byte code states to call loop holes/exploits/..., you have to have another model of behaviour that doesn't include these states.
That's my whole point. There are two ways to look upon software that "automatically" arbiters contracts: one is "the implementation of intend, as specified in human-readable terms" ; the other is "the code itself". Only the last way is a smart contract - especially one running on a block chain and "unstoppable".
It seems that many people confuse both. The first kind of thing could be, say, an application ran by an insurance company, that automatically treats common incidents, and pays people accordingly. This application is supposed to implement the INTEND of the PAPER CONTRACT. It can very well contain bugs ; people could find exploits in it, and have them paid much more by the company than they are entitled to. This is a "loophole", "bug", "exploit" because the software was SUPPOSED TO IMPLEMENT INTEND (in the written contract). As such, people exploiting that are indeed, thieves, and corrective action is perfectly normal: it was NOT the application that was the *final arbiter* but the paper contract ; the application only had to implement that intend, and failed (contained bugs and exploits). People profiting from that are dishonest thieves.
But a smart contract is NOT that ; and the Slock-it people (and many others btw) are keeping up this confusion by PROVIDING EXPLANATION OF INTEND. They shouldn't, because this confuses people, making them think that they sign up, like with a paper contract, to this intend. When the software behaves differently than the announced intend, they cry fool, and they behave as if the smart contract were the application containing bugs, because not implementing intend.
THAT IS NOT WHAT A SMART CONTRACT IS ABOUT. That is simply software automating a paper contract.
Dinofelis. I don't really disagree with the overall conclusion regarding what you are asserting, yet probably my point is bit of a different way of coming at a similar conclusion as you (especially regarding the fact that there should not have been an intervention), but I have different reasons for my conclusion, at least at the moment.
I don't claim to be any kind of legal expert, and possibly, I don't understand this area of the law well enough in order to really attempt to get caught up on legal mumbo jumbo. Nonetheless, I am of the opinion that there is not a lot of legal precedence in regards to smart contracts and whether such smart contracts can really be implemented to involve and affect a considerable number of people, whether those people are investors, beneficiaries or otherwise affected by the carrying out of the terms of these kinds of smart contracts.
So far, when we are talking about the hardfork and the various ramifications of such hardfork, that is not a case that is in front of any court, and when we are talking about the dao hacker potentially stealing money, that case is not in front of any court either and whether we are talking about whether the dao hacker was screwed by ethereum carrying out the hardfork to disallow him from gaining the value of the dao hack, that case is not in front of any court, either. Anyhow, I am trying to suggest that if these kinds of cases were to go in front of courts, I am of the belief that a large number of courts are not going to get caught up in turing complete contracts and to concede that the contract controls everything when in fact people are affected in various kinds of ways. Whether these kinds of courts make sense or not, they are going to rule in terms of people, intentions, equity and common law principles.
There may be some instance sin which any court ruling has little to no effect, because no one could change the outcome, which could arguably be the case with a situation such as bitcoin in which the transactions on the blockchain are immutable, but in the case of Ethereum, there has already been demonstrations of mutability, which could embolden courts on a higher level to order the carrying out of hardforks (once it is shown to be capable of being done by persons in control). Bitcoin, on the other hand, could possibly say "fuck you" to the court.. because no one can change the history (nor is anyone willing to attempt to do such).
So, yeah, I agree with you about the various principles about smart contracts being turing complete and untouchable, but I really doubt that turing completeness works in situations that there is not the existence of a proof of work system such as bitcoin that allows for decentralized and secure immutability. On the other hand, this is likely an evolving area of the law, and it is going to continue to be interesting how courts attempt to approach these matters, especially in circumstances in which there may be true decentralization - and whether heads could roll, even though those heads are not able to execute whatever the court, in such circumstances, is ordering them to execute.
I agree with a lot of dinofelis's responses to this, yet I would also add that there are concepts of unjust enrichment, fraud, etc... in common law.
Even if technically and specifically, the DAO hacker was following the technical language of the contract, in the law there are potential remedies for these kinds of unintended and unexpected contracts that could cause the DAO attacker not to profit from the technical loophole that he found. On the other hand, such DAO attacker and loopholes and technical flaws in the contract does not, in my opinion, justify a hardfork of ETH.. that is a bit of a different story and attempting to take the law into your own hands and at the same time denigrate any potential value that may have existed with the ETH ecosystem prior to the hardfork.
Well, this is, again, because the Slock-it people were selling *intend*. If the Slock-it people had only published the byte code, then what the DAO hacker did, was not "exploiting a loophole", because for certain byte code states to call loop holes/exploits/..., you have to have another model of behaviour that doesn't include these states.
That's my whole point. There are two ways to look upon software that "automatically" arbiters contracts: one is "the implementation of intend, as specified in human-readable terms" ; the other is "the code itself". Only the last way is a smart contract - especially one running on a block chain and "unstoppable".
It seems that many people confuse both. The first kind of thing could be, say, an application ran by an insurance company, that automatically treats common incidents, and pays people accordingly. This application is supposed to implement the INTEND of the PAPER CONTRACT. It can very well contain bugs ; people could find exploits in it, and have them paid much more by the company than they are entitled to. This is a "loophole", "bug", "exploit" because the software was SUPPOSED TO IMPLEMENT INTEND (in the written contract). As such, people exploiting that are indeed, thieves, and corrective action is perfectly normal: it was NOT the application that was the *final arbiter* but the paper contract ; the application only had to implement that intend, and failed (contained bugs and exploits). People profiting from that are dishonest thieves.
But a smart contract is NOT that ; and the Slock-it people (and many others btw) are keeping up this confusion by PROVIDING EXPLANATION OF INTEND. They shouldn't, because this confuses people, making them think that they sign up, like with a paper contract, to this intend. When the software behaves differently than the announced intend, they cry fool, and they behave as if the smart contract were the application containing bugs, because not implementing intend.
THAT IS NOT WHAT A SMART CONTRACT IS ABOUT. That is simply software automating a paper contract.
edit: continuation:
The big difference between "an application automating a contract" and "a smart contract" is that the first is not a contract: the contract is elsewhere, in paper, with intend. That kind of application can have bugs, exploits, loopholes, and if you use them, you are being dishonest, because you were supposed to adhere to the PAPER CONTRACT INTEND.
A smart contract, on the other hand, is a piece of code, and nothing else. By *analysing* that piece of code, one can try to deduce the intend. In as far as this analysis is *provably reliable* (in the same way as a bitcoin transaction is proved cryptographically), this analysis can be done by the proposer of the contract, and it is up to the signer of the contract to verify this reliability of the contract analysis from the code.
The big difference relies in the responsibility of the code execution. In the first case (a running application, implementing a paper contract), it is the - obviously centralized - issuer of the contract that is responsible, if he USES the application to do his accounting and arbitrage, to make sure that the application is running correctly, it is his responsibility to correct any errors the application can make, and in the end, he is liable for the damage the errors in his application can cause. After all, he had people engage in a PAPER CONTRACT, and he proposed this application to execute it. He cannot hide behind "the code was the contract", because he led people to believe that his explanation of intend was the contract, and he's hence responsible for every bug in the application and its consequences.
With the DAO, one has the impression that people were adhering to the contract intend as explained on the slock it website, and that they had some confidence that the actual ethereum contract running was implementing that contract. THIS IS HIGHLY MISLEADING. As such, the Slock it boys engaged their responsibility wrt. the DAO signees because everything was done to make them believe that the contract had a certain intend. (this is probably why they panicked and pushed for the fork): their use of a piece of byte code on a block chain to implement that intend was a very risky affair for them because in as much as this byte code was not going to run as intended (and that's what it did) they would have to explain how they crowd-funded explaining INTEND and then used this funny block chain application which implemented something else *and which they couldn't change afterwards*.
In the case of a genuine smart contract, the intend has to be *derived* from the code, and not the other way around. THAT IS VERY STRANGE, but the nature of a smart contract. That is what "code is law" means. Nothing is more scammy, than to *pretend* that the code is implementing an intend.
We've never seen such a thing before. Smart contracts are strange beasts. And the DAO scam/cover up has done great damage in covering up this aspect.
In common law, there are *forbidden contracts* because they are *misleading*. Unfair contracts are contracts of which the terms were obfuscated in some or other way to some of the parties. Contrary to what is often thought, contracts do not have to have a "balance between potential gains and losses" between parties ; otherwise, a donation would always be considered unfair. But a donation, covered up as a "fair deal" on the other hand, is a fraud. "you give me $10 000,-, and I say thank you" is a perfectly legal contract. "you give me $10 000,- against a unique painting of my hands you will probably be able to sell for $100 000,-" is a fraud if I just give you a piece of canvas with three blobs of blue paint on it. "you give me $10 000,- for a piece of canvas with 3 blobs of blue paint on it" is a fair contract.
So: "sign up to the DAO, which is meant to be a distributed venture capitalist entity" is a fraud (like the "painting you will probably sell for $100 000,-"). But "sign up to the DAO, here's the byte code" is a fair deal.
What the slock it boys did, was the scam "sign up to the DAO, which is meant to be a distributed venture capitalist entity - look at the fine print" and in the fine print, there was "the byte code can be found there".
But many smart contract proposers do exactly the same: they tell you what should be the intend of the smart contract. That's a scam. It is not the thing you sign up for, and which will actually determine what happens.
Eth is the most decentralized project out there.
This got to be a joke. Right?
Also, there was a reason why ETC was born into existence and was supported with a huge trading volume. Make no mistake, that ETH hardfork was bad.
I would like to insist on the fact that ONLY the byte code is the contract - which is why it is so important to be able to *deduce intend from byte code* and not the other way around - and this needs automatic analysis of the state tree of the byte code, and this needs a non-Turing-complete byte code language.
This is also why I consider the DAO hacker not a thief, and why I consider that the real scammers are the Slock it people (even though they may even have been scammers without realizing it). This is because the concept of *smart contract* is new, and the ETH fork has hindered people in helping them understand this new and strange beast.
This is also why I consider the DAO hacker not a thief, and why I consider that the real scammers are the Slock it people (even though they may even have been scammers without realizing it). This is because the concept of *smart contract* is new, and the ETH fork has hindered people in helping them understand this new and strange beast.
I think the intent of the contract is also important. The contract has to be fair to both parties. If the intent is not to lose the money obviously, then the bad code might not stand.
I agree with a lot of dinofelis's responses to this, yet I would also add that there are concepts of unjust enrichment, fraud, etc... in common law.
Even if technically and specifically, the DAO hacker was following the technical language of the contract, in the law there are potential remedies for these kinds of unintended and unexpected contracts that could cause the DAO attacker not to profit from the technical loophole that he found. On the other hand, such DAO attacker and loopholes and technical flaws in the contract does not, in my opinion, justify a hardfork of ETH.. that is a bit of a different story and attempting to take the law into your own hands and at the same time denigrate any potential value that may have existed with the ETH ecosystem prior to the hardfork.
JJG already explained things well, but I'm going to add a few things, so that maybe you start to understand.
You are delusional if you believe that mining1 has any intention of wanting to "start to understand." hahahahah
I do appreciate your efforts in your various explanation though. They are very good, detailed and they provide decent technical specifics and perspective - at least for the rest of us who have some intentions to actually attempt to "understand" better.
I think the intent of the contract is also important. The contract has to be fair to both parties. If the intent is not to lose the money obviously, then the bad code might not stand.
Then you need human judgement ; only a human can understand "intend". And then you consider that smart contracts (the contracts where software is the final arbiter) have no reason to exist.
Considering 'fair', no, a contract doesn't have to be 'fair'. A contract must be CLEAR, that is, the people signing up to a contract must understand perfectly what they are signing up to. There is no need for a contract to be fair, because the user is FREE to sign or not. Fairness is a concept when coercion is at work. If there is no coercion, fairness is a meaningless concept, because your freedom allows you 1) to propose just any deal 2) to accept just any deal 3) to refuse just any deal.
But the terms of the deal have to be clear. With a smart contract on ethereum, those terms are ONLY determined by the byte code. Up to you if you agree to those terms or not. If you agree to them, it is your responsibility to understand them *OR* to bet on the trust you can have in someone explaining you what they are (according to them).
If I propose to you a contract where we put money in a pot, and then we draw a winner, who will take all the money, and in the fine print it is stated that I'm entitled to decide how the drawing is done, if you sign up, you shouldn't complain that I can now draw each time my own name as a winner. It was in the contract. If you didn't "read the fine print" then that's your problem.
But in order to avoid all this simple scamming, it should be possible to analyse a contract on all its outcomes. Once that is possible, this kind of easy scamming is not possible any more, or only with very, very stupid people deserving no better (like the DAO holders). If this is not possible, you are in for a rough ride. Like the DAO holders.
I would like to insist on the fact that ONLY the byte code is the contract - which is why it is so important to be able to *deduce intend from byte code* and not the other way around - and this needs automatic analysis of the state tree of the byte code, and this needs a non-Turing-complete byte code language.
This is also why I consider the DAO hacker not a thief, and why I consider that the real scammers are the Slock it people (even though they may even have been scammers without realizing it). This is because the concept of *smart contract* is new, and the ETH fork has hindered people in helping them understand this new and strange beast.
This is also why I consider the DAO hacker not a thief, and why I consider that the real scammers are the Slock it people (even though they may even have been scammers without realizing it). This is because the concept of *smart contract* is new, and the ETH fork has hindered people in helping them understand this new and strange beast.
I think the intent of the contract is also important. The contract has to be fair to both parties. If the intent is not to lose the money obviously, then the bad code might not stand.
I would like to insist on the fact that ONLY the byte code is the contract - which is why it is so important to be able to *deduce intend from byte code* and not the other way around - and this needs automatic analysis of the state tree of the byte code, and this needs a non-Turing-complete byte code language.
This is also why I consider the DAO hacker not a thief, and why I consider that the real scammers are the Slock it people (even though they may even have been scammers without realizing it). This is because the concept of *smart contract* is new, and the ETH fork has hindered people in helping them understand this new and strange beast.
Consider the following: an ethereum lottery. It is very simple: during the week, people "buy tickets" of the contract, by sending a fixed sum of ethereum (the price of the ticket) to the contract. Saturday, at noon, the contract "draws randomly" one of the participants, who gets all the ethereum, except for 1% of the pot, which goes to the dev (a fixed address in the contract).
Now suppose I analyse the code, and see that the "random generator" is in fact a thing that calculates the numerical value of the last few bytes of a hash of every participating address, and picks the one that is closest to a prime number. In case of equality, it picks the one closest to the biggest prime number. In the case of still equality, it goes to the earliest participant signing up.
Once I understand this, I generate myself a lot of addresses, until I find one that gives a hash of which the tail's numerical value is exactly equal to the biggest prime number that can occur in the finite set the contract considers. I play with that address, immediately after the start of a new week, and of course, each time, I win. Nobody knows, because each week, I generate a new address with the same bytes at the end. That takes me some hashing power, but not so very much. It can take a long time before people realize. They see each week a winner, with a different address.
Am I a cheater ? Am I a thief ? Or just someone who read the contract and understood how to use it profitably ?
The REAL scam comes from the announcement of the contract, which tells people that there is a RANDOM drawing amongst participants. People *imagine* a different contract, than the one they are signing up to. But this blah-blah over intend of the contract is not what people SIGN UP TO. They only sign up to byte code.
This is why ONLY the byte code should be read by signers. And this is why it should be analysable automatically. And this is why there shouldn't be any "explanation of intend" on any web site concerning any smart contract. Only the byte code should be there, to be read/analysed by whoever is interested in signing it.
If you find that strange/ridiculous/unattractive, then you start seeing what smart contracts really are.
This is also why I consider the DAO hacker not a thief, and why I consider that the real scammers are the Slock it people (even though they may even have been scammers without realizing it). This is because the concept of *smart contract* is new, and the ETH fork has hindered people in helping them understand this new and strange beast.
Consider the following: an ethereum lottery. It is very simple: during the week, people "buy tickets" of the contract, by sending a fixed sum of ethereum (the price of the ticket) to the contract. Saturday, at noon, the contract "draws randomly" one of the participants, who gets all the ethereum, except for 1% of the pot, which goes to the dev (a fixed address in the contract).
Now suppose I analyse the code, and see that the "random generator" is in fact a thing that calculates the numerical value of the last few bytes of a hash of every participating address, and picks the one that is closest to a prime number. In case of equality, it picks the one closest to the biggest prime number. In the case of still equality, it goes to the earliest participant signing up.
Once I understand this, I generate myself a lot of addresses, until I find one that gives a hash of which the tail's numerical value is exactly equal to the biggest prime number that can occur in the finite set the contract considers. I play with that address, immediately after the start of a new week, and of course, each time, I win. Nobody knows, because each week, I generate a new address with the same bytes at the end. That takes me some hashing power, but not so very much. It can take a long time before people realize. They see each week a winner, with a different address.
Am I a cheater ? Am I a thief ? Or just someone who read the contract and understood how to use it profitably ?
The REAL scam comes from the announcement of the contract, which tells people that there is a RANDOM drawing amongst participants. People *imagine* a different contract, than the one they are signing up to. But this blah-blah over intend of the contract is not what people SIGN UP TO. They only sign up to byte code.
This is why ONLY the byte code should be read by signers. And this is why it should be analysable automatically. And this is why there shouldn't be any "explanation of intend" on any web site concerning any smart contract. Only the byte code should be there, to be read/analysed by whoever is interested in signing it.
If you find that strange/ridiculous/unattractive, then you start seeing what smart contracts really are.
JJG already explained things well, but I'm going to add a few things, so that maybe you start to understand.
It would indeed even be worse if smart contracts were themselves Turing-complete state machines. But this is not what I'm alluding to. In a Turing-complete language, you cannot *automatically and systematically* test a random given piece of code on ALL OF ITS STATES because that set is potentially infinite.
In other words, if I give you a random piece of byte code (which is an actual contract you're wondering if you should engage with it or not), there's no systematic way to obtain the full state tree from it with a tool. Mind you that you have to use the *byte code* and not the Solidity source code from which it is supposed to be compiled, because in the end it is the byte code that will be running, and all subtleties of side effects of the compilation are too difficult to take into account. A given contract doesn't even have to have Solidity source code: you can always set up the byte code independently.
There's no possibility to obtain *automatically and with certainty* the full state tree of a contract.
And the whole art of lawyers looking at business contracts is to explore the state tree: ALL possible states and outcomes a contract can have. THE VERY PRINCIPLE of an honest contract is that the signing parties are aware of ALL the possible states and outcomes of a contract.
This is entirely different for software in general. Software in general (for instance, scientific software) is often used to obtain outcomes *people didn't know in advance*. Here, Turing-completeness IS a good thing.
But NOT in contracts. In as much as a contract is supposed to be honest, ALL ITS STATES must be obviously understood and known to the signing parties. And that is exactly what Turing complete languages don't allow you to obtain with certainty on a random piece of contract byte code. This is also why there is this stupid gas limit of which all the exploits are not yet starting to occur and for which one can design very, very subtle exploits.
Now, of course you CAN limit yourself to a testable SUBSET of byte code, but that misses the point that you cannot test "a random contract given to you" ; that the nodes cannot do that test, and hence have to apply a gas limit of which nobody knows exactly what leaves this cuts off the state tree/graph of the contract.
On non-turing complete contract systems, you don't need any gas limit, because every node can analyse the contract, and find out how big the state tree is, and what is its longest path.
Cutting away "long paths" with a gas limit can introduce also a lot of exploits. For instance, you might set up a contract such that redeeming ether is only possible for certain addresses, because the calculation is depending on the address and for most addresses, this calculation is too long and will always be cut off by the gas limit ; or you could be more subtle, and have certain contract instructions to be impossible by gas limit if they come from certain addresses. This could even be induced after the contract is running, by giving instructions that can only come from one address, obfuscated by gas limit.
The gas limit is necessary because of Turing completeness, and the fact that a node cannot analyse the tree of just any random contract.
Don't confuse a technical hardfork and breaking immutability. Even if monero is hardforking over introducing confidential transactions, this is not breaking immutability as compared to the INTEND of the white paper. Bitcoin never broke immutability, but hardforked several times - all this time, the intend of the white paper has been preserved, and all of the history has been preserved.
The only time that one could naively think that this didn't happen, was when a BUG in the node software didn't follow the white paper intend, and allowed for *non valid blocks by intend* to be validated erroneously. When the bug was repaired, the white paper intend was restored, and of course a whole lot of blocks turned out not to be valid: but the point is, they NEVER were valid according to the intend of the white paper. So this was not a break of immutability.
Mind you that node software is NOT a smart contract, but normal software, that implements INTEND. There's nothing wrong with changing that software, as long as one sticks to intend, and as long as one preserves the past in as much as that past was in agreement with the intend of the protocol.
The whole idea of the block chain technology is that the antagonism between the players, their diversity and number is so big, that only consensus can be found over the original white paper intend, and the real history according to that original protocol (as intend).
But you are perfectly right that this can fail. There's no guarantee that this immutability will remain. However, in that case, the block chain failed. It is no more or no less than a 51% attack. People can decide to continue to use the failed chain. This is my big surprise with ETH: it is a failed chain, that has been 51% attacked, but continues to live on.
I don't call gambling on block chain tokens "investing". It is gambling, nothing more and nothing less. Investing means helping to set up production capital with economic growth as its consequence and source of reward. Buying bitcoin and hodling, or gambling on altcoins, at no point, helps buying capital goods or services: it only pumps money from greater to lesser fools.
If you're in the gambling business, actually you don't mind in any case what happens, because you're betting on a random generator. If you're in the crypto token gambling business, there doesn't even need to exist any block chain: just tokens on exchanges: IOU on websites.
You are right that the danger of a block chain failing exists. What is amazing, is that the tokens of failed chains continue to be traded. That is, to me, like if one were still trading Apple shares the months after Apple was out of business. But it is not impossible. After all, trading only needs belief.
I know that. But it created a huge moral hazard: first of all, it didn't punish the DAO gamblers as it should have, for having signed up to a smart contract that wasn't what they naively thought it was. So it has allowed the DAO gamblers to profit from the buzz over smart contracts, without confronting them with the actual way smart contracts work (namely, through exploits). It has failed to make people see what it *really* means: "unstoppable code" because one stopped it. So these gamblers, that had invested in a VERY BAD IDEA, have been rewarded with not losing their funds as it should have been. And the guy known as the DAO hacker has been ripped off from his true use of the smart contract.
Because a smart contract is just a piece of byte code, and nothing more. Advertising any *intend* of a smart contract is scamming people. Most smart contracts do that: they say that this contract is doing this or that. That's scamming people. The ONLY thing one should tell you about a smart contract, is its byte code - like the ONLY thing that you (or your lawyer) should read is the actual contract you sign, and not any "explanatory but not engaging documentation" that comes with it. The thing you put your signature on, is the final arbiter. With a smart contract, it is the byte code. That is why the DAO hacker wasn't a thief, or a cracker: he just read the byte code, and saw the state that looked very advantageous to him (and to every participant that would have read the byte code, and nothing but the byte code).
And this is why an analysis of the byte code, and nothing but the byte code, is important, to derive the full state tree. And that is why Turing complete byte code language makes this impossible.
I wonder if those 3 people decide to bring out a new core that strips Satoshi of his holdings, by blocking any transaction of the first 50 000 blocks UTXO, whether that would be adopted.
Being bad because of turing complete is bullshit. ETH is turing complete, but smart contracts dont have to, so that argument is dead from the start.
It would indeed even be worse if smart contracts were themselves Turing-complete state machines. But this is not what I'm alluding to. In a Turing-complete language, you cannot *automatically and systematically* test a random given piece of code on ALL OF ITS STATES because that set is potentially infinite.
In other words, if I give you a random piece of byte code (which is an actual contract you're wondering if you should engage with it or not), there's no systematic way to obtain the full state tree from it with a tool. Mind you that you have to use the *byte code* and not the Solidity source code from which it is supposed to be compiled, because in the end it is the byte code that will be running, and all subtleties of side effects of the compilation are too difficult to take into account. A given contract doesn't even have to have Solidity source code: you can always set up the byte code independently.
There's no possibility to obtain *automatically and with certainty* the full state tree of a contract.
And the whole art of lawyers looking at business contracts is to explore the state tree: ALL possible states and outcomes a contract can have. THE VERY PRINCIPLE of an honest contract is that the signing parties are aware of ALL the possible states and outcomes of a contract.
This is entirely different for software in general. Software in general (for instance, scientific software) is often used to obtain outcomes *people didn't know in advance*. Here, Turing-completeness IS a good thing.
But NOT in contracts. In as much as a contract is supposed to be honest, ALL ITS STATES must be obviously understood and known to the signing parties. And that is exactly what Turing complete languages don't allow you to obtain with certainty on a random piece of contract byte code. This is also why there is this stupid gas limit of which all the exploits are not yet starting to occur and for which one can design very, very subtle exploits.
Now, of course you CAN limit yourself to a testable SUBSET of byte code, but that misses the point that you cannot test "a random contract given to you" ; that the nodes cannot do that test, and hence have to apply a gas limit of which nobody knows exactly what leaves this cuts off the state tree/graph of the contract.
On non-turing complete contract systems, you don't need any gas limit, because every node can analyse the contract, and find out how big the state tree is, and what is its longest path.
Cutting away "long paths" with a gas limit can introduce also a lot of exploits. For instance, you might set up a contract such that redeeming ether is only possible for certain addresses, because the calculation is depending on the address and for most addresses, this calculation is too long and will always be cut off by the gas limit ; or you could be more subtle, and have certain contract instructions to be impossible by gas limit if they come from certain addresses. This could even be induced after the contract is running, by giving instructions that can only come from one address, obfuscated by gas limit.
The gas limit is necessary because of Turing completeness, and the fact that a node cannot analyse the tree of just any random contract.
Quote
Immutability ? Are you that naive ? Any blockchain can hardfork, eth is not less or more immutable than any other blockchain and no project can guarantee that wont happen.
Don't confuse a technical hardfork and breaking immutability. Even if monero is hardforking over introducing confidential transactions, this is not breaking immutability as compared to the INTEND of the white paper. Bitcoin never broke immutability, but hardforked several times - all this time, the intend of the white paper has been preserved, and all of the history has been preserved.
The only time that one could naively think that this didn't happen, was when a BUG in the node software didn't follow the white paper intend, and allowed for *non valid blocks by intend* to be validated erroneously. When the bug was repaired, the white paper intend was restored, and of course a whole lot of blocks turned out not to be valid: but the point is, they NEVER were valid according to the intend of the white paper. So this was not a break of immutability.
Mind you that node software is NOT a smart contract, but normal software, that implements INTEND. There's nothing wrong with changing that software, as long as one sticks to intend, and as long as one preserves the past in as much as that past was in agreement with the intend of the protocol.
The whole idea of the block chain technology is that the antagonism between the players, their diversity and number is so big, that only consensus can be found over the original white paper intend, and the real history according to that original protocol (as intend).
But you are perfectly right that this can fail. There's no guarantee that this immutability will remain. However, in that case, the block chain failed. It is no more or no less than a 51% attack. People can decide to continue to use the failed chain. This is my big surprise with ETH: it is a failed chain, that has been 51% attacked, but continues to live on.
Quote
Any blockchain can be hardforked so if you dont agree with that, dont join blockchain scene / dont invest.
I don't call gambling on block chain tokens "investing". It is gambling, nothing more and nothing less. Investing means helping to set up production capital with economic growth as its consequence and source of reward. Buying bitcoin and hodling, or gambling on altcoins, at no point, helps buying capital goods or services: it only pumps money from greater to lesser fools.
If you're in the gambling business, actually you don't mind in any case what happens, because you're betting on a random generator. If you're in the crypto token gambling business, there doesn't even need to exist any block chain: just tokens on exchanges: IOU on websites.
You are right that the danger of a block chain failing exists. What is amazing, is that the tokens of failed chains continue to be traded. That is, to me, like if one were still trading Apple shares the months after Apple was out of business. But it is not impossible. After all, trading only needs belief.
Quote
And a one case scenario doesnt make it rule, people only agreed with it because it didnt really rollback anything besides the dao, it was a special case, dao was LOCKED. If hacker could withdraw it immediately and sell or what not, hf wouldnt have been an option anymore. You are very naive and ill informed.
I know that. But it created a huge moral hazard: first of all, it didn't punish the DAO gamblers as it should have, for having signed up to a smart contract that wasn't what they naively thought it was. So it has allowed the DAO gamblers to profit from the buzz over smart contracts, without confronting them with the actual way smart contracts work (namely, through exploits). It has failed to make people see what it *really* means: "unstoppable code" because one stopped it. So these gamblers, that had invested in a VERY BAD IDEA, have been rewarded with not losing their funds as it should have been. And the guy known as the DAO hacker has been ripped off from his true use of the smart contract.
Because a smart contract is just a piece of byte code, and nothing more. Advertising any *intend* of a smart contract is scamming people. Most smart contracts do that: they say that this contract is doing this or that. That's scamming people. The ONLY thing one should tell you about a smart contract, is its byte code - like the ONLY thing that you (or your lawyer) should read is the actual contract you sign, and not any "explanatory but not engaging documentation" that comes with it. The thing you put your signature on, is the final arbiter. With a smart contract, it is the byte code. That is why the DAO hacker wasn't a thief, or a cracker: he just read the byte code, and saw the state that looked very advantageous to him (and to every participant that would have read the byte code, and nothing but the byte code).
And this is why an analysis of the byte code, and nothing but the byte code, is important, to derive the full state tree. And that is why Turing complete byte code language makes this impossible.
Quote
Also, centralized blockchains are more at risk of being hard forked, like bitcoin, 3 people can decide that, and it will be done, if they wanted to. Eth is the most decentralized project out there.
I wonder if those 3 people decide to bring out a new core that strips Satoshi of his holdings, by blocking any transaction of the first 50 000 blocks UTXO, whether that would be adopted.
Mining1... you are full of shit and contradictions that I am questioning whether to respond to you globally or to pick apart your various points of bullshit.
I guess I should pick it apart a little bit, otherwise possibly you and/or other readers may conclude that my comments are too general.
Being bad because of turing complete is bullshit. ETH is turing complete, but smart contracts dont have to, so that argument is dead from the start.
Most likely the essence of the earlier argument by dinofelis has to do with the failure of the ETH overall and the recognition that we are not quite ready for Turing completeness - especially the DAO and ETH seemed to be an attempt to lead us down that path, and we are just not ready, yet. Likely, the better conclusion is that for quite some time to come, we are going to need various kinds of human intervention, but whatever the fuck combination of human intervention and non-intervention that ETH and the DAO came up with was either before its time or otherwise all fucked up - but what would you expect from scheming pump and dump contradictions?
Sure, some day there could be a role for turing completeness and smart contracts, yet whatever evolved through ETH seemed to be much more hype and marketing rather than real attempts at real world applications - just like your attempts to characterize criticisms as bullshit and dead from the start, when there is some bases for the criticisms.
Immutability ? Are you that naive ?
You seem to be the one that is naive in your attempt to belittle other folks when you in fact seem to be missing some of the overall points.
Yes, there was considerable problems with the evolution of ETH based on recent mutability applications. ETH carried out hardforks more than once and engaged in other manipulations, but this last one kind of seemed to have bit them in the ass (likely more than expected).
I don't know whether ETH had ever intended to be immutable, yet the recent success of ETC to sustain itself as an ETH rebellion demonstrates (beyond the pump and dump aspect) that a considerable following in the Ethereum community were displeasured by the way that ETH had gone about its most recent hardfork and even the justification for that decision to hardfork and the way that they carried it out.
Any blockchain can hardfork, eth is not less or more immutable than any other blockchain and no project can guarantee that wont happen.
Here you go again, trying to minimize Ethereum's decision to hardfork by suggesting false equivalencies and suggesting that anyone can hardfork at any time. Sure, in the end, there is some truth to your stupid ass assertion that any chain can hardfork, but you are losing quite a bit of nuance when you try to suggest that anyone can hardfork at any time... and failing to take into account exactly how ETH decided to hardfork and under what circumstances and what circumstances would cause another chain to hardfork.
News ALERT... not all coins are created equal and not all hardforks are created equal.. and likely bitcoin has learned some from ETH about the dangers of hardforking and are even more reluctant than they were earlier regarding going down a hardfork path - especially a controversial hardfork... on the other hand, if a hardfork is clearly non-controversial, then there is likely more reason to go down such path (which was not the case with ETH's hardfork... ETH's hardfork was controversial - and maybe not realized by some folks until after witnessing how much support ETC received subsequently to the hardfork).
Any blockchain can be hardforked so if you dont agree with that, dont join blockchain scene / dont invest.
I think that I already addressed this point.. even though any blockchain can hardfork, not all blockchains are equal, and not all blockchains will enter into controversial hardforks without some kind of preparation for repercussions.
And a one case scenario doesnt make it rule, people only agreed with it because it didnt really rollback anything besides the dao, it was a special case, dao was LOCKED. If hacker could withdraw it immediately and sell or what not, hf wouldnt have been an option anymore.
Yes, you are trying to justify particulars of the hardfork when in essence, the hardfork decision was rash, unjustified and likely more controversial than anticipated.
You are very naive and ill informed.
Name calling is not helpful, even when you seem to be the one that is attempting to avoid engaging with substance by throwing out these kinds of remarks and your actual remarks seem to show that you are living in a bit of a fantasy world that is filled with selective choosing of facts... and spin.
Also, centralized blockchains are more at risk of being hard forked, like bitcoin, 3 people can decide that, and it will be done, if they wanted to.
O.k.. you seem to be engaging in more characterizations here, rather than reality.
Ethereum is centralized and bitcoin is not.
A large point of bitcoin's proof of work adds up to decentralized immutability.. and that is largely what gives bitcoin value as being paradigm shifting like no other coin.. including Ethereum.. .
Ethereum has demonstrated its centralization with recent actions including the recent hardfork. Bitcoin has been having a battle over this for nearly a year, and in essence bitcoin has not been easy to hardfork and there remains considerable resistance to the hard forking of bitcoin. Ethereum's recent experience lends additional factual evidence and logic concerning why bitcoin should not go down any kind of controversial hardfork way... and your attempts to suggest that bitcoin is some how similar or equal to ethereum seem to be based in fantasy world thinking rather than accounting for actual facts and actual recent history concerning both chains.
Eth is the most decentralized project out there.
This is one of the stupidest comments that you could make. Your mere assertion of such fact does not make it true.
Ethereum has recently been hardfork in a controversial way over a controversial and insubstantial reason, which demonstrates its lack of decentralization. Bitcoin on the other hand has the most powerful computing system dedicated to proof of work, which allows for decentralization and immutability.... Ethereum is no where near bitcoin's level, so you are talking nonsense in your assertion about Ethereum's supposed "most decentralized" standing.
Being bad because of turing complete is bullshit. ETH is turing complete, but smart contracts dont have to, so that argument is dead from the start. Immutability ? Are you that naive ? Any blockchain can hardfork, eth is not less or more immutable than any other blockchain and no project can guarantee that wont happen. Any blockchain can be hardforked so if you dont agree with that, dont join blockchain scene / dont invest. And a one case scenario doesnt make it rule, people only agreed with it because it didnt really rollback anything besides the dao, it was a special case, dao was LOCKED. If hacker could withdraw it immediately and sell or what not, hf wouldnt have been an option anymore. You are very naive and ill informed.
Also, centralized blockchains are more at risk of being hard forked, like bitcoin, 3 people can decide that, and it will be done, if they wanted to. Eth is the most decentralized project out there.
Also, centralized blockchains are more at risk of being hard forked, like bitcoin, 3 people can decide that, and it will be done, if they wanted to. Eth is the most decentralized project out there.
Jump to: