Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

fix description of how true chain is determined #1395

Merged
merged 4 commits into from Oct 17, 2016

Conversation

Projects
None yet
4 participants
Contributor

jlopp commented Oct 15, 2016

Currently states that full nodes take the longest chain as the true chain while they actually care about the cumulative proof of work, not the chain height.

fix description of how true chain is determined
Currently states that full nodes take the longest chain as the true chain while they actually care about the cumulative proof of work, not the chain height.
@@ -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.
-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 impossible due to the fact that the longest chain is by definition the true chain. After the suggested six confirmations, the ability to fool the client become intractable, as only a single honest network node is needed to have the complete state of the 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 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.
@harding

harding Oct 15, 2016

Contributor

@jlopp

  • "fool a full node become intractable" should be becomes
  • For sybil attacks - only a single could you make that sybil attacks---only a single (the triple dash will be transformed by our Markdown interpreter into a proper emdash)

Otherwise, this LGTM. CC: @instagibbs (who I believe authored this paragraph)

@jlopp

jlopp Oct 15, 2016

Contributor

Applied those suggested changes.

Contributor

jlopp commented Oct 15, 2016

Fixed pluralization problem

Contributor

harding commented Oct 15, 2016

ACK. Thanks, @jlopp!

Contributor

theymos commented Oct 16, 2016 edited

It wasn't introduced in this PR, but I'm noticing now that this paragraph contains the incorrect statement: "the ability to fool a full node becomes intractable after 6 confirmations." Intractable in this context means "basically impossible, considering real-world limitations." But it's only difficult to reverse a 6-conf transaction, not nearly impossible. Satoshi chose 6 confirmations as the "confirmed point" by finding the point at which an attacker with 10% of the network would have less than a 0.1% chance of success (ie. he was assuming that both of those values were reasonable). Today, if the top two pools cooperated, they'd have about a 21% chance of success in reversing a 6-conf transaction, using numbers from Meni Rosenfeld's double-spend paper.

I recommend changing "intractable" to "very expensive".

Contributor

jlopp commented Oct 16, 2016

Agreed; replaced intractable with very expensive.

@Cobra-Bitcoin Cobra-Bitcoin merged commit 5678835 into bitcoin-dot-org:master Oct 17, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment