Quote from: monsterer on February 16, 2016, 11:30:26 AM

Quote from: TPTB_need_war on February 16, 2016, 11:13:12 AM

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.