* Added instructions for Windows 7, but only for Bitcoin Core GUI. I
added a stub for anyone who wants to write instructions for using the
daemon on Windows.
* Added instructions for Ubuntu 14.04 LTS Server, but only for Bitcoin
core daemon. I assume most server users run headless.
* Added instructions for Other Linux Distributions, for both GUI and
daemon. Hopefully the instructions are general enough to apply to most
distributions but specific enough that they actually help readers.
* Added a stub for Windows 8.1 as I don't have access to a copy, and all
the pay-per-hour Windows VPSes I can find run some version of Windows
Server. (I have the same problem with OS X.)
* Hid some subsections in the table of contents: I found having
subsections named "Bitcoin Core GUI" and "...Daemon" within multiple
sections distracting, so I hid them in the TOC.
* Added basic PGP verification instructions: I didn't try to explain PGP
to newbies, but I did provide instructions useful to people who have
used PGP before. These instructions are currently displayed in the
Windows 7 and Other Linux Distributions sections (where users download
from Bitcoin.org).
* Made sure the end of each install section points to the Network
Configuration section so users open port 8333.
Closes#410
Made numerous corrections suggestion by Saivann Carignan (thanks!),
including:
* Replaced GUI autostart instructions with using Bitcoin Core GUI's own
autostart option.
* Described minimum upload speed requirements.
* Described metered bandwidth requirements. Also added a warning about
exceeding periodic bandwidth limits.
* List items that ended with complete sentences (subject+predicate)
received terminal punctuation. Did not terminally punctuate sentence
fragments (sentences missing a subject or predicate).
Also suggested by Saivann, I added an extended section describing
setting up port forwarding on home routers and opening firewall ports to
allow inbound connections to port 8333.
Add basic page with some general information plus instructions for
Ubuntu 14.10.
Change a link on the participate page to point to the full node page.
This page is being added as English-only for now. I figure we can
convert it into a translation template after we have instructions for
Windows and Mac OS X, and after the instrutions have actually been
tested with the released version of Bitcoin Core 0.10.0. (These Ubuntu
instructions were tested with RC3 and the old Ubuntu packaging.)
* Set filenames once in the download page
* Edit download page for new or updated files
* Add link to the source code, GitHub and torrent download
* Replace long sync instructions by short instructions to run a full node on the download page
Commit originated by Saïvann Carignan and updated by Dave Harding.
* 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
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.
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.
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.
* Replace previous TX Overview image with a simplified illustration.
The previous overview image was commented out in pull #566 / commit
6afc683. New image incorporates suggestions by @saivann (thanks!)
* Add new illustration showing the specifics of outputs and inputs (and
how they're related). This replaces most of the detail lost by using a
simplified overview image
* Add two short paragraphs briefly describing the ouput and input
features, leading into the existing detailed P2PKH description
