As monsterer and I have been alluding to up thread, afaics you have not definitively stated the frame-of-reference—employed by your ("every UTXO output has its own block chain") design—for Byzantine fault tolerant consensus, so I have now expended the time to research, think, and hopefully correctly define it.
Your design's frame-of-reference for Byzantine fault tolerant consensus is majority of the vote by the "voters" which have locked a suitable amount of coins (value). We must determine the (game theory) objectivity of this frame-of-reference and the impacts within the CAP theorem.
The record of who are the majority throughout the history of time must be recorded in the history of the consensus, otherwise there is no consensus about what the majority was and thus what it is now. For example, if someone controlled sufficient coins in the past (greater than the number of coins that were locked for voting in the current public consensus history), they could erase the entire history from that point, by publishing a new block for their historical UTXO (even if they historically spent them subsequent to the historical block where they were UTXO) locking their coins for voting and then voting to make their revision of history the dominant majority. The major distinction from (and flaw compared to) Bitcoin's PoW is that competing versions of history are not compared by the accumulated amount of resources committed to each version. In Bitcoin's PoW, the longest chain accumulates all the PoW in the chain (thus unlike in your design, in PoW there can only be one longest one and thus only one majority!), but afaics in your design all the coins locked subsequent to a fork revision of history are not accumulated in comparison. I suppose you could propose to accumulate locked coin-days-destroyed, but the problem is there is not objective measure of "days destroyed" that the adversary can't game. Or you could propose to accumulate some other resource as a measure of the longest chain which could not be readily fabricated by the adversary, but I would have to analyze a specific proposal (which afaics you have not yet made). Essentially the issue is long-term "nothing at stake".
Now I've read up thread that you claim that you don't even store a record of the vote history, but not only does this appear to show you are somewhat myopic about how your design functions, and also as monsterer pointed out, if you don't store the history then there is no way for a node which is not omniscient to know what the objective consensus is without invoking trust (and decentralized currency must be trustless else it devolves in numerous ways to centralized currency). About whether you are storing the voting implicitly, afaics your design must record as transactions which coins are locked and the implicit entangling of cross-spending between chains implicitly records which chains elected which forks, but I guess you are correct that voting is not even implicitly stored if voters (defined by locked coins) are not injectively (and non-surjectively) mapped to chains (i.e. if voters don't correspond to chains).
So the "partial ordering" in your design is really unknowable levels of durable partitioning and thus non-durable consistency, because there is no way to guarantee anything about confirmation and objectivity of the majority consensus now or anytime into the future.
The only way around this is to rely on "weak subjectivitiy" where trust in the social consensus provides the long-term checkpoints. Problem with that is there may be disagreement in the social consensus in that case usually "might makes right". However in that case, Bitcoin is also subject to "might makes right" where the 51% attack can revise history as well. If you don't store records of voting short-term, then there is no trustless objectivity from last "weak subjectivity" check point. Without recording the voting, the confirmation of a transaction is unknown (nebulous).
Since your coin is named RaiBlocks, perhaps you had seen the following before:
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
Even if you do record the voting, then the problem is there is "nothing at stake" in the short-term and thus history can be rewritten in the short-term. The various proof-of-stake algorithms attempt to penalize short-term adversarial behavior to eliminate this "nothing at stake" hole.
Assuming you work out how to penalize short-term adversarial activity (and not just rely on the non-quantitative game theory myopia that adversaries won't be self-interested because they devalue the coin and thus their holdings in the coin) to remove "nothing at stake", rely on "weak subjectivity" of social consensus for long-term check points, work out how to incentivize fast recording and propagation of majority confirmation, then you will have achieved some form of block chain scaling, but until those specifics are revealed (not yet invented?), then we can only speculate. One thing that appears to be clear in your RaiBlocks design is that every full node must receive and verify every transaction in your system, so that aspect of scaling hasn't been improved.
Btw, I will tell you that I worked out those design issues already. Essentially my comments above are directing you to my design.
Your design's frame-of-reference for Byzantine fault tolerant consensus is majority of the vote by the "voters" which have locked a suitable amount of coins (value). We must determine the (game theory) objectivity of this frame-of-reference and the impacts within the CAP theorem.
The record of who are the majority throughout the history of time must be recorded in the history of the consensus, otherwise there is no consensus about what the majority was and thus what it is now. For example, if someone controlled sufficient coins in the past (greater than the number of coins that were locked for voting in the current public consensus history), they could erase the entire history from that point, by publishing a new block for their historical UTXO (even if they historically spent them subsequent to the historical block where they were UTXO) locking their coins for voting and then voting to make their revision of history the dominant majority. The major distinction from (and flaw compared to) Bitcoin's PoW is that competing versions of history are not compared by the accumulated amount of resources committed to each version. In Bitcoin's PoW, the longest chain accumulates all the PoW in the chain (thus unlike in your design, in PoW there can only be one longest one and thus only one majority!), but afaics in your design all the coins locked subsequent to a fork revision of history are not accumulated in comparison. I suppose you could propose to accumulate locked coin-days-destroyed, but the problem is there is not objective measure of "days destroyed" that the adversary can't game. Or you could propose to accumulate some other resource as a measure of the longest chain which could not be readily fabricated by the adversary, but I would have to analyze a specific proposal (which afaics you have not yet made). Essentially the issue is long-term "nothing at stake".
Now I've read up thread that you claim that you don't even store a record of the vote history, but not only does this appear to show you are somewhat myopic about how your design functions, and also as monsterer pointed out, if you don't store the history then there is no way for a node which is not omniscient to know what the objective consensus is without invoking trust (and decentralized currency must be trustless else it devolves in numerous ways to centralized currency). About whether you are storing the voting implicitly, afaics your design must record as transactions which coins are locked and the implicit entangling of cross-spending between chains implicitly records which chains elected which forks, but I guess you are correct that voting is not even implicitly stored if voters (defined by locked coins) are not injectively (and non-surjectively) mapped to chains (i.e. if voters don't correspond to chains).
So the "partial ordering" in your design is really unknowable levels of durable partitioning and thus non-durable consistency, because there is no way to guarantee anything about confirmation and objectivity of the majority consensus now or anytime into the future.
The only way around this is to rely on "weak subjectivitiy" where trust in the social consensus provides the long-term checkpoints. Problem with that is there may be disagreement in the social consensus in that case usually "might makes right". However in that case, Bitcoin is also subject to "might makes right" where the 51% attack can revise history as well. If you don't store records of voting short-term, then there is no trustless objectivity from last "weak subjectivity" check point. Without recording the voting, the confirmation of a transaction is unknown (nebulous).
Since your coin is named RaiBlocks, perhaps you had seen the following before:
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
Quote from: Vitalik Buterin
perhaps the best example is the Rai stones, where a tribe in Yap essentially maintained a blockchain recording changes to the ownership of stones
Even if you do record the voting, then the problem is there is "nothing at stake" in the short-term and thus history can be rewritten in the short-term. The various proof-of-stake algorithms attempt to penalize short-term adversarial behavior to eliminate this "nothing at stake" hole.
Assuming you work out how to penalize short-term adversarial activity (and not just rely on the non-quantitative game theory myopia that adversaries won't be self-interested because they devalue the coin and thus their holdings in the coin) to remove "nothing at stake", rely on "weak subjectivity" of social consensus for long-term check points, work out how to incentivize fast recording and propagation of majority confirmation, then you will have achieved some form of block chain scaling, but until those specifics are revealed (not yet invented?), then we can only speculate. One thing that appears to be clear in your RaiBlocks design is that every full node must receive and verify every transaction in your system, so that aspect of scaling hasn't been improved.
Btw, I will tell you that I worked out those design issues already. Essentially my comments above are directing you to my design.
As monsterer and I have been alluding to up thread
Monsterer and I have been having discussions and you may not be in as much agreement as you believe.
I will wait to see a public post from monsterer if he disagrees with my assessment. Are you referring to private discussions with him? Because in my quick perusal of his public posts in this thread, they seem to be congruent with my points. Feel free to point out a case where you think his points are not congruent with mine.
afaics you have not definitively stated the frame-of-reference—employed by your ("every UTXO output has its own block chain")
Those words are in quotes though it is not factually a quotation.
Perhaps American English is not your native language? I did not quote you. If I did, I would have used the normal forum quoting as I always do. Placing a phrase between double quotes can also mean that the quoted description is an example of how someone might say it (not specifically any person, since the quote was not attributed to any person).
design—for Byzantine fault tolerant consensus
There is no such thing as Byzantine fault tolerance since the byzantine problem is stated in terms of separation of communication a.k.a. network partitioning. Only after partitions have been merged can a final conclusion be reached for instance bitcoin isn't tolerant against partitioning since if the network was partitioned and each separate segment was generate separate block chains, a conclusion as to which is the longest couldn't be reached until the partitions were merged and the results compared, hence it would no longer by a byzantine problem. Please read up more on the topic before commenting on them.
Do NOT again write an absurd condescending remark that assumes I hadn't yet researched the fundamental concepts.
Try to remain respectful please (and leave the ad hominem shit aside) as we had been up thread.
I have no idea what rational basis you have told yourself to justify assuming I don't understand the definition of Byzantine fault tolerance. How could I possibly be commenting with so much technical knowledge in your thread if I hadn't yet researched the fundamental concepts.
https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
, so I have now expended the time to research, think, and hopefully correctly define it. Your design's frame-of-reference for Byzantine fault tolerant consensus is majority of the vote by the "voters" which have locked a suitable amount of coins (value). We must determine the (game theory) objectivity of this frame-of-reference and the impacts within the CAP theorem.
Again, the CAP theorem states that all three states cannot simultaneously be achieved so by the nature that RaiBlocks, in addition to any crypto currency, does not claim it can operate while partitioned, this means at most we're claiming 2 out of 3 which by definition satisfies the CAP theorem and no cryptocurrency out there is violating it. Please read more before commenting.
This ad hominem noise again.
Yet another vacuous argument demonstrating that you do not understand that Bitcoin is partition tolerant within its Byzantine fault tolerant objectivity. Byzantine fault tolerance doesn't mean that CAP has to be fulfilled for those observers who are ignoring the longest chain rule or who are unwilling to accept the probabilitistic nature of the expectations (and thus the fault tolerance). Within Bitcoin's objectivity of the longest chain, all three of the CAP attributes are attained. And my criticisms of your design are about its ill-defined objectivity.
Let this technical rebuttal be instructive to you on the fact that my skills/expertise/research in this area are higher than you apparently assume (given your condescending remarks and your continual unwillingness to accept that 3 experts gmaxwell, monsterer, and myself have come into your thread and graciously tried to explain that your design has serious flaws).
The rest of your reply really seemed to start going off the rails of rational logic. But I will try to find the desire to reply to it point-by-point after I cool down from the lashing of your condescending assumptions above.
afaics you have not definitively stated the frame-of-reference—employed by your ("every UTXO output has its own block chain")
Those words are in quotes though it is not factually a quotation.
Perhaps American English is not your native language? I did not quote you. If I did, I would have used the normal forum quoting as I always do. Placing a phrase between double quotes can also mean that the quoted description is an example of how someone might say it (not specifically any person, since the quote was not attributed to any person)
According to the writer's handbook https://writing.wisc.edu/Handbook/QPA_quoting.html Quotations are literal quotations and should cite references, Adding Clarification, Comment, or Correction requires square brackets around what you're modifying.
http://www.apastyle.org/learn/faqs/use-double-quotes.aspx
I'm sure you'll have no problem writing up another post 
I warned you not to write condescendingly to me again. Now I will more forcefully state the facts.
I can see I am dealing with a pedantic Dunning-Kruger jackass who has too limited understanding of the technical field to discern technobabble from expertise.
Arguing with someone who is not knowledgeable enough in the field to know whey are acting as a Dunning-Kruger jackass, ends up being an enormous waste of time and effort for the expert.
When you are ready to come down from your ignorant high horse and learn, let me know.
Note most readers here are not knowledgeable enough to discern that you are not an expert. Thus you can probably convince them to invest in your project. The proof of failure will come down the line. No need for me to educate you beforehand, given your attitude.
The continuous citation of the CAP theorem is ridiculous. BitCoin does not have partition tolerance according to the cap theorem "the system continues to operate despite arbitrary partitioning due to network failures" BitCoin does not operate in the presence of arbitrary network failures, this it categorically wrong. No cryptocurrency can operate while partitioned, they can recover from partitions but they cannot operate while partitioned. CAP does not apply to any cryptocurrency ever, repeating it at all is absolutely absurd.
Bitcoin does "continue to operate despite arbitrary partitioning due to network failures".
Again you conflate the double-spend on a forked network in your mind a claimed refutation of CAP, because you assume CAP is only useful in an absolute frame-of-reference. But absolute frames-of-reference do not exist in the universe. And this shows you do not understand the definition of "Byzantine fault tolerance", because it only applies to the nodes on each of the forked networks as to whether the objectivity of the system has remained intact and the nodes can continue to operate within that defined objectivity.
Essentially what you are trying to say with your design and your arguments in this thread, is there is no possible objective frame-of-reference, because there never can exist an absolute one. You conflate absolutism with relative objectivity (which btw is all we have in our universe, because nothing is absolute).
At least Bitcoin achieves CAP up to the limitation that networking partitioning can fork the Bitcoin network and the participants on each fork can continue to operate. Whereas, your design doesn't even achieve assurances of objectivity even without network partitioning.
I do not appreciate your ad hominem accusations claiming/implying that I am generally not correct in my logic because it is another attack on my person instead of refuting a stated technical issue. (Nothwithstanding that my logic is correct and you are not skillful enough to discern it yet)
Also you conflate a) refuting a stated fact; with b) making a statement about a person's need to read before commenting. The former is not ad hominem, the latter is ad hominem. Period.
Edit: also you are assuming CAP only applies to the physical network partitioning, but it also applies to logical partitioning. Bitcoin is resilient to logical partitions (forks) because of the longest chain rule. Your design is not analogously resilient, which monsterer and I have explained.
The record of who are the majority throughout the history of time must be recorded in the history of the consensus, otherwise there is no consensus about what the majority was and thus what it is now.
That's not correct, the consensus now is all that matters. For instance as humans we don't have a record of all governments and all decisions going back to the beginning of time yet we have a consensus about what we agree to at this moment. A historical record can be interesting but the only thing that matters is consensus at this current point in time, only historians care about anything else and currency isn't about a history lesson.
Perhaps you missed the fact that I already stated that without recording of the voting, there is no way to know when "now" is as it pertains to confirmation of consensus being attained. How is the payee supposed to know when to trust the payment and release the goods or services?
Without recording the voting, the confirmation of a transaction is unknown (nebulous).
For example, if someone controlled sufficient coins in the past (greater than the number of coins that were locked for voting in the current public consensus history), they could erase the entire history from that point,
This seems to be erroneous. Historical consensus cannot override contemporary consensus, contemporary consensus is the only thing that matters with RaiBlocks. The only way to erase history is for the current consensus to flip blocks a.k.a. a true, >50% attack.
This is because you have no objective means of determining which set of "now" is the reality. Thus you assume that the online nodes will just magically agree on the "now" they all have. The fact that you can't see that you've failed to even define the way the majority chain is objectively determined, should be indicative of that you are not sufficiently knowledgeable to design a new block chain paradigm.
Two or more errors don't make it correct. You can state that your system flies to the moon and if that assumption is based on foundational errors then no one can disprove your claim. The proof will come in the fantastic devolution of your system in the wild.
Also you seem to have lost the point that if the historical coins locked was only 1% of the coin supply, then only 1.1% of the coin supply would need to be retroactively locked to rewrite history in the lack of durable objectivity in your system.
I am not going to go back and forth with you on the comedy of errors. It is a pointless waste of my scarce time.
by publishing a new block for their historical UTXO (even if they historically spent them subsequent to the historical block where they were UTXO) locking their coins for voting and then voting to make their revision of history the dominant majority.
This is describing a >50% attack, all cryptocurrencies are vulnerable to this though RaiBlocks give a stronger guarantee. With RaiBlocks >50% of the MARKET CAP needs to vote to flip, with PoW only 50% of the mining strength needs to flip. If you look at BitCoin's market cap of ~4billion, and ask: could you gain majority mining power with ~2 billion in mining hardware? Absolutely. PoW is a weaker guarantee.
Logic fail. You are assuming every coin is locked so every coin votes, which means no coins can be transacted. Duh.
, if you don't store the history then there is no way for a node which is not omniscient to know what the objective consensus is without invoking trust (and decentralized currency must be trustless else it devolves in numerous ways to centralized currency).
That's true, in fact most people who use bitcoin are invoking trust because they trust the wallet they're using to correctly evaluate which chain has the highest block work and not log the password to their private keys.
You habitually conflate orthogonal concepts.
Even if the vast majority of users do not run full nodes, the security of Bitcoin is still based on the objectivity of the full nodes, which your design does not possess.
Assuming you work out how to penalize short-term adversarial activity (and not just rely on the non-quantitative game theory myopia that adversaries won't be self-interested because they devalue the coin and thus their holdings in the coin)
You're stating this is myopic but this is the exact rhetoric people use when rebutting against why miners wouldn't start mining forks in to BitCoin. Destroying the protocol destroys future profit in the protocol hence it's in the miner's and voter's best interest to come to consensus instead of creating volatility. This seems to be a fundamentally flawed application of game theory.
The astute people such as Gregory Maxwell understand how critical it is that no party has 51% or even 25% of the network hashrate. Do not let what fools write misdirect you on the objectivity of Bitcoin.
Rhetorical much.
