Quote from: TPTB_need_war on February 13, 2016, 01:16:59 PM

Quote from: TPTB_need_war on February 13, 2016, 10:36:17 AM

[...]

Afaics, Ethereum has an additional insoluble challenge which eMunie, Iota, and my design do not have to solve. That is they have to guarantee ordering of contract execution is Consistent even within a partition, which afaik (from Computer Science fundamentals) is impossible unless the scripts are 100% dependently typed; because otherwise they are not commutative and the permutations of orderings with the unbounded recursion of general scripting results in the block chain state being indeterminate. If one instead argues that any partial ordering will suffice (just chose one arbitrarily), this is equivalent to arguing that contract ordering doesn't matter, i.e. that they are commutative. It is a circular logic. So I really have no idea what the designers of Casper are thinking Huh

Quote from: https://blog.ethereum.org/2015/12/24/understanding-serenity-part-i-abstraction/

Serenity is intended to have two major feature sets: abstraction, a concept that I initially expanded on in this blog post here, and Casper, our security-deposit-based proof of stake algorithm. Additionally, we are exploring the idea of adding at least the scaffolding that will allow for the smooth deployment over time of our scalability proposals, and at the same time completely resolve parallelizability concerns brought up here an instant very large gain for private blockchain instances of Ethereum with nodes being run in massively multi-core dedicated servers, and even the public chain may see a 2-5x improvement in scalability.

Above I and Vitalik both linked to the same page (in fact I got that link from the quoted Vitalik text):

http://www.multichain.com/blog/2015/11/smart-contracts-slow-blockchains/

The point that page makes is that validating Ethereum contracts MUST be slow because nothing can be validated with parallel computation.

I am making an additional and more damning point. That is since each contract WITHIN a block has to be executed to completion before the next (i.e. no parallelization) this also means that the result of the block chain state will be potentially different depending on which order the contracts are ordered in the block. But note that such order is completely arbitrary (because there is no synchrony in distributed systems, i.e. there is no way to prove which transaction arrived first during the block period since each node will have a different ordering due to variance in network propagation).

The becomes an insoluble problem due to chain reorganizations (unless everyone waits for umpteen confirmations before validating anything but then how do we order the blocks...etc...see next paragraph).

Also we can't assume that contracts in one partition don't affect a contract in another partition due to externalities, e.g. for example the result of a contract causes an external action which causes the execution of another contract. The point of computation is that it is not bounded at the block chain!!!!!!!!!!!!!!!!!!!!!!

Thus if thus if the block period is not infinitesimally small (or especially as the block period grows larger), then the indeterminism that is introduced can cause contracts to behave randomly if they were not designed to handle such indeterminisn. Or worse yet, the validators on different partitions will be in predicament where if there are two or more orderings that are incompatible from different partitions and thus the block chain can't be unified and diverges into forks.

The externalities problem is entirely unfixable. Period! The only way to fix it is to not verify smart contracts on a block chain and instead only record the directed acyclic graph asset transfers on the block chain as the section "Smart contracts in public blockchains" explains. This means the entire premise of Ethereum is impossible. Fugetaboutit. Stick a fork in it. It is going to $0 their funding will run out and the game is over.

This is why I said the Ethereum developers do not fully understand the implications of the CAP theorem in conjunction with Turing completeness (or more saliently with the Second Law of Thermodynamics).

I am very tired of people saying that I am trolling and that the Ethereum developers are more clever than I am.

Even I remember Nick Szabo made an analogous error when he was at that conference where that guy claimed to be Satoshi and Nick was perplexed as to how the Bitcoin block chain could be made Turing complete with externalities. Someone tell Nick Szabo to read this (specifically from section "Double decker blockchains" forward):

http://www.multichain.com/blog/2015/11/smart-contracts-slow-blockchains/

Make sure you click the video link in the following quote!

Quote from: TPTB_need_war on December 13, 2015, 10:41:22 PM

My immediately prior installment in this journey was about Turing-completeness, so it is highly relevant to note that Nick Szabo just demonstrated to me that he is lacking knowledge about Turing-completeness compared to this Craig Wright that some are claiming might be Satoshi.

At roughly the 17 minute mark in this conference video, Wright correctly explains that due to unbounded recursion, the Bitcoin block chain scripting is effectively Turing-complete. Afaics, he is entirely correct and Nick Szabo is wrong, because although the scripting language stack can't loop within one transaction, one can use multiple transactions to simulate looping. This is precisely the point I made in my recent post wherein I explained that under composition it is impossible to prevent unbounded recursion and thus unbounded entropy. Review the Dr. Suess proof of Turing-completeness. It doesn't matter what the called script answers, the calling script can always change the outcome. If you have the ability to store state on the block chain across multiple invocations of a script, then the block chain becomes the stack. Nick Szabo just demonstrated to me that he isn't as smart as I thought. Dr. Wright makes a relevant point that many people these days seem to forget that in machine code there is no virtual machine that controls what the instruction set can do in terms of which memory it can treat as a stack. Bitcoin's script instruction set can be viewed as machine code w.r.t. to its ability to read and store state any where in the memory space of the block chain UTXO.

What Dr. Wright meant when he said, "the looping function is actually separate from the loop itself ... that would assume the only way of devising code would be to put it directly in the script". Szabo made really stoopid statement implying that the language can only be Turing-complete if the script stack is, but he completely fails to realize that the block chain is state and thus can be an orthogonal stack. And most definitely then you can loop. When I say "loop", I mean in the sense relative to the block chain as the stack, so I do not mean that any one transaction can loop. Yet such a distinction is arbitrary any way, because I can have a client interacting with the block chain causing it to loop.

Here is more about conjecture about Craig Wright being Satoshi:

http://www.wired.com/2015/12/bitcoins-creator-satoshi-nakamoto-is-probably-this-unknown-australian-genius/

http://www.theguardian.com/technology/2015/dec/09/bitcoin-creator-satoshi-nakamoto-alleged-to-be-australian-academic

http://www.theguardian.com/technology/2015/dec/09/bitcoin-founder-craig-wrights-home-raided-by-australian-police?CMP=twt_a-technology_b-gdntech

Edit: and add Gregory Maxwell (nullc) to list of people who don't understand Turing-completeness:

Quote from: LiteCoinGuy on December 09, 2015, 06:37:05 AM

He's discussion at the All Star Panel, was very odd, and not in any way lucid or clear. Here is /u/nullc take on a transcript I made. https://www.reddit.com/r/Bitcoin/comments/3w027x/dr_craig_steven_wright_alleged_satoshi_by_wired/cxsfy8p

I've read everything refferenced in this post and my conclusion is following. It is up to the programmers that will be deleloping applications to make sure there is a logic inside smart contracts which are essentially computer programs with unlimited capabilities to have logic that will take care of out of order problems. Yes it is possible to write an application on Ethereum that will produce unpredictable results. But it is also possible to write applications that will work smoothly if the developer understands the architecture well enough. Its really pointless to have a general discussion without reference to specific application. One thing is for sure: the slowlness and lack of concurrency greatly limits possible applications. What worries me is that Vitalik is computer science drop out and he may have missed some of the important stuff that people suppose to study

The whole thing about Ethereum seems to me like a strech of imagination that may lead nowhere. Blockchain is very specific thing created for very limited and specific purpose and so will be possible applications of Ethereum which I see to be mostly limited to transactional stuff. These applications will have to be quite simple, no heavy processing is going to work well in such archetecture. I really would like to see very specific ideas for Ehtereum apps and not general stuff that is theoretically possible.