* Add flowchart illustration to blocks-first section to match new
headers-first flowchart
* Add new headers-first initial block download (IBD) section
* Revise Block Broadcasting section
* Add paragraph about orphan block handling in headers-first to the
Orphan Blocks section
* Ran `make manual-updates` to grab new summary
* Clarified that GHPS is part of 0.10.0 and is removed in master
* Autocrossref'd "Bitcoin Core master" to GitHub repo
* Removed GHPS from list of Mining RPCs now that it's in Removed RPCs
This commit provides a detailed overview of the current block download
method, which I've retroactively named blocks-first for parallelism with
headers-first.
New And Significantly Revised:
* New Initial Block Download (IBD) section (h3) with Blocks-First
subsection (h4)
* New Orphan Block subsection (under Blocks Broadcasting) describing
orphan blocks and how they're handled under blocks-first. Also
includes a simple illustration of the difference between orphan blocks
and stale blocks. Thanks to luke-jr for his s/orphan block/stale
block/ commit a couple months ago---that made this commit much easier.
Edits:
* Cleaned up a couple cases missed by previous s/orphan/stale/ commit
because they used past tense (orphaned).
* In P2P reference section, mentioned that a `block` message can be sent
unsolicited by miners.
* Mention that `getheaders` and `headers` were added in protocol
version 31800.
* Moved a few internal links around and added a few new internal links.
Administrivia:
* Started adding "TODOv0.10" in HTML comments to places that need to be
updated when 0.10 is released so that I can easily git grep for that
tag later.
* All previously-documented RPCs have had their text completely
rewritten.
* All new RPCs and changed RPCs in Bitcoin Core 0.10.0 have been
documented, except for hidden RPCs.
* A new RPC "Quick Reference" section has been added to make finding the
right RPC easier.
* A "See Also" subsection has been added to the end of every RPC
pointing to other relevant information.
* All previous examples in the RPC section have been re-run and updated
as necessary.
* Syntax highlighting has been added wherever possible.
* Hash byte order has been specified as RPC byte order everywhere it's
used in RPCs.
New material:
* Add documentation for `filterload` message to devref. This is the last
P2P protocol message which needed documentation.
* Add an example for creating a bloom filter to the devex, as well as an
example of checking data against that filter.
Edits:
* Change "object" to "element" in previous `filteradd` text. I decided
"transaction element" made more sense than the more generic "object".
Text should be fully consistent across both `filterload` and
`filteradd` descriptions.
* Mentioned that I think the example hexdump in the `alert` section is
public domain. (Only the hex is taken from the wiki; the annotation is
my own work.)
* Describes all remaining messages except filterload. Specificially, the
following messages are described: Addr, Alert, FilterAdd, FilterClear,
GetAddr, Ping, Pong, Reject, VerAck, and Version
* New makefile test: report broken markdown tables
* Put relevant protocol version changes at the top of all message
subsections.
Adds to the devel reference page detailed documentation on the following
messages: block, getblocks, getdata, getheaders, headers, inv, mempool,
merkleblock, notfound, and tx.
Adds to the devel examples page an example of requesting and parsing a
merkleblock message.
Adds to the devel docs overview pages links to the above two new
P2P sections.
Tweaks the autocrossref plugin ignore pattern to not crossref in the
middle of a GIF image name; this allows the inclusion of animated GIFs.
* Replace current description of the block header with a better
description.
* Describe the various version numbers.
* Describe how the merkle root is constructed.
* Describe how nBits is parsed and how to correctly create it to
avoid negative values.
* Describe the serialized block format used to calculate max block size.
Provides a detailed description of the transaction format, replacing an
example hexdump taken from the wiki.
I'm putting this in the transaction section as the format is necessary
for the creation of txids, which are used as merkle leaves (so are
covered by consensus rules). However, this is also the format used by
several P2P network messages to transmit transactions, so I'll be
linking back to it from there as I document those messages.
* Revise P2P Networking section to provide a more detailed description
of initial peer discovery and DNS seeds.
* Tweak autocrossref.rb to allow term blacklisting. Use this new feature
to prevent cross referencing "address" in "IP address" to the
definition of Bitcoin P2PKH/P2SH addresses. This avoids a bunch of
manual "norefs".
Based on a suggestion made by @petertodd to the -devel mailing list and
the discussion in that thread by him and other participants.
* We've been using the term "consensus", but this commit introduces a
formal definition for it and "consensus rules" as part of the block
chain introduction.
* Describe that consensus rules may change and may happen when they
do: hard or soft forks.
* Describe how full nodes can detect hard or soft forks, then describe
how SPV clients can detect hard and soft forks using the more limited
information available to them.
* Add a short subsection about the different byte orders used with
hashes in Bitcoin Core and other software.
* Re-word some text in other sections to mention the byte order
differences
This commit created based on comments from @SergioDemianLerner (thanks!)
This modifies commits provided by @petertodd to use the terms "pubkey
script" and "signature script" instead of other terms.
* Rename "scriptPubKey" and "output script" to "pubkey script"
(suggested by @luke-jr). We leave a token "scriptPubKey" at the point
where we define pubkey script so that searchers can find it.
* Rename "scriptSig" to "signature script" (suggested by @luke-jr). We
also leave a token "scriptSig" at this definition point.
* Rename "redeemScript" to "redeem script"
* Defined ECDSA on secp256k1 curve as the crypto used in the Transaction
section and added references to secp256k1 private/public keys and
signatures.
* Removed "The Parts Of A Transaction" illustration by commenting it out
in the HTML. Shoehorning the pubkey/signature script terms into this
image was becoming difficult, and I'm not very fond of that
illustration anyway. I'll see if I can think of a nicer replacement
illustration for some point in the future.
* Add a short paraphrased version @petertodd's description of scripts as
generalized crypto.
* Updated all the illustrations which referred to either pubkey scripts
or signature scripts to use these terms.
* Small grammar fixes.
* Lower case #term-scriptPubKey as all our other anchor links are
lower case
* Replace script/scripts with scriptPubKey/scriptPubKeys in
_autocrossref.yaml. (Fixes `make test` errors from broken
auto-crossref links.)
Move existing "regtest / testnet" texts to the new subsection and link to it
Move Bitcoin Core setup instructions in devel-examples
Add a consistent introduction for devel-(guide/ref/examples)
Fix autocrossref.rb to not add links inside {% highlight %} code blocks
* Remove the QR Code error corrections subsection.
* Remove the non-example Payment Protocol text from developer examples.
* Update reference links and autocrossrefs to reflect above deletions
* Fix CSS padding problems reported by @saivann
* Remove all HTML comments from autocrossref text to allow easy checking
for broken link definitions: find _site -name '*.html' | xargs grep '\]\['
* Add PNG versions of guide and example SVG icons. (optipng run)
As suggested by @gmaxwell (thanks!), I tried to make clearer the benefit
of hardened keys:
* Described hardened keys as a solution in the first sentence of the
Hardened Keys subsection.
* Reordered the text so that the problem is described before the
solution, making the presence of a solution clearer.
* Added a prefatory sentence to the description of the two key
derivation formulas again describing the hardened formula as a
solution.
As suggested by @vbuterin (thanks!), I added a paragraph describing that
HD wallets don't use normal derivation on the master key so they don't
have an effective master public key. (See end of the diff.)
This is a fairly large diff because of the reordering, but no new
clauses were added besides those described above.
Thanks also (in alphabetical order) to @cbeams, @mikehearn, and
@tgeller, among others.
The last pre-squash commit was: c2b8d562aa107c7b68c60946cea14cdccc5159ad
