Convert all TODOs into tickets and link to them.

src/introduction/trailing-finality-layer-in-a-nutshell.md

@@ -2,7 +2,7 @@
 
 The hybrid PoW/PoS protocol proposed in this book is similar to today's Zcash NU5 protocol with the addition of a *Trailing Finality Layer*:
 
-**TODO**: Add graphic showing nodes connected to each other in the p2p protocol. Each node has two parts: PoW and TFL. Each part has a distinct connection to the neighbors of the same part, so node A's "PoW" connects to node B's "PoW", node A's "TFL" connects to node B's "TFL". Finally, we want some way to visualize that all of the PoW nodes and connections were "pre-existing" and that the TFL pieces are a "new layer".
+**TODO:** [Add network topology / software subcomponent diagram #124](https://github.com/Electric-Coin-Company/tfl-book/issues/124)
 
 The Zcash Trailing Finality Layer refers to a new subprotocol of a new hybrid PoW/PoS protocol, which we refer to as *PoW+TFL*. This subprotocol introduces [assured finality](../terminology.md#definition-assured-finality) for the Zcash blockchain, ensuring that *final* blocks (and the transactions within them) may never be rolled back.
 

src/overview/design-at-a-glance.md

@@ -2,7 +2,7 @@
 
 The [PoW+TFL](../terminology.md#definition-pow-tfl) consensus protocol is logically an extension of the Zcash consensus rules to introduce [trailing finality](../terminology.md#definition-trailing-finality). This is achieved by compartmentalizing the top-level PoW+TFL protocol into two [consensus subprotocols](../terminology.md#definition-consensus-subprotocols), one embodying most of the current consensus logic of Zcash and another the TFL. These protocols interact through a [hybrid construction](../terminology.md#definition-hybrid-construction), which specifies how the protocols interact, and what changes from "off-the-shelf" behavior, if any, need to be imposed on the subprotocols. Each of these components (the two subprotocols and the hybrid construction) are somewhat modular: different subprotocols or hybrid constructions may be combined (with some modification) to produce a candidate [PoW+TFL](../terminology.md#definition-pow-tfl) protocol.
 
-**TODO:** Add consensus subprotocol diagram.
+**TODO:** [Add a protocol component diagram to "Design at a Glance" #122](https://github.com/Electric-Coin-Company/tfl-book/issues/122)
 
 ## Hybrid Construction
 
@@ -14,7 +14,7 @@ The [hybrid construction](../terminology.md#definition-hybrid-construction) is a
 
 Currently we believe [Crosslink](../terminology.md#definition-crosslink) is the best candidate, due to security considerations.
 
-**TODO:** Clarify the security considerations at a high level.
+**TODO:** [Explain why we're more confident in Crosslink security vs the other hybrid construction candidates #123](https://github.com/Electric-Coin-Company/tfl-book/issues/123)
 
 ## Subprotocols
 
@@ -23,9 +23,6 @@ The PoW+TFL hybrid consensus consists of two interacting subprotocols:
 1. [PoW Subprotocol](../terminology.md#definition-pow): this subprotocol is very similar to NU5 consensus. It is a design goal of the TFL design to minimize changes to this subprotocol. Note: the shorthand "PoW" is potentially misleading, because this subprotocol is also responsible for the bulk of all supply and transaction semantic consensus rules.
 2. [PoS Subprotocol](../terminology.md#definition-pos): this is a new subprotocol which provides trailing finality via a finalizing PoS protocol.
 
-**TODO:** Find a more precise name for the PoW subprotocol, because this subprotocol is responsible for:
-- Proof-of-Work proving/validation (unmodified)
-- Nakamoto Best-chain Fork Choice rule (potentially modified by the [hybrid construction](../terminology.md#definition-hybrid-construction))
-- Transaction Validity Rules (with a [transaction context](../terminology.md#definition-hybrid-construction) potentially modified by [hybrid construction](../terminology.md#definition-hybrid-construction))
+**TODO:** [Clarify the distinctions between pure PoW, the PoW subprotocol, NU5, and fork-choice vs all of transaction semantics. #119](https://github.com/Electric-Coin-Company/tfl-book/issues/119)
 
 Note that the [hybrid construction](../terminology.md#definition-hybrid-construction) may require modification to the "off-the-shelf" versions of these subprotocols. In particular [Crosslink](../terminology.md#definition-crosslink) requires each protocol to refer to the state of the other to provide [objective validity](../terminology.md#definition-objective-validity).

src/overview/design-goals.md

@@ -35,7 +35,9 @@ Zcash has always had exemplary safety, security, and privacy, and we aim to cont
 - For any hybrid PoW/PoS protocol (including PoW+TFL), the cost-of-attack for a 1-hour rollback should not be reduced, given a “reasonably rigorous” security argument.
 - For any hybrid PoW/PoS protocol (including PoW+TFL), the cost-of-attack to halt the chain should be larger than the 24 hour revenue of PoW mining rewards, given a “reasonably rigorous” security argument.
 
-TODO: privacy, pure-PoS security goals.
+**TODO:** [Define privacy goals of TFL #118](https://github.com/Electric-Coin-Company/tfl-book/issues/118)
+
+**TODO:** [Define PoS Subprotocol desiderata which are distinct from Crosslink integration #117](https://github.com/Electric-Coin-Company/tfl-book/issues/117)
 
 ## Design Conservatism Goals
 

src/terminology.md

@@ -22,7 +22,7 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran
 
 <span id="definition-hybrid-construction"></span>**Hybrid Construction**: The design component of a [hybrid consensus](#defintion-hybrid-consensus) which specifies how to integrate [subprotocols](#definition-consensus-subprotocols) and what modifications, if any, those subprotocols need to be safely integrated. Examples include [Crosslink](#definition-crosslink) and [Snap-and-Chat](#definition-snap-and-chat).
 
-<span id="definition-liveness"></span>**Liveness**: The property of a distributed protocol which ensures that the protocol may progress provided liveness requirements are met. **TODO:** Fix this definition, which begs the question by failing to define "progress".
+<span id="definition-liveness"></span>**Liveness**: The property of a distributed protocol which ensures that the protocol may progress provided liveness requirements are met. **TODO:** [Fix the definition of Liveness #120](https://github.com/Electric-Coin-Company/tfl-book/issues/120)
 
 <span id="definition-nu5"></span>**NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors]
 
@@ -34,7 +34,7 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran
 
 <span id="definition-pow-tfl"></span>**PoW+TFL**: the overall complete, integrated consensus protocol specified in this book.
 
-<span id="definition-safety"></span>**Safety**: The property of a distributed protocol that guarantees a participant may safely rely on a consistent local state, provided safety requirements are met. **TODO:** Fix this definition.
+<span id="definition-safety"></span>**Safety**: The property of a distributed protocol that guarantees a participant may safely rely on a consistent local state, provided safety requirements are met. **TODO:** [Provide a rigorous definition of Safety #121](https://github.com/Electric-Coin-Company/tfl-book/issues/121)
 
 <span id="definition-simtfl"></span>**`simtfl`**: a protocol simulator for analyzing [TFL](#definition-tfl) security and abstract performance. Development lives at <https://github.com/zcash/simtfl></span>. See [Status and Next Steps: Current Components](./introduction/status-and-next-steps.md#current-components) for current status.
 
@@ -46,7 +46,7 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran
 
 <span id="definition-zip"></span>**ZIP**: a Zcash Improvement Proposal is the protocol development process the Zcash community uses to safely define potential protocol improvements. See <https://zips.z.cash></span>.
 
-*TODO*: Clarify the distinctions between PoW (general consensus), [NU5](#definition-nu5) which includes transaction semantics, and the PoW component of [PoW-TFL](#definition-pow-tfl). These distinctions deserve unique terms.
+**TODO:** [Clarify the distinctions between pure PoW, the PoW subprotocol, NU5, and fork-choice vs all of transaction semantics. #119](https://github.com/Electric-Coin-Company/tfl-book/issues/119)
 
 # Footnotes