3 ms·

> PoS consensus systems do allow for blockchains to be used to resolve consensus for future decisions I suppose you mean that someone (out of a group G) can co

> PoS consensus systems do allow for blockchains to be used to resolve consensus for future decisions I suppose you mean that someone (out of a group G) can commit an instruction saying "the future decision is Y" into the blockchain, and at some time later everyone will be convinced this is the future decision. This is not related to PoS, this will work for pretty much any system that supports smart contracts. In this situation the decision is not executed in a shared manner - even if one of G gets disconnected from the network, the decision still gets executed by the blockchain. So it is still different from the Two Generals Problem (as stated), where everyone in the group G must participate in executing the decision. So blockchains still don't solve the Two General Problem. Nor should this be a goal. I think the Two Generals Problem is stupidly strong and really unnecessary in the vast majority of real computing scenarios, including the blockchain. > Interesting - do you mind providing an exemplary paper or two? I'd like to read them. It's basically all of them, and I don't think many are worth reading so I don't remember the titles. Search for papers that try to solve the Sybil or Eclipse attacks. (Quite a lot of them rely on trusted authorities, these are not relevant here, I mean the other ones.)

dsacco 9y ago
> I suppose you mean that someone (out of a group G) can commit an instruction saying "the future decision is Y" into the blockchain, and at some time later everyone will be convinced this is the future decision. This is not related to PoS, this will work for pretty much any system that supports smart contracts. No, I specifically mean a voting protocol in which the "round" will not proceed ("the generals will not attack") unless all voters v in the voting set V come to consensus about the values t in the set of transactions T at the next block height ("the city to be attacked", "the time to attack", etc). Then the voting protocol asserts a proof of stake, such that Byzantine voters are penalized and honest/correct voters are rewarded. Then future decision resolution is provably guaranteed, so long as all activity remains deterministic, the cryptography is secure, all voters in the set V are online and active, and proof of stake is a plausible economic incentive. The caveat here is - pretty obviously - that it's possible for the consensus system to enter an infinite loop if it fails to reach consensus (just like the original problem). So no, it's not perfect, but it is modeling the Two Generals Problem and compartmentalizing it somewhat, though it can't completely resolve it. Otherwise, I agree with you - the classical Two Generals problem is an inordinate fault-tolerance ideal.
- infinity0 9y ago
  > [..] Then the voting protocol asserts a proof of stake, such that Byzantine voters are penalized and honest/correct voters are rewarded. How do you decide which one is a "Byzantine" voter? A minority is not necessarily dishonest. If you penalise a minority, at each step at most ceil(n/2-1) of the group will lose their stake, even if they were honest. That sounds overly-harsh.
  - schoen 9y ago
    I believe this is a terminological mistake. In the original formulation, all of the generals are "Byzantine" because they all work for the Byzantine Empire. In the original paper by Lamport, Shostak, and Pease, the problem is described this way: "We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action. However, some of the generals may be traitors, trying to prevent the loyal generals from reaching agreement." A common way to describe the participants in such a scenario is simply "honest" and "dishonest". The term "Byzantine" has become used in distributed systems research to refer to situations in which we can't be sure of participants' honesty and intentions. However, it doesn't correctly refer only to the dishonest participants.
    - infinity0 9y ago
      My point still stands - are you going to punish people simply because you're "not sure" of their honesty? That is what the parent post (to my previous post) was implying.
      - schoen 9y ago
        I didn't mean to question the substance of what you were saying; I was only thinking about the meaning of the term "Byzantine".

dsacco 9y ago

> I suppose you mean that someone (out of a group G) can commit an instruction saying "the future decision is Y" into the blockchain, and at some time later everyone will be convinced this is the future decision. This is not related to PoS, this will work for pretty much any system that supports smart contracts. No, I specifically mean a voting protocol in which the "round" will not proceed ("the generals will not attack") unless all voters v in the voting set V come to consensus about the values t in the set of transactions T at the next block height ("the city to be attacked", "the time to attack", etc). Then the voting protocol asserts a proof of stake, such that Byzantine voters are penalized and honest/correct voters are rewarded. Then future decision resolution is provably guaranteed, so long as all activity remains deterministic, the cryptography is secure, all voters in the set V are online and active, and proof of stake is a plausible economic incentive. The caveat here is - pretty obviously - that it's possible for the consensus system to enter an infinite loop if it fails to reach consensus (just like the original problem). So no, it's not perfect, but it is modeling the Two Generals Problem and compartmentalizing it somewhat, though it can't completely resolve it. Otherwise, I agree with you - the classical Two Generals problem is an inordinate fault-tolerance ideal.

infinity0 9y ago
> [..] Then the voting protocol asserts a proof of stake, such that Byzantine voters are penalized and honest/correct voters are rewarded. How do you decide which one is a "Byzantine" voter? A minority is not necessarily dishonest. If you penalise a minority, at each step at most ceil(n/2-1) of the group will lose their stake, even if they were honest. That sounds overly-harsh.
- schoen 9y ago
  I believe this is a terminological mistake. In the original formulation, all of the generals are "Byzantine" because they all work for the Byzantine Empire. In the original paper by Lamport, Shostak, and Pease, the problem is described this way: "We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action. However, some of the generals may be traitors, trying to prevent the loyal generals from reaching agreement." A common way to describe the participants in such a scenario is simply "honest" and "dishonest". The term "Byzantine" has become used in distributed systems research to refer to situations in which we can't be sure of participants' honesty and intentions. However, it doesn't correctly refer only to the dishonest participants.
  - infinity0 9y ago
    My point still stands - are you going to punish people simply because you're "not sure" of their honesty? That is what the parent post (to my previous post) was implying.
    - schoen 9y ago
      I didn't mean to question the substance of what you were saying; I was only thinking about the meaning of the term "Byzantine".