diff --git a/README.md b/README.md
index dd80f7b678def4c84884397a75aa49e0af0af9f6..1fe3913994d3cc1a75d2c6a04824e5bc44a175f8 100644
--- a/README.md
+++ b/README.md
@@ -60,14 +60,17 @@ Currently the only way to stop a runaway `testingX` is through killing it throug
 
 ### Your Tasks
 
-Your task is to finish a few of the unfinished pieces in the two files (10
-points for each). Search for **TO BE IMPLEMENTED** in `transactions.py`
+Your task is to finish a few of the unfinished pieces  in `transactions.py` (search for
+**TO BE IMPLEMENTED**). 
 
 * [10 points] Implementing IX Locks in `transactions.py`: Currently the code supports S, X, and IS locks. So if a transaction needs to lock a tuple in the X mode, the entire relation 
 is locked. This
 is of course not ideal and we would prefer to use IX locks (on the relation) to speed up concurrency. The code for this will largely mirror the code for IS. You will 
 have to change the `getXLockTuple()` function and also the `compatibility_list` appropriately. 
-* [20 points] Function `restartRecovery()` in `transaction.py`: This function is called if the log file indicates an inconsistency (i.e., if the logfile does not end with an empty CHECKPOINT record). If that's the case, then you must analyze the logfile and do a recovery on that.
+* [20 points] Function `restartRecovery()` in `transaction.py`: This function is called if
+  the log file indicates an inconsistency (i.e., if the logfile does not end with an empty
+  CHECKPOINT record). If that's the case, then you must analyze the logfile and do a
+  recovery on that (see 16.4.2 for details).
 
 For the recovery, you will need to write the code for both `revertChanges` and `restartRecovery`. `revertChanges` works by writing a compensating log
 record (CLR) for each update that a failed transaction does, in the correct