lbcd/README.md

154 lines
4.9 KiB
Markdown
Raw Normal View History

2013-09-09 18:00:46 +02:00
btcd
====
[![Build Status](https://travis-ci.org/btcsuite/btcd.png?branch=master)](https://travis-ci.org/btcsuite/btcd)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](http://godoc.org/github.com/btcsuite/btcd)
2013-09-09 18:00:46 +02:00
btcd is an alternative full node bitcoin implementation written in Go (golang).
This project is currently under active development and is in a Beta state. It
is extremely stable and has been in production use since October 2013.
It properly downloads, validates, and serves the block chain using the exact
blockchain: Add block validation infrastructure. This adds a full-blown testing infrastructure in order to test consensus validation rules. It is built around the idea of dynamically generating full blocks that target specific rules linked together to form a block chain. In order to properly test the rules, each test instance starts with a valid block that is then modified in the specific way needed to test a specific rule. Blocks which exercise following rules have been added for this initial version. These tests were largely ported from the original Java-based 'official' block acceptance tests as well as some additional tests available in the Core python port. It is expected that further tests can be added over time as consensus rules change. * Enough valid blocks to have a stable base of mature coinbases to spend for futher tests * Basic forking and chain reorganization * Double spends on forks * Too much proof-of-work coinbase (extending main chain, in block that forces a reorg, and in a valid fork) * Max and too many signature operations via various combinations of OP_CHECKSIG, OP_MULTISIG, OP_CHECKSIGVERIFY, and OP_MULTISIGVERIFY * Too many and max signature operations with offending sigop after invalid data push * Max and too many signature operations via pay-to-script-hash redeem scripts * Attempt to spend tx created on a different fork * Attempt to spend immature coinbase (on main chain and fork) * Max size block and block that exceeds the max size * Children of rejected blocks are either orphans or rejected * Coinbase script too small and too large * Max length coinbase script * Attempt to spend tx in blocks that failed to connect * Valid non-coinbase tx in place of coinbase * Block with no transactions * Invalid proof-of-work * Block with a timestamp too far in the future * Invalid merkle root * Invalid proof-of-work limit (bits header field) * Negative proof-of-work limit (bits header field) * Two coinbase transactions * Duplicate transactions * Spend from transaction that does not exist * Timestamp exactly at and one second after the median time * Blocks with same hash via merkle root tricks * Spend from transaction index that is out of range * Transaction that spends more that its inputs provide * Transaction with same hash as an existing tx that has not been fully spent (BIP0030) * Non-final coinbase and non-coinbase txns * Max size block with canonical encoding which exceeds max size with non-canonical encoding * Spend from transaction earlier in same block * Spend from transaction later in same block * Double spend transaction from earlier in same block * Coinbase that pays more than subsidy + fees * Coinbase that includes subsidy + fees * Invalid opcode in dead execution path * Reorganization of txns with OP_RETURN outputs * Spend of an OP_RETURN output * Transaction with multiple OP_RETURN outputs * Large max-sized block reorganization test (disabled by default since it takes a long time and a lot of memory to run) Finally, the README.md files in the main and docs directories have been updated to reflect the use of the new testing framework.
2016-09-14 01:11:12 +02:00
rules (including consensus bugs) for block acceptance as Bitcoin Core. We have
taken great care to avoid btcd causing a fork to the block chain. It includes a
full block validation testing framework which contains all of the 'official'
block acceptance tests (and some additional ones) that is run on every pull
request to help ensure it properly follows consensus. Also, it passes all of
the JSON test data in the Bitcoin Core code.
blockchain: Add block validation infrastructure. This adds a full-blown testing infrastructure in order to test consensus validation rules. It is built around the idea of dynamically generating full blocks that target specific rules linked together to form a block chain. In order to properly test the rules, each test instance starts with a valid block that is then modified in the specific way needed to test a specific rule. Blocks which exercise following rules have been added for this initial version. These tests were largely ported from the original Java-based 'official' block acceptance tests as well as some additional tests available in the Core python port. It is expected that further tests can be added over time as consensus rules change. * Enough valid blocks to have a stable base of mature coinbases to spend for futher tests * Basic forking and chain reorganization * Double spends on forks * Too much proof-of-work coinbase (extending main chain, in block that forces a reorg, and in a valid fork) * Max and too many signature operations via various combinations of OP_CHECKSIG, OP_MULTISIG, OP_CHECKSIGVERIFY, and OP_MULTISIGVERIFY * Too many and max signature operations with offending sigop after invalid data push * Max and too many signature operations via pay-to-script-hash redeem scripts * Attempt to spend tx created on a different fork * Attempt to spend immature coinbase (on main chain and fork) * Max size block and block that exceeds the max size * Children of rejected blocks are either orphans or rejected * Coinbase script too small and too large * Max length coinbase script * Attempt to spend tx in blocks that failed to connect * Valid non-coinbase tx in place of coinbase * Block with no transactions * Invalid proof-of-work * Block with a timestamp too far in the future * Invalid merkle root * Invalid proof-of-work limit (bits header field) * Negative proof-of-work limit (bits header field) * Two coinbase transactions * Duplicate transactions * Spend from transaction that does not exist * Timestamp exactly at and one second after the median time * Blocks with same hash via merkle root tricks * Spend from transaction index that is out of range * Transaction that spends more that its inputs provide * Transaction with same hash as an existing tx that has not been fully spent (BIP0030) * Non-final coinbase and non-coinbase txns * Max size block with canonical encoding which exceeds max size with non-canonical encoding * Spend from transaction earlier in same block * Spend from transaction later in same block * Double spend transaction from earlier in same block * Coinbase that pays more than subsidy + fees * Coinbase that includes subsidy + fees * Invalid opcode in dead execution path * Reorganization of txns with OP_RETURN outputs * Spend of an OP_RETURN output * Transaction with multiple OP_RETURN outputs * Large max-sized block reorganization test (disabled by default since it takes a long time and a lot of memory to run) Finally, the README.md files in the main and docs directories have been updated to reflect the use of the new testing framework.
2016-09-14 01:11:12 +02:00
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 by the block chain and also includes more strict checks which filter
transactions based on miner requirements ("standard" transactions).
One key difference between btcd and Bitcoin Core is that btcd does *NOT* include
wallet functionality and this was a very intentional design decision. See the
2013-10-05 09:51:12 +02:00
blog entry [here](https://blog.conformal.com/btcd-not-your-moms-bitcoin-daemon)
for more details. This means you can't actually make or receive payments
directly with btcd. That functionality is provided by the
[btcwallet](https://github.com/btcsuite/btcwallet) and
[Paymetheus](https://github.com/btcsuite/Paymetheus) (Windows-only) projects
which are both under active development.
2013-10-05 05:59:05 +02:00
## Requirements
[Go](http://golang.org) 1.6 or newer.
2013-10-05 05:59:05 +02:00
## Installation
#### Windows - MSI Available
https://github.com/btcsuite/btcd/releases
2013-10-05 05:59:05 +02:00
#### Linux/BSD/MacOSX/POSIX - Build from Source
2013-10-05 05:59:05 +02:00
- Install Go according to the installation instructions here:
http://golang.org/doc/install
- Ensure Go was installed properly and is a supported version:
```bash
$ go version
$ go env GOROOT GOPATH
```
NOTE: The `GOROOT` and `GOPATH` above must not be the same path. It is
recommended that `GOPATH` is set to a directory in your home directory such as
`~/goprojects` to avoid write permission issues. It is also recommended to add
`$GOPATH/bin` to your `PATH` at this point.
- Run the following commands to obtain btcd, all dependencies, and install it:
2015-02-08 19:00:36 +01:00
```bash
$ go get -u github.com/Masterminds/glide
$ git clone https://github.com/btcsuite/btcd $GOPATH/src/github.com/btcsuite/btcd
$ cd $GOPATH/src/github.com/btcsuite/btcd
$ glide install
$ go install . ./cmd/...
2015-02-08 19:00:36 +01:00
```
2013-10-05 05:59:05 +02:00
- btcd (and utilities) will now be installed in ```$GOPATH/bin```. If you did
not already add the bin directory to your system path during Go installation,
we recommend you do so now.
2013-10-05 05:59:05 +02:00
2013-10-08 20:30:36 +02:00
## Updating
#### Windows
Install a newer MSI
#### Linux/BSD/MacOSX/POSIX - Build from Source
2013-10-08 20:30:36 +02:00
- Run the following commands to update btcd, all dependencies, and install it:
2015-02-08 19:00:36 +01:00
```bash
$ cd $GOPATH/src/github.com/btcsuite/btcd
$ git pull && glide install
$ go install . ./cmd/...
2015-02-08 19:00:36 +01:00
```
2013-10-08 20:30:36 +02:00
2013-10-05 05:59:05 +02:00
## 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
```bash
$ ./btcd
2016-09-13 21:10:19 +02:00
```
2014-03-04 18:58:59 +01:00
2015-05-12 20:01:58 +02:00
## IRC
2014-03-04 18:58:59 +01:00
2015-05-12 20:01:58 +02:00
- irc.freenode.net
2014-03-04 18:58:59 +01:00
- channel #btcd
2015-05-12 20:01:58 +02:00
- [webchat](https://webchat.freenode.net/?channels=btcd)
2014-03-04 18:58:59 +01:00
2013-10-15 18:16:17 +02:00
## 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
2013-09-09 18:00:46 +02:00
## Issue Tracker
2013-09-09 18:00:46 +02:00
The [integrated github issue tracker](https://github.com/btcsuite/btcd/issues)
is used for this project.
2013-10-05 05:59:05 +02:00
## Documentation
The documentation is a work-in-progress. It is located in the [docs](https://github.com/btcsuite/btcd/tree/master/docs) folder.
2013-10-05 05:59:05 +02:00
## 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 the btcsuite developers. To
verify the signature perform the following:
2013-10-05 05:59:05 +02:00
- 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:
```bash
gpg --import GIT-GPG-KEY-conformal.txt
```
- Verify the release tag with the following command where `TAG_NAME` is a
placeholder for the specific tag:
```bash
git tag -v TAG_NAME
```
## License
2014-01-15 17:19:51 +01:00
btcd is licensed under the [copyfree](http://copyfree.org) ISC License.