You’re right. This is a common source of confusion and could be made clearer in the paper. Even pointing out that it is a common source of confusion and should be noted!
and you don’t “look dumb”. there’s a lot going on in the paper and you clearly a groking it. Glad you came here to ask
Ok, so given the slashing conditions. Lets say all validators reveal their votes simultaneously. If finality must proceed by exactly 1, a reveal of 50/50 split of votes for Root -> C'1 and Root -> C"2 put the protocol in a state where no finality can proceed without an altruistic slash. Which means that proper game theory is to wait to establish a higher justified checkpoint as guidance. However, as voting for a justified checkpoint at any height puts you at risk of not being able to vote for the finality of that height (lest you violate the h(t1) == h(t2) slashing condition) you also cannot really vote in the blind there. It seems like being the first to reveal is far riskier than being the last to reveal and I am trying to figure out the mitigation for that so that game theory doesn't lead stake to stop casting votes out of fear or being put into a position where they must resign or be slashed.
the leap-frogging votes was what I thought was the path out of that pickle. But it was obviously not (and had other problems)
actually, now I'm really confused. Even a vote for a link whose h(t) - h(s) > 1 means you have to slash yourself to vote for the link that can be used for finality because that would be a different link with h(t) - h(s) == 1 but h(t) is the same between these votes which is a slash. I must be off the right path so, I'm going to hunker down, light a campfire and wait for help haha
Oh, crap. Ok. its that finality is not necessarily built on finality. Finality can skip several blocks as it is built on justified links with a specific form of link after it.
I think I'm square now.
<nagydani> Hi,
Maybe, it is worth posting it here as well. After pestering @Hsiao-Wei Wang (hwwhww) with stupid questions to fill in the gaps in my understanding how Serenity was going to get started, I decided to write it all up so that a) I do not forget b) others might have an easier time figuring it out. Feedback of any kind, very much including criticism is most welcome:
https://medium.com/@daniel_20027/ethereum-serenity-for-dummies-d21dce9c0487
Maybe, it is worth posting it here as well. After pestering @Hsiao-Wei Wang (hwwhww) with stupid questions to fill in the gaps in my understanding how Serenity was going to get started, I decided to write it all up so that a) I do not forget b) others might have an easier time figuring it out. Feedback of any kind, very much including criticism is most welcome:
https://medium.com/@daniel_20027/ethereum-serenity-for-dummies-d21dce9c0487
@liangdzou Another more recent piece of code is also available, which can be found here https://github.com/cbc-casper
@liangdzou you can refer to this for more casper resources: https://github.com/status-im/athenaeum/blob/master/ethereum_research_records.json#L265-L323
argh Friendly Ghost != FFG :/ so confused by the names
Hi! I'm quite new to Casper and i'm doing some FFG research now. May I ask is there a way for me to customise my casper contract if I use Harmony docker to run a testnet? let's say, I want to change the transaction rate or block percentage. Because so far from what I ran i realise a lot of things are pre-defined.
Thank you very much
<vbuterin> Are you running the pyethereum-based code from last year?
<vbuterin> If so that is outdated and no longer applies
<vbuterin> I recommend waiting 1-2 months then trying to run nodes from prysmatic, lighthouse and co
Hi guys. I wonder why the red box (evil validator is 1/3 ~ 1/2 under no 51% attack on pow) is fully safe. Isn't the box should be "Liveness failure"? It will be very helpful if you guys give any reference about it...
i don't have all the details but you could imagine doing some kind of range proof (a la Bulletproofs) against the bonded stake.... however for consensus safety you probably want to be able to track every behavior down to the wei and removing that knowledge could be dicey
- that is, the entire pool of bonded stakes, not just some individual validator's stake
Any signature (tied to stake) for a block including one of these transactions.. or a block building on top of a block that contains an 'illegal' transaction could be used as proof that the stake was used for nefarious activities.
yeah... defo something to think about
you have to balance accountability w/ zero-knowledge propety
*property
what prevents somebody running Casper
from not running a fullnode
and just sniffing and replaying other people's votes
to collect rewrds