Adjust Protocol Update generators to honour extended voting period

IntersectMBO · Mar 17, 2020 · 0e72f19 · 0e72f19
1 parent b7a5402
commit 0e72f19
Show file tree

Hide file tree

Showing 2 changed files with 3 additions and 3 deletions.
diff --git a/shelley/chain-and-ledger/executable-spec/test/Test/Shelley/Spec/Ledger/Generator/Core.hs b/shelley/chain-and-ledger/executable-spec/test/Test/Shelley/Spec/Ledger/Generator/Core.hs
@@ -434,12 +434,12 @@ getKESPeriodRenewalNo keys (KESPeriod kp) =
           then n
           else go rest (n + 1) k
 
--- | True if the given slot is within the last `slotsPrior`
+-- | True if the given slot is within the last `2 * slotsPrior`
 -- slots of the current epoch.
 tooLateInEpoch :: SlotNo -> Bool
 tooLateInEpoch s = runShelleyBase $ do
   ei <- asks epochInfo
   firstSlotNo <- epochInfoFirst ei (epochFromSlotNo s + 1)
   slotsPrior_ <- asks slotsPrior
 
-  return (s >= firstSlotNo *- Duration slotsPrior_)
+  return (s >= firstSlotNo *- Duration (2 * slotsPrior_))
diff --git a/shelley/chain-and-ledger/formal-spec/update.tex b/shelley/chain-and-ledger/formal-spec/update.tex
@@ -84,7 +84,7 @@ \subsection{Protocol Parameter Update Proposals}
 Protocol updates are only allowed up until ($2\cdot\SlotsPrior$)-many slots before the
 end of the epoch. The reason for this involves how we safely predict hard forks.
 Changing the protocol version can result in a hard fork, and we would like an
-entire stability period between when we know that an hard fork will neccessarily happen
+entire stability period between when we know that a hard fork will necessarily happen
 and when the current epoch ends.
 
 \begin{itemize}