Update on Overleaf.

ccs-body.tex

@@ -332,12 +332,12 @@ The main idea of their solution is \emph{(i)} to  attach increasing weights $W_\
 The protocol described in Kiayias~\textit{et al.}~\cite{kiayias2021mining} holds for a static setting, that is for an environment in which the number of miners working for the construction of blocks is constant. Therefore PoWs are of fixed difficulty. 
 This is in contrast to the actual deployment of the Bitcoin blockchain where periodically, the difficulty is recalculated to cope with a variable and non predictable number of miners. 
 
-In this paper we propose for the first time an implementation of the NiPoPoW with chains of variable difficulty. This requires to solve the following challenges.
+In this paper we propose for the first time an implementation of the NIPoPoW with chains of variable difficulty. This requires to solve the following challenges.
 
 Firstly, the unstable part of the compressed chain (i.e., the $\chi$ part) cannot be a constant number of blocks long. Recall that in Kiayias~\textit{et al.}~\cite{kiayias2021mining}, $k$ represents this constant number of blocks. 
-Indeed, the unstable part must \textit{correspond to  sufficient work having been performed}~\cite{kiayias2021mining}, this "sufficient work" being represented by the current difficulty. A wrong assessment  of the length $k$  of the unstable part is highly undesirable.  First, an underestimation  of $k$ would be as detrimental for the security of the proof as the temporary presence of dishonest majority. Indeed, the adversary mining on top of the honest chain would first secretly append a block showing a manipulated snapshot (in favor of the adversary), then secretly would  append $k$ blocks with valid transactions to its own $k+1$-th block, and finally would compress its secret chain with the honest one. Presenting such a proof to a verifier would be convincing as  only the unstable part (i.e., the last $k$ blocks) are checked by the verifier~\cite{zindros2020decentralized}. Such an attack is successful either when the majority is dishonest (even temporary) or when the unstable part is not long enough, i.e., when $k$ is under-estimated. Now an over-estimation of $k$ would degrade the liveness property~\cite{zindros2020decentralized} ad the succinctness of the proof. 
+Indeed, the unstable part must \textit{correspond to  sufficient work having been performed}~\cite{kiayias2021mining}, this "sufficient work" being represented by the current difficulty. A wrong assessment of the length $k$ of the unstable part is highly undesirable.  First, an underestimation of $k$ would be as detrimental for the security of the proof as the temporary presence of dishonest majority. Indeed, the adversary mining on top of the honest chain would first secretly append a block showing a manipulated snapshot (in favor of the adversary), then secretly would append $k$ blocks with valid transactions to its own $k+1$-th block, and finally would compress its secret chain with the honest one. Presenting such a proof to a verifier would be convincing as only the unstable part (i.e., the last $k$ blocks) are checked by the verifier~\cite{zindros2020decentralized}. Such an attack is successful either when the majority is dishonest (even temporary) or when the unstable part is not long enough, i.e., when $k$ is under-estimated. Now an over-estimation of $k$ would degrade the liveness property~\cite{zindros2020decentralized} and the succinctness of the proof. 
 
-Consequently, a correct estimation of $k$ is necessary for the coThus The verifier must then first measure the mining power of the network before comparing proofs.
+Consequently, a correct estimation of $k$ is necessary for the correctness of the proof. 
 
 Another problem arising in the variable difficulty setting is that superblocks are only based on relative difficulties.
 In other words, superblocks only count the number of leading zeroes, and do not take into account the absolute difficulty of the block.