Post a PDF of the latest version in the header before the original version, so that people will comment on that and avoid doubling up on the same feedback.
Sorry I can’t make any more comments or tag any more people.
Grammar and readability edits
Please have the font in Arial or some other Sans Serif font.
Use CTRL+F to find the text that I’m quoting.
"when we say “2/3 of validators”, we are referring to the deposit-weighted fraction; that is, a set of validators whose sum deposit size equals to 2/3 of the total deposit size of the entire set of validators.” Maybe to avoid ambiguity have an acronym, e.g. validators with 2/3 of the total deposit size (VaTTTDS, pronounced vat dees).
The most notable property of Casper is that it is impossible for two conflicting checkpoints to be finalized without >1/3 of the validators violating one of the two Casper Commandments/slashing conditions."
…it is impossible for both of two conflicting checkpoints to be finalized unless >1/3 of the validators (by weight) violate one of…
think “four months’ worth of blocks”
should be four months worth of blocks. I don’t think you need the quotation marks. It doesn’t need “think”. Be decisive or say probably four months…
@chris-remus, “recursively justifying” should be defined as it is in the last bullet point of p. 2. However if this document uses usepackage{hyperref} then you can use \hypertarget{recursivelyjustify}{} in a line before the last bullet point of p. 2 (e.g. as below), then use \hyperlink{recursivelyjustify}{recursively justifying}.
188. \hypertarget{recursivelyjustify}{}
189. \item A checkpoint $c$ is called \emph{justified} if (1) it is the root, or (2) there exists a supermajority link $c^\prime \to c$ where $c^\prime$ is justified. \figref{fig:2c} shows a chain of four justified blocks.
314. Before, a checkpoint $c$ is called \emph{finalized} if it is justified and there is a supermajority link from $c$ to any of its direct children in the checkpoint tree. Finalization now has one additional condition---$c$ is finalized only if the votes for the supermajority link $c \rightarrow c^\prime$, as well as all of the supermajority links \hyperlink{recursivelyjustify}{recursively justifying} $c$, are included in the block chain before the child of $c^\prime$, i.e., before block number $\h(c^\prime) * 100$.
Yes I agree to have a different notation to \upnu for a validator set, a capital italic letter as used here.
Note this means that the forward validator set of dynasty d is the rear validator set of dynasty d + 1.
It’s probably better to spell this out for readability, i.e.:
\begin{align*}
\mathcal{V}_{\operatorname{r}}(d+1) &\equiv \left\{ \upnu : \DS(\upnu) < d + 1 \leq \DE(\upnu) \right\} \\
\equiv \left\{ \upnu : \DS(\upnu) \leq d < \DE(\upnu) \right\}
\equiv \mathcal{V}_{\operatorname{f}}(d)
\end{align*}
There is repetition of two sentences:
We add the condition that c is finalized only if the votes for the supermajority link c → c′, as well as the supermajority link justifying c, are included in c′’s block chain and before the child of c′—i.e., before block number h(c′) * 100. Isn’t the last phrase “and before the child of c′—i.e., before block number h(c′) * 100” repeating the previous condition, since including these votes in c′ implies that the votes will be included before the child of c′.
We assume all clients have local clocks are perfectly synchronized (any discrepancy can be treated asbeing part of the communication delay).
We assume that all clients have local clocks that are perfectly synchronized (any discrepancy can be treated as being part of the communication delay \delta).
@hwwhww
Could you clarify the difference between ω ≥ 4δ and ω > 4δ?
Yes I also had to stop and reflect about that, so a clarification would be good. For the case where ω ≥ 4δ, my understanding is that the validator can withdraw the deposit at that point in time, but they will have no time to launch a successful attack after that as it will be ignored by clients, since ω > 4δ.
If anyone knows how to use strikethrough in these comments, please let me know how.
If a validator sees a slashing violation at time t (that’s the time they hear the later of the two votes),
Which two votes? In a validator’s vote, there is a vote for the source and target checkpoints as their hash and height. So I’m assuming this means that the time of the target checkpoint. Perhaps this should be clarified, e.g.:
If a validator sees a slashing violation at time t (that’s the time they hear the later of the two votes, i.e. the timestamp of the target checkpoint)
Suppose that a large set of slashing violations results in results in two conflicting finalized checkpoints
Suppose that a large set of slashing violations results in two conflicting finalized checkpoints
whose chains that have not yet included the evidence transaction
whose chains have not yet included the evidence transaction
slashing evidence was submitted into a given chain “on time” or submittedand another chain as having accepted it too late
submitted and
I’m not sure what “another chain as having accepted it too late” is meant to mean, however maybe it could be rewritten as “submitted into a chain and then having accepted it too late at the time of another chain”.
In figure 5:
After withdrawal, attack fabricates a conflicting chain
After withdrawal, the attacker(s) (the supermajority validators) fabricates a conflicting chain
because the communityvalidators
because the community validators
thus stopping the attack and removingslashing the attacker.
thus stopping the attack and removing/slashing the attacker supermajority.
PoS is because if the validators are split into two subsets
PoS is valid because…
(however, every validator will lose a large portion of their deposit on one of the two chains due to leaks. If this situation happens, then each validator should simply favor whatever finalized checkpoint it saw first.
(however, every validator will lose a large portion of their deposit on one of the two chains due to leaks. If this situation happens, then each validator should simply favor whatever finalized checkpoint it saw first.)
can detect obviously malfesant behavior
malfeasant
Casper is an PoS-based
Casper is a PoS-based
[6] Bitcoin: A peer-to-peer electronic cash systems
system
Change/add to the following bib refs like so (I can only post at most two links):
As for security and performance, no feedback has come to mind yet, other than:
I look forward to future developments and shall be happy to actively work on such developments.
I guess that further research for other possible attacks and seeking out a security consultant would be good.
