Topic: The Ethereum Paradox - page 51. (Read 99910 times)

Sorry this is evidence that is not the case that we are not peers.

And the sooner you respect that, then the sooner I can respect you.


monsterer you are babbling nonsense. Sorry I am not going to unravel for you the entangled myopia you are weaving. The more I try to explain, the more deeply you will nest your misunderstanding. This is simply ridiculous that you are incapable of understanding freshmen level Computer Science.

Did you study at the university?

Frankly, you are no such professor and I am no such student. This is a discussion among peers in a forum.


Why do we need to force the external entity to do its job correctly? If a mechanism exists with which this entity can do its job correctly, then by not using said mechanism the fault lies entirely with that entity. If there are subsequent systems built which utilise said entity, they will have to be updated to remove their reliance upon it because it is faulty. To hope for anything else is to hope for the impossible.

What did I write that wasn't civil and factual?

If a student was babbling nonsense in front of the entire classroom and the Professor tried to amicably ask the student to please go study a bit more because he doesn't seem to understand some basic issues, and the student continued to ramble on filling up the entire 2 hour class session with his misunderstanding, would the Professor be uncivil to finally put his foot down and demand "please stop".

I don't know why you can't comprehend what I have already written. The "transaction" which contains the input data for a script, can be set by any external entity. How do you propose to require that the bits & bytes of that input data declares its dependencies when it is impossible to force the external entity to declare where the data came from? You seem to not understand some basic facts about modularity and type systems in programming. Even if you could force the external entity to declare the full lineage of the input data (i.e. 100% dependently typed), that would require that the scripting can't be programmable, i.e. the external I/O capability would be eliminated. If you don't understand why, please go learn about the typing systems Coq and Epigram.

Please review a post about typing Modularity from Philip Wadler on Gilad Bracha's blog (hope you realize who those two guys are) and note his post immediately followed my post. My post was even deeper than Wadler's and in fact what I wrote there in 2011 is exactly what I am writing here about Ethereum. If anyone wants to identify a god in computer science, Philip Wadler would rank orders-of-magnitude higher than Szabo. Even the Lex Spoon who comments after Wadler wrote the book on Scala. Gilad only wrote the specification for Java.

You should know that Wadler invented the Expression Problem, which is precisely about how to produce statically typed extensible programmability without needing to refactor and recompile. I did a lot of research on this Expression Problem and even Stackoverflow deleted some of my earlier research.

---

You are so ignorant of Computer Science that you don't even know the difference between horse shit and a textbook.

How can anyone expect me to be nice to you, when you belittle academics.

I suppose it is good you are so stupid that you don't realize how stupid you are, as it can be considered a defense mechanism against depression. Ignorant bliss.

Anonymint chatting absolute horse cock again.

Try to stay civil please. External inputs to a script always come in the form of a transaction. Any given transaction may depend on other transactions. As long as this dependency constraint is respected in the resulting overall ordering of transactions, I'm not sure there is a problem?

Re-read my prior post. You seem to not understand basic facts of computer science and thermodynamics, i.e. you can't prevent the external entity from lying.

That is exactly the point, though - if the external entity is required to specify the dependencies explicitly, the system ought to be able to reach an appropriate ordering.


I wasn't driving at discussing that, it just naturally appeared as a direct consequence of looking at your problem statement for ethereum.

If you are talking about scripting, then I think you've failed to entirely understand the point. That is that the data specified as input to any script can't be prevented from being taken from another script (in another partition) by the external entity that provided that "transaction" as you call it. The data can't be dependently typed such that it totally orders the universe external to the block chain. That is a fundamentally known fact of computer science and the Second Law of Thermodynamics. This is for example why Haskell has the IOMonad and the Control.Monad.ST.Unsafe. A 100% dependently typed program is 100% deterministic and thus can't be programmed to do anything new, i.e. it is an entirely closed system and can't accept any external entropy.

If you want to talk about total eventual ordering of transactions for directed acyclic graphs, I think we should do so in your thread.

This is more a theoretical question about the overall solvability of the problem with scripting, dependencies and ordering. All inputs to a script come via a transaction, so, I am asking if there were a set of dependencies specifiable in any given transaction that forced the referenced transactions* to be ordered before the new transaction, is this enough for the system to decide on an overall order?

*) To address your other point, specifically in ethereum, dependencies would have to be specified as references to previous blocks, not previous transactions because, as you point out, there is only a partial order in a blockchain. The system would then have to group transactions with compatible dependencies into blocks.

In addition, yes, I am hoping an eventual total ordering of transactions is possible.

See my edit. No you got me, because I failed to explain that clearly.

Well you got me again.

Good you pointed that out, so I can clarify.

The distinction for Side Chains is one block chain is subject to the 51% attack of the other block chain. So the security is only as strong as the weakest block chain.

I think that any kind of attempted solution of any problem is subject to the same "criticism".

"Sure, this works... but remember that 51% attacker can rewrite the entire chain"

