ETH = Game Over

[JayJuanGee]

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.

[1715001331]

1715001331

[1715001331]

1715001331

[JayJuanGee]

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. 

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.

[vlight]

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.

[dinofelis]

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.

[JayJuanGee]

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.

[dinofelis]

...

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.

[dinofelis]

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.

[JayJuanGee]

...

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.

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 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.

[Latmist]

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.

[mining1]

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.

[dinofelis]

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.

[JayJuanGee]

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/

[JayJuanGee]

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.

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.

[RealBitcoin]

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?

[dinofelis]

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.

This is also related to this "Turing completeness".  You only have untrusted code if there is no systematic way to analyse the code.  For instance, bitcoin scripts are also "untrusted code" but as the bitcoin scripting language is not Turing complete, the number of states of any bitcoin script is always limited (and usually very small) ; as such, bitcoin scripts cannot do much mischief (apart screwing up the transaction they are handling).  There are no "unanalyzable bitcoin scripts". 

[LiberOptions]

Ethereum Price Technical Analysis – ETH Overbought, Caution Ahead

Ethereum price continued to impress, as it registered solid gains not only against the US dollar, but also against Bitcoin. There was a move above the $14.00 handle, which is a sign that the price is an uptrend. My yesterday’s idea of buying ETH worked once again. There was a bullish trend line on the hourly chart (data feed via SimpleFX) of ETH/USD, which played well and acted as a buy zone...

http://www.newsbtc.com/2016/09/21/ethereum-price-technical-analysis-eth-overbought-caution-ahead/

[LiberOptions]

ETH Trims Gain, Recovers

Ethereum Price Recovery

Ethereum price made a short-term top yesterday against the US Dollar as I pointed out. There was a sharp decline, as the ETH/USD pair fell below the $12.50 support area and somehow managed to hold $12.25. Yesterday’s highlighted bearish trend line on the hourly chart (data feed via SimpleFX) of ETH/USD acted as a resistance and pushed the price down.

link

[RealBitcoin]

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.

This is also related to this "Turing completeness".  You only have untrusted code if there is no systematic way to analyse the code.  For instance, bitcoin scripts are also "untrusted code" but as the bitcoin scripting language is not Turing complete, the number of states of any bitcoin script is always limited (and usually very small) ; as such, bitcoin scripts cannot do much mischief (apart screwing up the transaction they are handling).  There are no "unanalyzable bitcoin scripts". 

Yes, and even this will be solved, in the malleability fixes deployed by segwit and other future implementations.

The only way to securely run an online financial network is to have only trusted code on it, and the worst thing to happen is for a transaction to not go through.

But with ETH, i bet there are zero day bugs that could cause a lot of harm, if not for the system itself, but for smart contracts, like how the DAO got screwed.

[LiberOptions]

Ethereum Price Weekly Analysis – ETH Remains Supported

Ethereum price ETH surged higher recently versus the new dollar and we even saw a new monthly high of $14.22. There was a nice upside move, and showed that the price remains in an uptrend. ETH/USD is currently correcting lower. It already broke the 23.6% Fib retracement level of the last wave from the $10.17 low to $14.21 high. So, there is a chance that the pair may trade down further from the current levels.

Link

[molsewid]

Ethereum is having Ddos attack again and the developer confirmed that be careful for those who using desktop wallet before thats the targets of the hacker OMG why they doing this on ethereum , it was nice and the price is stable in up and down