The Ethereum Paradox

[TPTB_need_war]

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.

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?

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?

[1714138152]

1714138152

[1714138152]

1714138152

[YarkoL]

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.

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"

[TPTB_need_war]

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.

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"

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.

[YarkoL]

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.

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"

The distinction for Side Chains is one block chain is subject to the 51% attack of the other block chain.

Well you got me again.

[TPTB_need_war]

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.

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"

The distinction for Side Chains is one block chain is subject to the 51% attack of the other block chain.

Well you got me again.

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

[monsterer]

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?

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.

[TPTB_need_war]

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?

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.

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.

[monsterer]

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 by the external entity that provided that "transaction" as you call it.

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.

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

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

[TPTB_need_war]

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 by the external entity that provided that "transaction" as you call it.

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.

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.

[monsterer]

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.

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?

[stoat]

Anonymint chatting absolute horse cock again.

[TPTB_need_war]

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.

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?

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.

Anonymint chatting absolute horse cock again.

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.

[monsterer]

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

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

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?

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.

[TPTB_need_war]

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

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

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.

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?

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.

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?

[monsterer]

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?

It's a shame that you are unable to explain yourself given a straightforward question and are forced to resort to childish insults.

[TPTB_need_war]

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?

It's a shame that you are unable to explain yourself given a straightforward question and are forced to resort to childish insults.

I have already explained it. I was also cordial in hinting to you that you needed re-read my post and learn. Then you pushed it by saying my cordial hint was not civil. So I tried to explain it to you again. Now you've gone one step further by calling your Professor childish.

I think perhaps what you are proposing (yet you did not articulate it) is that you want every transaction to require that the input data is annotated to specify where that data appears on the block chain (i.e. which script output it is). But that means you are proposing to exclude "external I/O"; and I had already written upthread that yes if a design excludes external I/O then the problem is solved, but this means the programmability is mostly useless, e.g. no new accounts, etc..

Please monsterer think about what I have written. Please learn about type systems and what "dependently typed" means. Take some quiet time.

[Peachy]

Being someone with first hand experience, and the technical knowledge to present challenges to TPTB's arguments when applicable, I can tell you its just too damn painful to do so.

No developer worth any salt is going to engage with him because it simply devolves into name calling if you don't align with his thoughts.  Before long the n00b, b-lister, you are not worthy comments start regardless of if he's right or not and its just a noisy waste of time.  I've seen the same towards people just trying to understand and not necessarily even disagreeing.

The discussion ends in a blaze of fire with one of the parties leaving, usually it's not TPTB that has departed (he can argue all damn day) so it "looks" from the outside that he won, even if in reality his "facts" are wrong.

Aaaand it begins.

TPTB:  Something to consider:
http://www.principiadiscordia.com/forum/index.php?topic=32044.0

Smartest Guy in the Room syndrome is related to Dunning/Kruger Effect, and affects men and women equally.

The Smartest Guy in the Room is smart enough to know that he's smarter than most people, but not smart enough to recognize when other people are smarter. He defaults to the belief that because he is smarter than the majority of the population, he must be smarter than the people he's talking to, and tends to look no further or deeper than whatever initial assumption he has made or conclusion he has come to.

The Smartest Guy in the Room is recognizable for his tendency to dismiss other people's views without critically examining why, for glancing at a discussion, assuming other people are being foolish, and correcting them based on that assumption without actually checking the source material himself to understand what they are discussing, and for either digging in his heels and screeching, or for "refusing to argue because it's pointless" whenever anyone else presents difficult-to-refute information that contradicts his conclusion.

He actually can't learn, because he thinks he already knows, and that the rest of us simply aren't smart enough to see his enlightenment. The Smartest Guy in the Room has usually been through at least one, sometimes two jailbreaks, but then something critical happened; he stopped. Convinced that he had broken out of his cell, he latched onto whatever form of enlightenment helped him get there, failing to realize that enlightenment is a verb, not a noun. Clinging to the implements of his enlightenment, he also failed to notice that he is once again squatting in a cell almost identical to the one he believed he had left behind.

There is nothing that can be done with a Smartest Guy in the Room, as any attempt to convince him that he is missing out on a huge aspect of bipedal development will simply lead to him thinking that you don't understand his unique and highly sophisticated perspective. In that sense, the Smartest Guy in the Room is stuck in a state of arrested development, at approximately age fourteen.

He is a lost cause and cannot be rehabilitated.

[TPTB_need_war]

Good luck with that.  One of the things that made Bitcoin great is consensus via economics that's advantageous for the individual and the group.

Yeah it is absolutely great that China's mining bloc controls 65% of Bitcoin's hashrate and has vetoed any block size increase, including Classic's proposed mere doubling of the block size to 2MB only. Ostensibly they want to force transaction fees higher to fatten their profits. This is called an oligarchy and it is great for individuals like us, so we can pay through the nose to the oligarchy.

Thanks again for your incredible wisdom and including your sage proclamation that Szabo is a crypto god and was/is Satoshi.

Peachy has joined you in my very exclusive Ignore list, which I reserve for the wisest soothsayer salesmen.

[monsterer]

I think perhaps what you are proposing (yet you did not articulate it) is that you want every transaction to require that the input data is annotated to specify where that data appears on the block chain (i.e. which script output it is). But that means you are proposing to exclude "external I/O"; and I had already written upthread that yes if a design excludes external I/O then the problem is solved, but this means the programmability is mostly useless, e.g. no new accounts, etc..

I am suggesting that in many cases it is acceptable to allow external I/O, as long as the scripts which are built using external I/O are aware of each other and their sequencing requirements are met. Here is a trivial example:

External I/O source: a store of a single off-chain integer and script triggering mechanism
Script A: receives an integer as input, doubles it, returns it
Script B: receives an integer as input, halves it, returns it

*) The I/O source starts with the integer 1
*) It triggers script A
*) Waits until A appears in the chain, then triggers B with a dependency for the last observed A
*) Waits for B to appear and then re-triggers A with a dependency for the last observed B
*) Rinse and repeat.

What will the result be after 10 iterations?

Yes this example is trivial and simple, but it includes external I/O with dependencies exactly as I described.

[Mvann]

Props to monsterer for facing the beast head on

We shall wait for the rebuttal.. hehe

Edit:

One observation I make myself is that TPTB first implied pretty strongly that whatever the issue was (outside my understanding) it was so fundamentally flawed it was unsolvable guaranteeing Ethereums fall. However, as I understand it atm it's more of a "the direction is wrong, maybe there is a solution, Ethereum should hire me to solve the problem"

I feel an apology here is warranted in case I am completely wrong with my assumption. Clearly TPTB is a bright guy and surprisingly very pleasant as evident by the video. Shocking but true