The Ethereum Paradox

[stoat]

And more condensed again, ETH needs Casper to work as promised, that is the entire core and value, correct?

So if Casper is still not ready and maybe can Never be created decentral, ETH has a value between a MySQL DB and NXT....

You wish FUD masters

[1714810778]

1714810778

[1714810778]

1714810778

[1714810778]

1714810778

[TPTB_need_war]

Sorry, a bit more precise: Is casper the  base for the Smart contract executor?

No...   smart contracts are already a reality without Casper.

https://etherchain.org/contracts

Smart contracts in a real world setting that must scale can not exist without Casper.

The virtual machine for smart contracts runs, but any sort of real world scaling of the virtual machine requires Casper.

I have explained why Casper can't possibly work and my point is unarguable.

[stoat]

Smart contracts in a real world setting that must scale can not exist without Casper.

The virtual machine for smart contracts runs, but any sort of real world scaling of the virtual machine requires Casper.

I have explained why Casper can't possibly work and my point is unarguable.

Yes, without Casper scaling is out of the question (or impossible even with Casper according to you).

I thought the question being asked was whether Casper had something to do with the EVM itself or not.


Casper is the thing that makes ETH different and let it be a smart contract Running blockchain?
Is casper the  base for the Smart contract executor?

Nope

[TPTB_need_war]

Trolls could sell turds as Snicker bars floating the swimming pool. Difference here is that speculators have no care whatsoever if the technology will actually work or not, because speculators are only chasing price (and the insiders can manipulate the price buying from themselves because they control the float, thus converting greater fools into cash flow for the Casper team to waste another $15 million down a rat hole). Thus trolls find it valuable to pollute the technology discussion with inane posts.

[stoat]

Trolls could sell turds as Snicker bars floating the swimming pool. Difference here is that speculators have no care whatsoever if the technology will actually work or not, because speculators are only chasing price (and the insiders can manipulate the price buying from themselves because they control the float, thus converting greater fools into cash flow for the Casper team to waste another $15 million down a rat hole). Thus trolls find it valuable to pollute the technology discussion with inane posts.

you have not explained in a coherent way why casper won't work.  It's impossible because casper is not released yet so you have no idea how it will work.

You are just an angry FUDer at this point.

[TPTB_need_war]

The trolls and I are going to play a game of how many times the same post can be repeated in a thread to see who wins the battle of attrition about facts versus FUD.

Just a heads-up...   I don't have anything specific to say about it:

https://www.youtube.com/watch?v=StMBdBfwn8c

The discussion continues...    

Part 1 - https://www.youtube.com/watch?v=QMJJl10MVyU

Readers should note I commented on the prior linked video upthread. Now I will comment on the second one you've linked to.

Listening to this video further affirmed how lost the Casper design team is.

Around the 27 minute point, Lucius Greg Meredith interjects the salient point that voting on blocks can't be orthogonal to voting on partitions. And you can see the point I made upthread as quoted below, that there is no possible way to partition the gas for scripts. Thus there can't be a Nash equilibrium on partition voting.

Vlad proposes to separate the voting for hashes of "blocks" (these "blocks" don't reference a prior block hash as in Satoshi's design, so Greg renames them "sequences") which he assumes are pre-partitioned, and then separately vote on how these blocks are ordered into a "state root". But the problem is that scripts need gas to run and since it is impossible to partition gas, then the entire assumption is invalid that validators can assume the transactions in their partition are orthogonal.

Bottom line is they will fail. They apparently haven't realized this yet, and they haven't articulated the core essence yet. I am superior designer (and note that Gregory Maxwell did not reply again because ostensibly he knows I am correct) because I can cut directly to the core issues.

Even if someone argued against my upthread point that strict partitions can't exist for scriptable block chains wherein I claimed this is due to uncontrolled external chaos due to external I/O, there is another unarguable reason that strict partitions can't exist for a scriptable block chain. That is because the gas (currency) transfers must be atomic with the script block confirmation (i.e. if they are orphaned and chain reorganized then they must be done together) so they must be in the same partition. But if the currency for a partition is a static set of UXTO or account balances (i.e. no cross-partition spending), then the system can not function properly.

Yet we also explained above (and even monsterer agrees on this point fwiw) that cross-partition spending breaks the Nash equilibrium.

Thus I continue to maintain my point that Ethereum can not scale with decentralized validation.

