5ec951f6a7
This commit improves how the headers-first mode works in several ways.
The previous headers-first code was an initial implementation that did not
have all of the bells and whistles and a few less than ideal
characteristics. This commit improves the heaers-first code to resolve
the issues discussed next.
- The previous code only used headers-first mode when starting out from
block height 0 rather than allowing it to work starting at any height
before the final checkpoint. This means if you stopped the chain
download at any point before the final checkpoint and restarted, it
would not resume and you therefore would not have the benefit of the
faster processing offered by headers-first mode.
- Previously all headers (even those after the final checkpoint) were
downloaded and only the final checkpoint was verified. This resulted in
the following issues:
- As the block chain grew, increasingly larger numbers of headers were
downloaded and kept in memory
- If the node the node serving up the headers was serving an invalid
chain, it wouldn't be detected until downloading a large number of
headers
- When an invalid checkpoint was detected, no action was taken to
recover which meant the chain download would essentially be stalled
- The headers were kept in memory even though they didn't need to be as
merely keeping track of the hashes and heights is enough to provde they
properly link together and checkpoints match
- There was no logging when headers were being downloaded so it could
appear like nothing was happening
- Duplicate requests for the same headers weren't being filtered which
meant is was possible to inadvertently download the same headers twice
only to throw them away.
This commit resolves these issues with the following changes:
- The current height is now examined at startup and prior each sync peer
selection to allow it to resume headers-first mode starting from the
known height to the next checkpoint
- All checkpoints are now verified and the headers are only downloaded
from the current known block height up to the next checkpoint. This has
several desirable properties:
- The amount of memory required is bounded by the maximum distance
between to checkpoints rather than the entire length of the chain
- A node serving up an invalid chain is detected very quickly and with
little work
- When an invalid checkpoint is detected, the headers are simply
discarded and the peer is disconnected for serving an invalid chain
- When the sync peer disconnets, all current headers are thrown away
and, due to the new aforementioned resume code, when a new sync peer
is selected, headers-first mode will continue from the last known good
block
- In addition to reduced memory usage from only keeping information about
headers between two checkpoints, the only information now kept in memory
about the headers is the hash and height rather than the entire header
- There is now logging information about what is happening with headers
- Duplicate header requests are now filtered
|
||
|---|---|---|
| limits | ||
| release | ||
| util | ||
| .gitignore | ||
| .travis.yml | ||
| addrmanager.go | ||
| addrmanager_test.go | ||
| blockmanager.go | ||
| btcd.go | ||
| CHANGES | ||
| config.go | ||
| deps.txt | ||
| discovery.go | ||
| doc.go | ||
| LICENSE | ||
| log.go | ||
| mempool.go | ||
| mruinvmap.go | ||
| mruinvmap_test.go | ||
| params.go | ||
| peer.go | ||
| README.md | ||
| rpcserver.go | ||
| rpcwebsocket.go | ||
| sample-btcd.conf | ||
| server.go | ||
| service_windows.go | ||
| signal.go | ||
| upgrade.go | ||
| upnp.go | ||
| version.go | ||
btcd
[
]
(https://travis-ci.org/conformal/btcd)
btcd is an alternative full node bitcoin implementation written in Go (golang).
This project is currently under active development and is in an Alpha state.
It currently properly downloads, validates, and serves the block chain using the exact rules (including bugs) for block acceptance as the reference implementation (bitcoind). We have taken great care to avoid btcd causing a fork to the block chain. It passes all of the 'official' block acceptance tests (https://github.com/TheBlueMatt/test-scripts).
It also properly relays newly mined blocks, maintains a transaction pool, and relays individual transactions that have not yet made it into a block. It ensures all individual transactions admitted to the pool follow the rules required into the block chain and also includes the vast majority of the more strict checks which filter transactions based on miner requirements ("standard" transactions).
One key difference between btcd and bitcoind is that btcd does NOT include wallet functionality and this was a very intentional design decision. See the blog entry here for more details. This means you can't actually make or receive payments directly with btcd. That functionality will be provided by the forthcoming btcwallet and btcgui.
Installation
Windows - MSI Available
https://github.com/conformal/btcd/releases
Linux/BSD/POSIX - Build from Source
-
Install Go according to the installation instructions here: http://golang.org/doc/install NOTE: btcd requires features only available in Go version 1.2 or later.
-
Run the following command to obtain btcd, all dependencies, and install it:
$ go get github.com/conformal/btcd -
btcd will now be installed in either
$GOROOT/binor$GOPATH/bindepending on your configuration. If you did not already add to your system path during the installation, we recommend you do so now.
Updating
Windows
Install a newer MSI
Linux/BSD/POSIX - Build from Source
NOTE: btcd requires features only available in Go version 1.2 or later.
- Run the following command to update btcd, all dependencies, and install it:
$ go get -u -v github.com/conformal/btcd/...
Getting Started
btcd has several configuration options avilable to tweak how it runs, but all of the basic operations described in the intro section work with zero configuration.
Windows (Installed from MSI)
Launch btcd from your Start menu.
Linux/BSD/POSIX/Source
$ ./btcd
Mailing lists
- btcd: discussion of btcd and its packages.
- btcd-commits: readonly mail-out of source code changes.
To subscribe to a given list, send email to list+subscribe@opensource.conformal.com
TODO
The following is a brief overview of the next things we have planned to work on for btcd. Note this does not include the separate btcwallet and btcgui which are currently under heavy development:
- Documentation
- Code cleanup
- Add remaining missing RPC calls
- Complete several TODO items in the code
- Offer cross-compiled binaries for popular OSes (Fedora, Ubuntu, FreeBSD, OpenBSD)
GPG Verification Key
All official release tags are signed by Conformal so users can ensure the code has not been tampered with and is coming from Conformal. To verify the signature perform the following:
-
Download the public key from the Conformal website at https://opensource.conformal.com/GIT-GPG-KEY-conformal.txt
-
Import the public key into your GPG keyring:
gpg --import GIT-GPG-KEY-conformal.txt -
Verify the release tag with the following command where
TAG_NAMEis a placeholder for the specific tag:git tag -v TAG_NAME
License
btcd is licensed under the copyfree ISC License.