Block lattice

[clemahieu]

They nice part about each account running their own chain is they all have a 100% vested interest in maintaining their own chain and 100% authority over what goes in it and when. If any forks are observed in the few seconds after send a receiver should immediately add more wait time before accepting a block out the pending/UTXO set.  Basically receivers have the option of receiving things out of order.

I don't want to sound disparaging, but that's already how bitcoin's UTXO system works. Users create transactions in their wallets by linking inputs to outputs and then signing. No one can change that outside the client. The only thing which changes outside the client is the sequencing of transactions, which is provided by the blockchain.

Agreed it's very close to what the UTXO set does. One difference is all unspent outputs are serialized and essentially combined under a single head block so a lite client could prune everything except a few head blocks for each account regardless of the number of transacions that make up their balance. This of course is a boring optimization that's been proposed for Bitcoin but never implemented.

The other reasons for breaking things up this way is to greatly decrease the number of race conditions in the protocol that need arbitration.  There's no race condition of who mined the block, whether A->B happened before or after A->C or in which block a transaction needs to be placed. All of these are benign race condition that need arbitration even in the presence of a network of all good actors.  When we allow each node to control their own chain in this way we have no arbitration for benign reasons, only the malicious cases. This also means nodes can treat forks as second class citizens without someone ddosing the network with transactions creating delays.

This gives transaction throuput limited only by hardware speed I.e. No block size discussion and transaction latency limited only by network speed I.e. No block interval discussion. Clearing transactions as fast as possible means we don't have end user confusion of "why isn't my transaction confirming" or "what fee do I put on my transaction and what does that mean"? Plus giving users what they expect in currency, native instant transactions.

Nodes listen for and tally votes, the only time they request votes is on startup syncing or if a block got a bunch of votes but it doesn't fit in the local ledger meaning we missed something and were pretty sure it's not junk because it got a fair amount of votes.

The trouble is because there is no historical voting evidence, any historical fork will require active effort to resolve.

In POW syncing nodes can trivially verify and resolve historical forks without any additional work from miners - the longest chain always wins and the  true elegance of this system is that is does not distinguish between a syncing node and a regular node; this makes it very robust.

We drop the blocks that are voted against because all that really matters is the final conclusion. Storing historical votes might not cover all vote options I.e. A node publishing a fork only to people bootstrapping in which case there's never been a vote on this block but it's equally as irrelevant as a block that's voted out.

[monsterer]

The other reasons for breaking things up this way is to greatly decrease the number of race conditions in the protocol that need arbitration.  There's no race condition of who mined the block, whether A->B happened before or after A->C or in which block a transaction needs to be placed.

I'm not sure I see how. Given a recipient A and two transaction senders B and C, if B and C send a transaction to A simultaneously, you still have the same problem - both of them attempt to update the data structure in A at once?

[clemahieu]

The other reasons for breaking things up this way is to greatly decrease the number of race conditions in the protocol that need arbitration.  There's no race condition of who mined the block, whether A->B happened before or after A->C or in which block a transaction needs to be placed.

I'm not sure I see how. Given a recipient A and two transaction senders B and C, if B and C send a transaction to A simultaneously, you still have the same problem - both of them attempt to update the data structure in A at once?

That's actually a great example of the benefit of the system, when B and C send to A simultaneously, two receivable entries are created that A needs to accept in to its chain.  A gets to create two blocks X receives from B and Y receives from C and it gets to pick the order they're placed in to A's own chain.  It could pick Y -> X -> HEAD or X -> Y -> HEAD but it picks one, signs each, and announces to the network the order A decided for its own chain.

I also threw together some animations for the confirmation and fork consensus procedure.  Let me know what you think.
https://github.com/clemahieu/raiblocks/wiki/Double-spending-and-confirmation

[Kushedout]

where does it store the wallet file? or how do I backup my wallet?  (on windows)

[clemahieu]

where does it store the wallet file? or how do you backup my wallet?  (on windows)

On Windows it stores it in C:\Users\<user>\AppData\RaiBlocks\backup

[monsterer]

It could pick Y -> X -> HEAD or X -> Y -> HEAD but it picks one, signs each, and announces to the network the order A decided for its own chain.

I also threw together some animations for the confirmation and fork consensus procedure.  Let me know what you think.
https://github.com/clemahieu/raiblocks/wiki/Double-spending-and-confirmation

Doesn't this mean that A needs to be online at the time of receipt in order to convey it's decision to the network?