You are referring to asset exchange (not Ethereum's scripting). As you have stated, only the consensus mechanism can choose between the plurality of partial orderings because the partial orderings are arbitrary (and in the presence of competing double-spends, the partial orderings are conflicting). Thus Nash equilibrium depends on the consensus mechanism not being gameable which is the point I was making in my Edit#2 of my prior post.

I am interpreting your posts as you continue wishing for some sort of absolute, structural synchrony which can't exist in distributed systems. Did I misunderstand your question?

What I mean is, is it possible to specify a set of non cyclic dependencies for any given transaction, which when ordered by the system results in a complete resolution of this dependency entanglement?

For readers, what monsterer is pointing out here is that the design of decentralized cross-chain (meaning two coins' block chains, not two candidate chains for the same longest-chain-rule block chain) exchange suffers from if either block chain orphans the block that the other block chain depended on, i.e. that a chain reorganization on one block chain of one coin isn't enforced on the other coin's block chain, thus one of the parties in the exchange steals from the other (because the one keeps the coins on both chains).

So monsterer is offering this as an example where even for only asset exchange block chains (i.e. no scripting), there is the case that external factors can cause the "system" to fail from the perspective of the user.

And this is the main problem with Blockstream's proposed Side Chains, in that chain reorganizations could cause a cascade of failure, which thus seem to make Side Chains totally insecure and unworthy of adoption. Some people have argued that exchanges could be delayed by sufficient confirmations, but remember that with proof-of-work a lie-in-wait 51% attacker can rewrite the entire block chain. Then again others point out that we are screwed any way with a 51% attacker and that the community will organize. Note I rebutted this in my video, by explaining that community can't organize. Please watch my video to get the full explanation. Note that the Chinese mining cartel already controls 65% of Bitcoin's hashrate and has vetoed any block size increase, not even allowing the doubling of block size for Bitcoin Classic, thus this has shown the community can't overcome a 51% attack.


For monsterer's example (not Side Chains), I argue that the user is capable of associating that failure with incorrect use of the system and localized to use of a decentralized exchange. Whereas the distinction from the partitioned scripting case is that users wouldn't even be able to know what service they used had caused the failure, because the failure could occur derivatively due to intertwined cascade from other scripts. In short, the users (or programmers) of violating scripts may be aware that the assumption of cross-partition has been violated, but the rest of the users would be incapable of making this determination!


Even the script can't stop a user from copying data from one partition to another. So even if Ethereum only runs authorized and vetted scripts, this afaics wouldn't totally ameliorate the issue.

Edit: Of course (external) I/O from scripts can input to other scripts in a myriad of cascade and permuted entanglement.

When I write 'external I/O', I mean differentiated from referencing some data on the block chain as an input, e.g. UXTO. You see that for asset exchange, the data is deterministic because all I/O must sum to 0 and the directed acyclic graph assures us there is no recursion of the state.

Edit#2: It appears to me that for asset exchange all I/O is deterministic. For scripting, this is not the case due to external I/O, not even without partitions! But at least without partitions, then scripting apparently doesn't violate the Nash equilibrium in the sense that all scripts are validated by all validators (thus there is no way for the validators for a partition to lie to the other validators). Whereas in partitioning, sufficient (w.r.t. to the consensus-by-betting resolution) validators might lie about their partition (i.e. pursue another strategy) since that is another game theory strategy that is introduced by the partitioning given that the partitions can't be enforced externally. The distinction is about Nash equilibrium. Per the definition of Nash equilibrium, then validators pursing another strategy (i.e. lying) destroys the Nash equilibrium.

You might argue that the author of any script which disobeys these hidden dependency rules isn't following the rules of the system.

The question is: is this problem actually fixable in theory? Can you imagine a system whereby a single transaction contains multiple downward dependencies which potentially merge partitions? Is there a case where a conflict in ordering dependency can occur between scripts?

Note edit I made to a post on the prior page:


Speculators who think Szabo and Vitalik are gods deserve what the Bible says in the Ten Commandments:


These guys took $18 million to go work on vaporware and didn't even produce a scalable prototype.

The first sin was taking ICO money when all they had to offer was their reputations and no actual product or even completed research.

Why do humans base so much on perceived reputation. Reputation is overrated. Completed production talks, all the other BS walks.

There are so many smart people in this world. Smartness isn't enough.

You all have destroyed this young man. You spoiled him. I had to cut lawns and I developed my first commercial software success by sleeping under my desk and programming from my room. Sacrifice.

Case in point: atomic cross chain transfers. That's the realisation of the failure in contemporary blockchains. I don't believe it causes a breakdown of the nash equilibrium, though - the miners still follow their usual rules.

You got it with the edit. You must have re-read my prior post and the edits I had done on my prior post.

The issue is the system thinks it has strict partitioning, but the external users can violate that partitioning of state (at least with scripts, not sure yet about only asset transfers). The system thinks that the state of one partition can't impact the state of another partition, but the external users can violate this assumption if there exists the ability to apply external input to the block chain (which obviously must exist otherwise the scripting is mostly useless, i.e. no new accounts, etc).

For asset transfers, I need to think about the harm that can be done and whether the same problem applies. For scripting (with external I/O) it is clearly impossible to assume/enforce strict partitioning of state.


No script fails from the perspective of the block chain. The external users see failure, because only the external users are aware they violated the strict partitioning of state. And thus the spaghetti of external failure becomes as intertwined as inputs and outputs from many partitions cross-pollute cascades and intertangled scripts.

Edit: the block chain thinks it is validating the block chain because it erroneously thinks strict partitioning is enforced. External users see that validation is failing, because they violated the assumption of strict partitioning by cross-polluting the state via the external I/O of the block chain. Thus holistically and systemically there is failure (from the perspective of the external users and thus the coin's market value plummets as users abandon the system due to failures).