Update report/src/sections/07-discussion.tex

Co-authored-by: Anders Malta <74375517+Maltesius@users.noreply.github.com>

Author: ironmand123

report/src/sections/07-discussion.tex

@@ -42,7 +42,7 @@ \subsection{Shuffle Security}\label{subsec:Discution-Shuffle-security}
 
 We would however not recommend using an~$\ell$ lower than 80, as here the worst case scenario needs a little under half the available shuffles to be honest in order to be secure.
 As seen in~\autoref{fig:shufflesecurity} you would also only need a third of the 8192 shuffles to be honest to get within the one standard deviation.
-This would still lead to a reduction of the proving time of 62.69ms, which is 74.25\% of the current time and a reduction in the verifying time of 0.89ms, which is 96.11\% of the current time.
+This would still lead to a reduction of the proving time of 62.69ms, which is 74.25\% of the current Curdleproofs time and a reduction in the verifying time of 0.89ms, which is 96.11\% of the current Curdleproofs time.
 It would also reduce the size of the block overhead from 16.656KB to 12.048KB.
 Some other things to keep in mind when deciding on how many honest shuffles should be necessary to make the shuffle secure is that there are other factors that can affect the security of the blockchain.
 One of such factors is some of the know attacks that takes advantage of controlling a large number of validators.