comment
Byzantine fault-tolerant consensus - Why 33% threshold
Also @qbt937 here is what Lamport's paper that you linked says: Now that we have introduced signed messages, our previous argument that four generals are required to cope with one traitor no longer holds. In fact, a three-general solution does exist. We now give an algorithm that copes with m traitors for any number of generals. (The problem is vacuous if there are fewer than m + 2 generals.)
comment
What are the downsides of proof of stake?
Funny you say that David: forbes.com/sites/carltonreid/2018/10/21/…
comment
What are the downsides of proof of stake?
But can’t it be trivially revealed that you voted for both, and then others in system would just stop listening to you, and therefore all the coins you staked would be frozen forever? One strike and you’re out.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
Also how do you explain this, then? trustnodes.com/2018/08/10/… ... Leslie Lamport proposed it actually.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
Maybe you are right, but please define "Byzantine agreement" rigorously so we can evaluate the claim. It seems that if n/3 < f < n/2 it can be solved at least with synchrony and digital signatures as you said. Beyond n/2 you can't know whether there was a netsplit and a larger consensus will override yours, so you can't make forward progress if malicious nodes fake a netsplit.
awarded
comment
Byzantine fault-tolerant consensus - Why 33% threshold
Download the SAFE Network and run it yourself, it is a working implementation. They solve many related problems, including transferring ownership of files and proving that they are still being stored without revealing their contents.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
It is achieved using a technique called Kademlia which is used in DHTs. The SAFE Network uses it in much the same way as we do: each token has a group of the closest N computers in XOR space to watch it. But there are other ways to do it as well. That consensus is not global, not all nodes know every output.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
By the same token you can ask, how do I know the nodes that arrived at a consensus are the whole network and not a small subnetwork of a much larger one which will eventually reach a conflicting consensus? This is more about the step prior to consensus - namely selection of the set of nodes that will matter in the first place, for token T or transaction X. For us we use Kademlia but a naive implementation would just be to list the IP addresses of the nodes directly in the token history itself. Either way you need to have this list. Ripple has the UNL.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
Both sides of what? There is only disproof. There is no voting. If malicious nodes SAY two different things then the other nodes GOSSIP that and proceed accordingly! For example if a malicious or not malicious node actually showed a fork then it doesn’t matter that it also said there was no fork to someone else. EVEN ONE node can prove there was a fork!
comment
Byzantine fault-tolerant consensus - Why 33% threshold
Ideally, people should all learn about falsification of claims they care about, and make up their own minds who to believe. That’s how people reliably arrive at the truth. Having a Ministry of Truth — whether made up of PoW, PoS or representatives etc. — creates an attractive honeypot for hacking. It’s also much more centralized. But in this stackoverflow question my main point is just that there is a way to do BFT consensus in the face of MORE than 33% malicious nodes.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
Okay @DavidSchwartz I have updated our article on Consensus here, as promised: forum.intercoin.org/t/intercoin-technology-consensus/80 . I took the time to describe it in much more detail, and also compare it to other systems including XRP Consensus Process. Please take your time to understand the system it's describing, and I'd be happy to see what you have to say. You can make an account easily on that forum, and post your review as a comment there, because it probably doesn't belong on stackoverflow.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
OK I will write it up on our forum and link you to it. Then you can comment there (easier and probably more appropriate than here).
comment
Byzantine fault-tolerant consensus - Why 33% threshold
It seems to me that you didn’t understand my answer which makes me suspect there is some misunderstanding. I believe it js that in your conception the consensus is always global about all transactions in a block, and in mine it’s about each token. The sender may be dishonest but they’d only be hurting themselves by paying twice for the same goods. Let me make it simple: you pull out a credit card and the transaction stalls for an hour. So you pull out another credit card and it goes through. When the first credit card transaction completes successfully you don’t endorse it or dispute it.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
I just addressed that above. Let them refuse to reach a quorum. The sender A simply issues another transaction to ANOTHER consensus group and endorses whichever group reaches a consensus first, ignoring the other. So yes one consensus group makes no forward progress... and so what?
comment
Byzantine fault-tolerant consensus - Why 33% threshold
Why can’t the quorum be more than 66%? That is the whole point. If the group makes no forward progress, the sender simply issues another transaction to another group, and endorses whichever group does reach a consensus first. If the other group ever does reach a consensus also, it is dropped by the sender. The 33% nodes may be simply netsplit and not malicious. Re-read what I originally wrote in my second comment on this thread.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
It doesn’t matter if someone releases conflicting signatures. B waits for a supermajority of the validators for token T to SIGN a statement saying they didn’t see a double-spend, then A endorses the transfer. As long as the majority of the honest nodes have signed the statement, they won’t change it later, and even if they do, B can produce the statement they signed contradicting themselves. The whole point is that there can be more than 33% dishonest nodes and it will still work.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
The key why any of this works is because in crypto-currency, the recipients are ultimately the final arbiters of what consensus result they consider untainted (valid and unforked history). Every time A pays B, B is ultimately either going to accept the payment, or not. They can take their sweet time looking for claims of violation and forks and investigate them all. The goal is to simply build aledger that maximizes the probability of surfacing this information.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
If there is a split of honest validators in a consensus group, then at least one of the subgroups after the split won’t be able to achieve a supermajority, and the one that does sign a supermajority (assuming there is one) needs only ONE honest validator to detect that a dishonest validator has given (and signed) two different answers for the whole thing to be rejected by any self-interested recipient.
comment
Byzantine fault-tolerant consensus - Why 33% threshold
No, we simply have the sender of the transaction make a final endorsement before it is posted to the ledger, but after it is signed by a supermajority of validators. If the supermajority is not reached before a timeout (e.g. because of a netsplit) the sender can just submit the transaction to a different group of validators (we implemented sharding by transaction) so maybe that group will come to a consensus first. The sender then simply endorses one approved transaction and ignores the other. This is only possible because the sender has ultimate say over if they want to send something.