The point of the above quote is that gas can't be spent across partitions. There is no way to merge partitions because it introduces the ability to double-spend in more than one partition. Thus if gas can't be spent across partitions then there is no way that gas can be moved in and out of partitions to where it is demanded.

The only way to spend a token across partitions is to have a LCR (a single partial order) for all partitions, i.e. a single partition for inter-partition state changes. LCR means longest-chain-rule. But this can only be a Nash equilibrium when all validators for the LCR validate all partitions (otherwise because as explained upthread, the Nash equilibrium is lost because the winner of a block can't be sure if he is building off an invalid state). Thus cross-partition spending requires centralization of validation (a.k.a. verification) because LCRs require centralization of validation. So if the point of sharding (a.k.a. partitioning) was to decrease latency and speed up and decentralize validation, it is a futile goal. This is unarguable.

Note an alternative to LCR is a traditional proof-of-stake for enforcing a single partial order (yet the point about validation in the prior paragraph still applies), but which is highly flawed and loses Nash equilibrium in numerous ways. Worse is that Casper's consensus-by-betting has a combinatorial explosion of partial orders, so as Vitalk admits in the above linked video, the model doesn't converge on enforcing a single partial order. The failure to converge (or the alternative being over fitness and converging on noise, as Vitalik also admitted) is entirely expected because proof-of-stake is self-referential and thus does not have a reference point from which to anchor a single partial order for which the Nash equilibrium can't be gamed. The way proof-of-stake overcomes this is by being essentially centralized. But I have also shown (see link in prior paragraph) that proof-of-work is also economically driven to centralization of validation.

There is only one way out of this mess for consensus systems, and that is my design which centralizes validation but decentralization control over the choice of validators (and decentralized statistical validation of validators).

[Piston Honda]

Trolls could sell turds as Snicker bars floating the swimming pool. Difference here is that speculators have no care whatsoever if the technology will actually work or not, because speculators are only chasing price (and the insiders can manipulate the price buying from themselves because they control the float, thus converting greater fools into cash flow for the Casper team to waste another $15 million down a rat hole). Thus trolls find it valuable to pollute the technology discussion with inane posts.

you have not explained in a coherent way why casper won't work.  It's impossible because casper is not released yet so you have no idea how it will work.

You are just an angry FUDer at this point.

dude for real your shilling or eth leg-humping is really annoying. fuck.

[BlindMayorBitcorn]

Trolls could sell turds as Snicker bars floating the swimming pool. Difference here is that speculators have no care whatsoever if the technology will actually work or not, because speculators are only chasing price (and the insiders can manipulate the price buying from themselves because they control the float, thus converting greater fools into cash flow for the Casper team to waste another $15 million down a rat hole). Thus trolls find it valuable to pollute the technology discussion with inane posts.

you have not explained in a coherent way why casper won't work.  It's impossible because casper is not released yet so you have no idea how it will work.

You are just an angry FUDer at this point.

dude for real your shilling or eth leg-humping is really annoying. fuck.

Like a bad dream.

[ilia7777]

[...]

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  

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!

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:

   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.

[monsterer]

Casper has much bigger problems than just the sharding - even if you remove all sharding, you cannot escape from the fact that they rely on transactions to form their consensus, when transactions require consensus due to double spends.

[TPTB_need_war]

Ethereum is already more scalable than bitcoin.

Another troll who has no technological knowledge whatsoever and thus doesn't understand what he is commenting on.

This is a technical thread. Those without technical knowledge should please go troll in their numerous ETH P&D threads.

[stoat]

Ethereum is already more scalable than bitcoin.

Another troll who has no technological knowledge whatsoever and thus doesn't understand what he is commenting on.

This is a technical thread. Those without technical knowledge should please go troll in their numerous ETH P&D threads.

How can you FUD casper when you don't know how it will work because it hasn't been developed yet?

[TPTB_need_war]

How can you report facts about Casper when you don't know how it will work because it hasn't been developed yet?

Because I've been studying consensus design issues for 3 years and I've watched numerous technical presentations on Casper, thus I know what they are designing and what is possible and impossible.

What you believe about me or my capabilities is irrelevant since you don't understand any of the technology.

Produce technological rebuttals or get off my lawn troll kiddie.

[stoat]

The fact is, you are fudding something that you have no idea about because it isnt released.

It's pretty pathetic really and you should instead be buying ETH.

[TPTB_need_war]

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.

In a strict sense you (and monsterer who mentioned that first) are correct, which is why I wrote the following:

Even if someone argued against my upthread point that strict partitions can't exist for scriptable block chains wherein I claimed this is due to uncontrolled external chaos due to external I/O, there is another unarguable reason that strict partitions can't exist for a scriptable block chain. That is because the gas (currency) transfers must be atomic with the script block confirmation (i.e. if they are orphaned and chain reorganized then they must be done together) so they must be in the same partition. But if the currency for a partition is a static set of UXTO or account balances (i.e. no cross-partition spending), then the system can not function properly.

Yet we also explained above (and even monsterer agrees on this point fwiw) that cross-partition spending breaks the Nash equilibrium.

Thus I continue to maintain my point that Ethereum can not scale with decentralized validation.

Which I subsequently elaborated on today. The point about gas is why it is impossible to have sharded validation even if the scripts can otherwise be guaranteed to respect their partitioning.

But in a real world scenario where scripting is not controlled but is open for anyone to code, then when these scripts fail, they may not only fail themselves, but they may also do other things which cause other scripts to fail and even cause the economics of 51% attacks to be much easier and more plausible (make sure you click that link, as well read how I explained it to monsterer upthread). In short, the Nash equilibrium can collapse due to unpredictable externalities. But even if you argue against this, the sharding (paritioning) of gas is implausible with sharded validation.

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.

Yeah that is my point that even though the virtual machine works, it doesn't scale decentralized (yeah sure we can scale anything centralized). And it won't even scale to where Bitcoin is now decentralized because scripts consume more validation resources than validating ECDSA signatures.

Here are some ideas for DApps to think about when designing a smart contract block chain:

www.coindesk.com/7-cool-decentralized-apps-built-ethereum/

I am of course thinking about this and how to do it correctly.

If I get healthy, I will try to teach these young guys a lesson about respecting those who have experience. I don't think Vitalik and Vlad are entirely clueless (and certainly Greg Meredith is a true academic and had worked at Microsoft Research), but I do believe they lack the experience in creating software and shipping it to millions of users. They lack some of the things I had to learn the hard way in those many years of shipping software that worked.

For example, I long ago shortcut directly to the generative essence of the problem space and thus am not wasting everyone's time and $millions pursuing braindead designs that can't possibly work. Instead I understand that validation must be centralized in any possible consensus system and thus I turned my attention to decentralized control over centralized validation. Those guys are instead still stuck back at figuring out what can't work.

[monsterer]

Which I subsequently elaborated on today. The point about gas is why it is impossible to have sharded validation even if the scripts can otherwise be guaranteed to respect their partitioning.

Gas is paid by the invoker of the script, you are aware of that?

[TPTB_need_war]

Which I subsequently elaborated on today. The point about gas is why it is impossible to have sharded validation even if the scripts can otherwise be guaranteed to respect their partitioning.

Gas is paid by the invoker of the script, you are aware of that?

That doesn't matter (or actually it makes the problem I explained more obvious). The script validation and the gas spend confirmation must be atomic, which means they must be confirmed in the same partition, else validation can not be partitioned per the logic I already explained.

[monsterer]

That doesn't matter (or actually it makes the problem I explained more obvious). The script validation and the gas spend confirmation must be atomic, which means they must be confirmed in the same partition, else validation can not be partitioned per the logic I already explained.

They will be - the gas is paid inside the same transaction which invokes the script?

edit: but, of course that does invoke the horror of double spends - since partitions are necessarily separate and unaware of each other, I can spend the same gas in multiple partitions at the same time.

[TPTB_need_war]

That doesn't matter (or actually it makes the problem I explained more obvious). The script validation and the gas spend confirmation must be atomic, which means they must be confirmed in the same partition, else validation can not be partitioned per the logic I already explained.

They will be - the gas is paid inside the same transaction which invokes the script?

edit: but, of course that does invoke the horror of double spends - since partitions are necessarily separate and unaware of each other, I can spend the same gas in multiple partitions at the same time.

You got it with your edit.

Of course the virtual machine assumes they are atomic as you first stated, but the reality of the sharding is they can't be.

Building the virtual machine was the fun, easy part. The consensus scaling was the hard part which they should have done first even before raising ICO money. That is disgraceful.

[monsterer]

You got it with your edit.

Of course the virtual machine assumes they are atomic as you first stated, but the reality of the sharding is they can't be.

Building the virtual machine was the fun, easy part. The consensus scaling was the hard part which they should have done first even before raising ICO money. That is disgraceful.

The only way around this that I can see is to make Ether non fungible, which is a bit of a problem for a currency.