[clemahieu]

It could pick Y -> X -> HEAD or X -> Y -> HEAD but it picks one, signs each, and announces to the network the order A decided for its own chain.

I also threw together some animations for the confirmation and fork consensus procedure.  Let me know what you think.
https://github.com/clemahieu/raiblocks/wiki/Double-spending-and-confirmation

Doesn't this mean that A needs to be online at the time of receipt in order to convey it's decision to the network?

If A is offline, UTXO entries accumulate.  Eventually when A is online to spend, their wallet will look at the UTXO set and pull in blocks they missed while offline.

Sending is two phases:  
Send: Deduct delta from source balance, mark block as receivable in UTXO set  
Receive: Remove block from UTXO set, increase destination balance by delta.  

[TPTB_need_war]

Let me know if you have any detailed questions about RaiBlocks.  I tried to answer them the best I could but I sense you see some outstanding issues that need addressing.

When I have free time I will get back to your "block lattice" (afair originally named "block list"?) thread, but I don't have time right now. Appears the issue will be something about having multiple partitions and prevention of double-spends globally and/or the ability to send a transaction to any block list at any time.

Multiple partitions don't come for free. You give up something. This is what I meant about the CAP theorem.

[clemahieu]

Let me know if you have any detailed questions about RaiBlocks.  I tried to answer them the best I could but I sense you see some outstanding issues that need addressing.

When I have free time I will get back to your "block lattice" (originally "block list") thread, but I don't have time right now. Appears the issue will be something about having multiple partitions and prevention of double-spends globally and/or the ability to send a transaction to any block list at any time.

Multiple partitions don't come for free. You give up something. This is what I meant about the CAP theorem.

Multiple partitions is odd, RaiBlocks, like all cryptocurrencies doesn't operate while partitioned.  Please expand, you can be very specific when you find time.

[TPTB_need_war]

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/

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.

[clemahieu]

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.

Essentially the issue is long-term "nothing at stake".

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.

The only way around this is to rely on "weak subjectivitiy"

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.

[TPTB_need_war]

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 diarrhea 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

Byzantine fault
 Any fault presenting different symptoms to different observers
Byzantine failure
 The loss of a system service due to a Byzantine fault in systems that require consensus

Your understanding of Byzantine fault tolerance is incorrect. Per the definition above, Bitcoin delivers the same expectations (symptoms) for CAP (consistency, access, and partition tolerance) to all observers which are participants in the longest chain partition. The probability of a failure decreases probabilistically over time as the number of confirmations on the longest chain increases. There are degenerate cases such as the 51% attack where Byzantine failure occurs.

Note the double-spending on a minority chain is not a Byzantine failure, because by definition the minority chain is invalid.

There is no such thing as absolute anything in the universe, thus arguing that Byzantine fault tolerance is not universal is a vacuous assertion. Byzantine fault tolerance is defined for a system and the defined objectivity of the system, not for universal absolutism.

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

[clemahieu]

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)

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.

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.

No ad-hominem assertion has been made, I remarked that you don't know what you're talking about, not that the comment is incorrect because you as a person are making it.  This is an incorrect application of the ad-hominem logical fallacy.

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.

That's the question, I think you're actually technobabbling and don't have technical knowledge.  I think you've mined technical phrases and are repeating them, incorrectly.

https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

Byzantine fault
 Any fault presenting different symptoms to different observers
Byzantine failure
 The loss of a system service due to a Byzantine fault in systems that require consensus

Your understanding of Byzantine fault tolerance is incorrect. Per the definition above, Bitcoin delivers the same expectations (symptoms) for CAP (consistency, access, and partition tolerance) to all observers which are participants in the longest chain partition. The probability of a failure decreases probabilistically over time as the number of confirmations on the longest chain increases. There are degenerate cases such as the 51% attack where Byzantine failure occurs.

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.

Note the double-spending on a minority chain is not a Byzantine failure, because by definition the minority chain is invalid.

There is no such thing as absolute anything in the universe, thus arguing that Byzantine fault tolerance is not universal is a vacuous assertion. Byzantine fault tolerance is defined for a system and the defined objectivity of the system, not for universal absolutism.

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

Nothing ad-hominem about it, you're wrong because it's an incorrect conclusion, not because you're the person making it.  I'm sure you're capable of making a correct conclusion.

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.

I'm sure you'll have no problem writing up another post

[TPTB_need_war]

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

