5 ms·

Sure, the addresses for the validators should be reused. The more it's used the better. >> Is this a problem that isn't present in Bitcoin? How can a brand ne

by jaekwon 12y ago

Sure, the addresses for the validators should be reused. The more it's used the better. >> Is this a problem that isn't present in Bitcoin? How can a brand new Bitcoin user securely join the network for the first time? > It worries me that you can't answer this and you're working on a cryptocurrency. I'm not asking because I don't know the answer. (I know the answer.) I'm asking because your answer will help me clarify the answer for you using the framework and terminology that you're comfortable with. And in this space, each term means different things in different contexts. :) It's not trivial for a traitor to pretend to be all of the generals. Say there are validators A, B, C, D, and they have equal voting power. Given this configuration, it's impossible for A to be the proposer for 2 blocks in a row unless some of the other validators were absent. It's not just deterministic -- it's round-robin.

lappa 12y ago
>Sure, the addresses for the validators should be reused. The more it's used the better. That's not at all what I said, but this is besides the point. >t's not trivial for a traitor to pretend to be all of the generals. Say there are validators A, B, C, D, and they have equal voting power. Given this configuration, it's impossible for A to be the proposer for 2 blocks in a row unless some of the other validators were absent. It's not just deterministic -- it's round-robin. And you whitepaper allows for block creation with absent validators which makes it trivial because you have total control over the seed determining the next set of valdators. Even if you changed that, it would be trivial because you would only need to have last input into the seed one time to grind and generate a signature such that you are the exclusive validator. You continue to assert the attack isn't feasible, but you aren't actually paying attention to what the reason I have told you twice now. "It's not [feasible] for a traitor to pretend to be all the generals <no explanation>, say there are [arbitrary example]. Given this configuration it's infeasible for the attack to be performed <no explanation>. <Repetition of facts that are part of the reason stake grinding works including it's determininsticness>." If you aren't aware of what stake grinding allows, it is an attack where you calculate the deterministic results of many many signatures (seeds) and finds signatures that result in you winning, allowing you to perform the attack once again.
- jaekwon 12y ago
  > control over the seed determining the next set of validators That notion makes sense in something like PeerCoin or other preexisting PoS designs, but I don't see how that phrase applies to Tendermint. There is no "sampling" -- all validators must sign every block.
  - vbuterin 12y ago
    I think you underemphasize this point. My Slasher algo ( https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/ https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proo... ) from way back then does use sampling; Tendermint does not, and thus gains a whole bunch of robustness properties at some cost to efficiency.
  - lappa 12y ago
    >all validators must sign every block. Well now you're defining a new system. You can't expect me to explain the security of an undefined system, so I am sticking to the system defined in your paper which states that not all validators need to sign every block.
    - jaekwon 12y ago
      The whitepaper says that +2/3 of the entire validator set (in voting power) must sign every block. In the ideal scenario (in other words, in the stable state) every validator does sign every block.
      - lappa 12y ago
        Yes, it is pointless for me to argue about an undefined system. If you mean to say that 67% of the validator set must sign every block, then you shouldn't argue with the premise that 100% must sign every block.
        jaekwon 12y ago
        It would be interesting to see a more well defined attack from you.

by jaekwon 12y ago

lappa 12y ago

>Sure, the addresses for the validators should be reused. The more it's used the better. That's not at all what I said, but this is besides the point. >t's not trivial for a traitor to pretend to be all of the generals. Say there are validators A, B, C, D, and they have equal voting power. Given this configuration, it's impossible for A to be the proposer for 2 blocks in a row unless some of the other validators were absent. It's not just deterministic -- it's round-robin. And you whitepaper allows for block creation with absent validators which makes it trivial because you have total control over the seed determining the next set of valdators. Even if you changed that, it would be trivial because you would only need to have last input into the seed one time to grind and generate a signature such that you are the exclusive validator. You continue to assert the attack isn't feasible, but you aren't actually paying attention to what the reason I have told you twice now. "It's not [feasible] for a traitor to pretend to be all the generals <no explanation>, say there are [arbitrary example]. Given this configuration it's infeasible for the attack to be performed <no explanation>. <Repetition of facts that are part of the reason stake grinding works including it's determininsticness>." If you aren't aware of what stake grinding allows, it is an attack where you calculate the deterministic results of many many signatures (seeds) and finds signatures that result in you winning, allowing you to perform the attack once again.

jaekwon 12y ago
> control over the seed determining the next set of validators That notion makes sense in something like PeerCoin or other preexisting PoS designs, but I don't see how that phrase applies to Tendermint. There is no "sampling" -- all validators must sign every block.
- vbuterin 12y ago
  I think you underemphasize this point. My Slasher algo ( https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/ https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proo... ) from way back then does use sampling; Tendermint does not, and thus gains a whole bunch of robustness properties at some cost to efficiency.
- lappa 12y ago
  >all validators must sign every block. Well now you're defining a new system. You can't expect me to explain the security of an undefined system, so I am sticking to the system defined in your paper which states that not all validators need to sign every block.
  - jaekwon 12y ago
    The whitepaper says that +2/3 of the entire validator set (in voting power) must sign every block. In the ideal scenario (in other words, in the stable state) every validator does sign every block.
    - lappa 12y ago
      Yes, it is pointless for me to argue about an undefined system. If you mean to say that 67% of the validator set must sign every block, then you shouldn't argue with the premise that 100% must sign every block.
      - jaekwon 12y ago
        It would be interesting to see a more well defined attack from you.