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.