Observe the following guidelines for uses of double quotation marks other than in material quoted directly from a source.
to introduce a word or phrase used as an ironic comment, as slang, or as an invented or coined expression. Use quotation marks the first time the word or phrase is used

http://www.scribendi.com/advice/when_to_use_double_or_single_quotation_marks.en.html

n much specialist writing, including linguistics, philosophy, and theology, terms with particular meanings that are unique to that subject are often enclosed in single quotation mark

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.

[TPTB_need_war]

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 diarrhea 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

Byzantine fault
 Any fault presenting different symptoms to different observers
Byzantine failure
 The loss of a system service due to a Byzantine fault in systems that require consensus

Your understanding of Byzantine fault tolerance is incorrect. Per the definition above, Bitcoin delivers the same expectations (symptoms) for CAP (consistency, access, and partition tolerance) to all observers which are participants in the longest chain partition. The probability of a failure decreases probabilistically over time as the number of confirmations on the longest chain increases. There are degenerate cases such as the 51% attack where Byzantine failure occurs.

Note the double-spending on a minority chain is not a Byzantine failure, because by definition the minority chain is invalid.

There is no such thing as absolute anything in the universe, thus arguing that Byzantine fault tolerance is not universal is a vacuous assertion. Byzantine fault tolerance is defined for a system and the defined objectivity of the system, not for universal absolutism.

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

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.

[TPTB_need_war]

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.

[monsterer]

I'm afraid I largely agree with TPTB_need_war; without a voting history, I find it hard to see how there can be a reliable, unforgeable consensus for '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.

This is true in the real world because time travel is impossible.  Cryptocurrencies must strive to make time travel, voting on past history, or presenting fraudulent histories very hard, or the 'now' won't be reliable or consistent.

[clemahieu]

I'm afraid I largely agree with TPTB_need_war; without a voting history, I find it hard to see how there can be a reliable, unforgeable consensus for '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.

This is true in the real world because time travel is impossible.  Cryptocurrencies must strive to make time travel, voting on past history, or presenting fraudulent histories very hard, or the 'now' won't be reliable or consistent.

It seems like the analogous situation in bitcoin is being fed shorter block chains that were dropped.  When synchronizing we don't give shorter chains to people because it's irrelevant, we only give people the longest one a.k.a the contemporary state.

What would voting history give?  What if they only replay certain votes?  History is really unnecessary.

[monsterer]

It seems like the analogous situation in bitcoin is being fed shorter block chains that were dropped.  When synchronizing we don't give shorter chains to people because it's irrelevant, we only give people the longest one a.k.a the contemporary state.

What would voting history give?  What if they only replay certain votes?  History is really unnecessary.

In bitcoin you can give any node any set of chains - the node simply chooses the longest one; this is trustless and always consistent.

If you had voting history in raiblocks, at least the synchronizing client could make some kind of judgement based on several forks which it is presented with. As it stands, it has to ask other nodes which is correct, which is not a trustless operation and on top of that, said nodes must expend their own resources to re-vote on the historical forks (the DDOS angle, I've previously mentioned).

[clemahieu]

It seems like the analogous situation in bitcoin is being fed shorter block chains that were dropped.  When synchronizing we don't give shorter chains to people because it's irrelevant, we only give people the longest one a.k.a the contemporary state.

What would voting history give?  What if they only replay certain votes?  History is really unnecessary.

In bitcoin you can give any node any set of chains - the node simply chooses the longest one; this is trustless and always consistent.

If you had voting history in raiblocks, at least the synchronizing client could make some kind of judgement based on several forks which it is presented with. As it stands, it has to ask other nodes which is correct, which is not a trustless operation and on top of that, said nodes must expend their own resources to re-vote on the historical forks (the DDOS angle, I've previously mentioned).

Requesting a confirmation takes almost the same amount of resources as responding to one, I don't see a DDOS angle other than simple network flooding.

We also use stateless UDP rather than TCP so far fewer network resources are consumed.

I still don't see bitcoin as completely trustless, determining the highest block is trustless but you still need to trust where you got your wallet and that it's implementing the protocol correctly.  You also need a way to determine if you're connected to a partition, since there's no upper bound quarum on hashrate there's no trustless way to determine connectedness.  With voting you can observe if you've received a quarum and make that determination.

I guess it's an engineering tradeoff, do we want fast confirmations and unbounded global throughput at the expense of edge-case trust which I still find fairly impractical.