Latest Casper Basics. Tear it apart


#66

Understood :slight_smile: To play a bit more of Devil’s Advocate, guys with lots of money (large deposits) may be able to get in very late by bumping up gas payments. If my deposit is $1 zillion and my bounty is a percentage of the deposit I can afford to pay whatever it takes to get included in one of the last block before the epoch ends.
So ironically, validators with large deposits may end up doing less work and ripping most of the bounties, because they will be able to afford to be included in the last block.

More of Devil’s Advocate: nothing precludes validators from reaching agreements with large miners to have guaranteed inclusion in the last block. In this case, there may be a funny situation where a large portion of the votes will be in the last block :slight_smile:


#67

Casper test net

Casper test net

Can any one point to the source code for the Casper daemon that corresponds to the test net ?)))

P.S. Looks like here it is


#68

I have some questions,can anyone answer it for me? Thank you very much!
Q1: Mentioned in section 3,"Once validator ν leaves the validator set, the validator’s public key is forever forbidden from rejoining the validator set."As time goes on, the contents of this collection will grow to a lot. Then how to maintain this set of verifiers.
Q2: Mentioned in section 2.1,“if ≥ 23 of validators follow the protocol, then it’s always possible to finalize a new checkpoint without any validator violating a slashing condition.” Why is “without”.
Q3: Mentioned in section 2.1,“the inequality h(s1) < h(s2) < h(t2) < h(t1) cannot hold.” Then what about inequality h(s1) < h(s2) < h(t1) < h(t2)?


#69

On page 6, paragraph 3,what is " 'four months’ worth of blocks"


#70

Q1: Mentioned in section 3,"Once validator ν leaves the validator set, the validator’s public key is forever forbidden from rejoining the validator set."As time goes on, the contents of this collection will grow to a lot. Then how to maintain this set of verifiers.

Technically we don’t actually need this in the protocol; the issue is that if you withdraw and then re-deposit with the same public key, then the second-round deposit could get slashed for conflicts between messages made by the first-round deposit, or for inconsistencies between the two deposit rounds. It should be a client-side responsibility to make sure not to do this.

Mentioned in section 2.1,“if ≥ 23 of validators follow the protocol, then it’s always possible to finalize a new checkpoint without any validator violating a slashing condition.” Why is “without”.

Because if some validator has to violate a slashing condition to finalize a new checkpoint, the protocol is “stuck”, and can’t move forward without someone voluntarily sacrificing their own money.

Mentioned in section 2.1,“the inequality h(s1) < h(s2) < h(t2) < h(t1) cannot hold.” Then what about inequality h(s1) < h(s2) < h(t1) < h(t2)?

That’s okay. This intuitively means “At time t1, the best source checkpoint I was aware of is s1, but then at the later time t2, I became aware of a better source checkpoint at s2, so I switched to using it”. We expect this to be a very normal occurrence, at least in cases where the PoW blockchain is unstable enough that forks become an issue.