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.
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.
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.
, 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.
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.
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.
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.
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.
Again, looking back to the beginning of time is unnecessary, whether Tlok in his cave in 5000BC got a majority vote is of no consequence today when I spend my money, no one cares, it's just slow.
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).
This speculation is unnecessary since I'm making no such claim. The algorithm stands as-is.
What's at stake is market cap which is why voting is given, in proportion to balance held, to value holders. Only people holding value in the network truly care about its health. A >50% attack definitely does have something at stake, they're destroying the currency that they own 50% of. Would a bitcoin holder who held 2 billion in bitcoin start DDOSSing the network or mining in forks? Absolutely not, they'd lose their investment.
Now I've read up thread that you claim that you don't even store a record of the vote history
As has already been fully and completely demonstrated, a fully history is unnecessary.
but not only does this appear to show you are somewhat myopic about how your design functions, and also as monsterer pointed out
Monsterer and you have fewer agreements than you believe.
, 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. As much as people want to believe otherwise, all cryptocurrencies have a degree of trust when downloading a wallet and bootstrapping to the network.
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).
This seems to be a fundamental misunderstanding of the system as a whole. Voters are a one-to-one function of chains, though it's not onto since accounts can designate a representative to vote with their stake on their behalf.
So the "partial ordering" in your design is really unknowable levels of durable partitioning
Since all chains are replicated to all peers, there is no partitioning. Again, this system, like all cryptos does not insure correctness in the case of partitioning. I don't know why the CAP theorem ever needs to be brought up, no one ever claims their crypto works when the network is partitioned. If you ever cite the CAP theorem again, please directly and succinctly cite where someone is specifically and directly saying their crypto will work in the case of network partition, otherwise you're technobabbling.
and thus non-durable consistency,
Durability is ensured as much as durability can be assured in any distributed system, by broadcasting the transactions to all nodes. Do you mean Durability in the sense of ACID transactions or is this a new definition of durability?
because there is no way to guarantee anything about confirmation and objectivity of the majority consensus now or anytime into the future.
I'll defer commentary on this conclusion until proper reading is performed.
That may not be the only way, it's impossible to prove unknowns; this is a flawed conclusion.
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/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.
Again, history cannot be rewritten without a >50% stake in contemporary consensus in which case 50% of the market cap is voting to destroy their investment.
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.
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.
