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".
* Sorted the _includes/references.md file as it became unclear where
links should be added.
* Fixed accidentally lowercased "merkle" at start of sentence.
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!)
* Adds the #bitcoin-dev IRC channel, Bitcoin StackExchange, and
BitcoinTalk Dev & Tech board to the development page.
* Links to that section of the page from the devel docs.
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
Describe the essential functions of a wallet program and how multiple
programs can work together to fulfill those functions, as in the case of
a signing-only wallet.
* 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)
* Add new icons for Developer Guide and Developer Examples so we don't
keep reusing the book icon.
* Update payment protocol links to point to developer examples when
appropriate.
* Add new Developer Examples page
* Add a transaction tutorial describing in detail how to make various
different transactions.
* Add a new "multicode" CSS class to allow combination of consecutive
code blocks into a single code block. This lets us use pygments
highlighting for multiple different types of code within the same
aparent block of code.
* Get autocrossref to ignore code blocks so we don't need to endcrossref
every time we encounter a code block. This makes the source much more
readable and maintainable.
Two unrelated minor additions which were requested at nearly the same
time.
* @mikehearn requested we add a link to @gavinandresen's PaymentRequest
generator. Added to _includes/guide_payment_processing.md with link
definition in _includes/references.md
* @Burrito-Bazooka requested we mention that the block reward halves
every 210,000 blocks. Added to _includes/ref_block_chain.md
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
