From 8dac7580c666905aadc030f01f11e2a6aa842a3a Mon Sep 17 00:00:00 2001 From: Ignotus Peverell Date: Mon, 2 Jan 2017 14:56:58 -0800 Subject: [PATCH] Minor typos. --- doc/chainsync.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/chainsync.md b/doc/chainsync.md index 7edced9d4..f7246c5b8 100644 --- a/doc/chainsync.md +++ b/doc/chainsync.md @@ -68,11 +68,11 @@ With this information it can verify: Once the validation done, the peer can download and validate the blocks content from the horizon up to the head. -While this algorithm still works for very low values of Z (or in the extreme case +While this algorithm still works for very low values of `Z` (or in the extreme case where `Z=1`), low values may be problematic due to the normal forking activity that can occur on any blockchain. To prevent those problems and to increase the amount -of locally validated work, we recommend values of H of at least a few days worth of -blocks, up to a few weeks. +of locally validated work, we recommend values of `Z` of at least a few days worth +of blocks, up to a few weeks. ### What could go wrong? @@ -117,14 +117,14 @@ capabilities (a bitmask of features a peer exposes) on connection. ### Several nodes continuously give fake horizon blocks -If a peer can't reach consensus on the header at H, it gradually moves back. In the +If a peer can't reach consensus on the header at h, it gradually moves back. In the degenerate case, rogue peers could force all new peers to always become full nodes (move back until genesis) by systematically preventing consensus and feeding fake headers. While this is a valid issue, several mitigation strategies exist: -* Peers must still provide valid block headers at horizon `H`. This includes the +* Peers must still provide valid block headers at horizon `Z`. This includes the proof of work. * A group of block headers around the horizon could be asked to increase the cost of the attack.