joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 17:56:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update guide_operating_modes.md

Browse source
This commit is contained in:
Jameson Lopp 2016-10-15 12:52:06 -04:00 • committed by GitHub
parent 62e8b63c5e
commit 6cb4bef567
1 changed files with 1 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
_includes/devdoc/guide_operating_modes.md
View file

@ -20,7 +20,7 @@ Currently there are two primary methods of validating the block chain as a clien
The first and most secure model is the one followed by Bitcoin Core, also known as a “thick” or “full chain” client. This security model assures the validity of the block chain by downloading and validating blocks from the genesis block all the way to the most recently discovered block. This is known as using the *height* of a particular block to verify the client’s view of the network. The first and most secure model is the one followed by Bitcoin Core, also known as a “thick” or “full chain” client. This security model assures the validity of the block chain by downloading and validating blocks from the genesis block all the way to the most recently discovered block. This is known as using the *height* of a particular block to verify the client’s view of the network.
For a client to be fooled, an adversary would need to give a complete alternative block chain history that is of greater difficulty than the current “true” chain, which is computationally expensive (if not impossible) due to the fact that the chain with the most cumulative proof of work is by definition the "true" chain. Due to the computational difficulty required to generate a new block at the tip of the chain, the ability to fool a full node become intractable after 6 confirmations. This form of verification is highly resistent to sybil attacks - only a single honest network peer is required in order to receive and verify the complete state of the "true" block chain. For a client to be fooled, an adversary would need to give a complete alternative block chain history that is of greater difficulty than the current “true” chain, which is computationally expensive (if not impossible) due to the fact that the chain with the most cumulative proof of work is by definition the "true" chain. Due to the computational difficulty required to generate a new block at the tip of the chain, the ability to fool a full node becomes intractable after 6 confirmations. This form of verification is highly resistent to sybil attacks - only a single honest network peer is required in order to receive and verify the complete state of the "true" block chain.
![Block Height Compared To Block Depth](/img/dev/en-block-height-vs-depth.svg) ![Block Height Compared To Block Depth](/img/dev/en-block-height-vs-depth.svg)