Well
they banned me because they don't want to hear the truth that
bonded validators can't ever work (not in Casper, Tendermint, Cosmos, or any other).
Any way, here is what I was going to post there next:
and added the ability to attribute blame to 1/3+ in the case of double spend forks, no matter the % of Byzantine voting power.
And that is your error as I have stated twice already. You can't assign blame in Byzantine agreement. Study it fundamentally, then will realize your mistake. Reading my whitepaper will provide the necessary understanding of the error in what you added.
P.S. What is this with open source projects banning those who want to report fatal flaws? Censorship is the antithesis of open source.
You can't possibly know wether or not casper is flawed
Yes I can. It is a fundamental taxonomy of possible workarounds to the FLP impossibility result. Read my whitepaper when it is released (although I don't think you will understand it but it is written to be comprehensible for those with reasonable analytical skills).
What @jaekwon (Cosmos/Tendermint) and others may not realize is that the fundamental limitations of Byzantine agreement can't be structured around with protocol. It is a fundamental limitation (due to physics of asynchrony). So they can obfuscate as much as they want with heapings of protocol complexity, so as to hide the fundamentals from themselves. But I understand
the essence of genius.
So Casper is hiding the bonding collateral in the notion of betting from collateral, but they won't escape from the fundamental limitation which is that blame can't be objective (it is always ambiguous) in Byzantine agreement. The only alternative to Byzantine agreement is probabilitistic, asymptotic (e.g. PoW and my design which is not PoW but something new). But probabilitistic, asymptotic can't assign blame to malfeasance either (for example you can't prove that Bitcoin miners are censoring transactions from blockchain data objectively, you need external social information which is not objective).
I will double-check my logic on this again when I do the comprehensive re-read of my paper. Will report back here, if I find any flaw in my analysis.
My opinion, if you really want to do something, anything, then you should join others. You have nobody to debate and you'll apply your knowledge and logic on what is already known
I engage others in debate as I did with @jaekwon but he just banned me and shut down the Github issue when he decided he didn't want to let me explain further how his project is broken and can't be fixed. He expect me to unravel the obfuscation they have done with protocol and that is not my job. I already understand the fundamental reason blame is impossible. It is their job to find out how they obfuscated this fundamental in their understanding of their design. Or later I can take the time to write or hire someone to write a formal refutation of their Proof of Accountability. Why should I encourage them to stop working on their project and wasting their time? Much better for me to have one less potential competitor and not to lose my precious time doing their work for them. At the right time, we can make it 100% proven that their projects are a total failure. And that will best done when my project is already released. Don't wake up a sleeping dog prematurely.
I decided to take a quick look at Tendermint/Cosmos's Proof of Accountability again:
Proof of Fork Accountability
...
As a corollary, when there is a fork, an external process can determine the blame by requiring each validator to justify all of its round votes. Either we will find 1/3+ who cannot justify at least one of their votes, and/or, we will find 1/3+ who had double-signed.
I explain in my whitepaper why their assumption above is incorrect. Here is the quote from my white paper:
1.2 Byzantine AgreementThe proof of the
non-asymptotic form of BFT is intuitive in the example scenario where every node is a voter and each candidate blockchain block is an election epoch. If every vote is correct, BFT only applies to faults which are unresponsive nodes; thus a quorum of only a majority of votes is required to obtain an unambiguous result because any ordering of blocks is always non-conflicting
(or equivalently if the coordination of voting is synchronized such that conflicting order can’t exist, but then BFT isn’t applicable per the * footnote of prior section). For example, if validators of transactions never vote for a conflicting transaction such as a double-spend, then given two attempted elections for a pair of consecutive blocks of transactions, the minimum number of voters which commit to both elections is
fₛ = 2T - N - 1, where
T is the minimum quorum size for each election. Thus
T ≥ (N + 1)/2 where
2T - N - 1 ≥ 0 because
0 safety is required given every vote is non-conflicting. But in the Byzantine agreement case wherein malevolent
† and/or asynchronous (i.e. caused by random, ambiguous propagation ordering) validators can vote for blocks that contain conflicting transactions, the minimum number of voters which
commit to both elections
fₛ = 2T - N - 1 must be greater than the number of excess voters not needed to form a quorum
fₗ = N - T, so that a quorum for a conflicting pair of blocks can’t exist because there aren’t enough
uncommitted voters to vote for it, i.e.
T ≥ N - fₛ.
[^Tendermint-safety] Thus
T ≥ (2N + 1)/3 where
2T - N - 1 ≥ N - T,
fₛ is the safety margin, and
fₗ is liveness.
[^BFT-derivation] This result which is mathematically equivalent to
N = 3f + 1 where
f = fₛ = fₗ, is analogous to the
N = 3m + 1 generals for
m traitors result for the Byzantine Generals Problem (aka “BGP”).
[^BGP]Liveness
fₗ in this context is the maximum number of unresponsive and/or malevolent nodes allowed for the system to not stall all quorums and/or censor for which blocks quorums are allowed. Safety margin
fₛ is the minimum number of voters which must commit to a pair of blocks to prevent
ambiguous ordering of blocks. Even if only a single election would ever be held for a set of signing keys which represent the voters, applies in any nonsynchronous (aka “asynchronous”) case when there isn’t trust of a designated centralized tally, because voters can irrefutably claim that an epoch expired and they signed a new vote for a new epoch. It is even irrefutable that a trusted centralized tally did not receive a vote.
[^he-said-she-said] [^ambiguous-fault]Some systems may opt for more safety margin at the detriment of reduced liveness by choosing a larger minimum quorum size
T.
[^BFT-derivation]Marbles in Jars ExampleThe proof in the Byzantine agreement case is easy to visualize with 3 voters who can each vote with marbles of one color representing their signing key: red, white, and blue. Given 3 jars representing ballot boxes for 3 elections on the consensus ordering of any two of them (wherein the jars could represent blockchain blocks), two marbles can be placed in each jar without any color voting more than twice― i.e. no voter has cheated yet the consensus is ambiguous. Declaring any of the jars as the first, results in two choices (aka “forks”) for which jar is the next. One jar has red and white, another red and blue, and another white and blue. This is why the proof requires that the excess of the quorum be less than
¹/₃ (aka “
-¹/₃”). So by adding a voter with green marbles so that smallest minority reduces from
¹/₃ to
¹/₄ which is thus
-¹/₃, the ambiguity is resolved because the green marble can only be placed in 2 of the 3 jars― again presuming no voter cheated to vote more than twice. Thus
+²/₃ instead of
¹/₂+ is required for quorums in the presence of possible malevolence (and/or honest ambiguity due to random propagation delays) given an asynchronous network, otherwise the ordering of the quorums can’t be proven.
Note if any 3 of the 4 marbles are colluding, i.e.
²/₃ or more (aka “
+²/₃”) of the voters are malevolent, they can vote for as many conflicting quorums (forks) as they wish and it will be ambiguous which of the 4 marbles is cheating, because given 3 sets of 3 jars, a different one of the 3 cheaters can vote in each set. And the honest voter has to vote on the fork which the quorum is extending, because otherwise not voting is indistinguishable from unresponsive. It can’t be irrefutably proven that the 3 malevolent marbles were cheating and colluding because they can each claim that other one became unresponsive; thus voting for more than two quorums became necessary. And the honest marble voted more than twice also. Propagation order and responsiveness can’t be proven nor disproven in an asynchronous network.
†
The adjectives “malevolent” or “attacking” applied to nodes means a colluding or centralized controlled group of nodes.
[^Tendermint-safety]
Jae Kwon, Ethan Buchman. Tendermint Wiki, Tendermint Github project, §Byzantine Consensus Algorithm: Proof of Safety, Jun 18, 2014.[^BFT-derivation]
David Mazieres. The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus. Stellar Development Foundation, §5.4.3. Comparison to centralized voting, Feb 25, 2016.[^BGP]
Leslie Lamport, Robert Shostak, and Marshall Pease. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, Vol. 4, No. 3, , pp. 382–401, July 1982. Mark Nelson. The Byzantine Generals Problem. Dr. Dobb’s (drdobbs.com), Mar 18, 2008.[^he-said-she-said]
Andreas Haeberlen, Petr Kuznetsov, and Peter Druschel. Practical Accountability for Distributed Systems. Proceedings of the 3rd Workshop on Future Directions in Distributed Computing (FuDiCo III), Bertinoro, Italy, §2.2 Proofs and verifiable evidence, p. 2, June 2007.[^ambiguous-fault]
Shelby Moore III, Unprovable accountability for network communication, Bitcointalk.org, “Transactions as Proof of Stake White Paper” thread, post #19, Dec 4, 2013.
