LBRYCommunity/lbcd
1
0
Fork 0
Code Issues 17 Pull requests 4 Projects Releases 28 Packages Wiki Activity

[lbry] docs: update docs for LBRY

Browse source 
Co-authored-by: Roy Lee <roylee17@gmail.com>
This commit is contained in:
Brannon King 2021-08-19 14:41:48 -04:00 committed by Roy Lee
parent a09c895f49
commit 4e63bef33b
47 changed files with 836 additions and 3414 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1230
CHANGES
View file

File diff suppressed because it is too large Load diff

1
LICENSE
View file

@ -1,5 +1,6 @@
ISC License
Copyright (c) 2021 The LBRY developers
Copyright (c) 2013-2017 The btcsuite developers
Copyright (c) 2015-2016 The Decred developers

168
README.md
View file

@ -1,121 +1,133 @@
btcd
====
# lbcd
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![Coverage Status](https://coveralls.io/repos/github/btcsuite/btcd/badge.svg?branch=master)](https://coveralls.io/github/btcsuite/btcd?branch=master)
[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
[![Coverage Status](https://coveralls.io/repos/github/lbryio/lbcd/badge.svg?branch=master)](https://coveralls.io/github/lbryio/lbcd?branch=master)
[![ISC License](https://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd)
<!--[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/lbryio/lbcd)-->
btcd is an alternative full node bitcoin implementation written in Go (golang).
`lbcd` is a full node implementation of LBRY's blockchain 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.
This project is currently under active development and is in a Beta state while
we ensure it matches LBRYcrd's functionality. The intention is that it properly
downloads, validates, and serves the block chain using the exact rules
(including consensus bugs) for block acceptance as LBRYcrd.
We have taken great care to avoid lbcd causing a fork to the blockchain.
It properly downloads, validates, and serves the block chain using the exact
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.
Note: `lbcd` does *NOT* include wallet functionality. That functionality is provided by the
[lbcwallet](https://github.com/lbryio/lbcwallet) and the [LBRY SDK](https://github.com/lbryio/lbry-sdk).
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).
## Security
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
blog entry [here](https://web.archive.org/web/20171125143919/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.
We take security seriously. Please contact [security](mailto:security@lbry.com) regarding any security issues.
Our PGP key is [here](https://lbry.com/faq/pgp-key) if you need it.
We maintain a mailing list for notifications of upgrades, security issues,
and soft/hard forks. To join, visit [fork list](https://lbry.com/forklist)
## Requirements
[Go](http://golang.org) 1.16 or newer.
All common operating systems are supported. lbcd requires at least 8GB of RAM
and at least 100GB of disk storage. Both RAM and disk requirements increase slowly over time.
Using a fast NVMe disk is recommended.
`lbcd` is not immune to data loss. It expects a clean shutdown via SIGINT or
SIGTERM. SIGKILL, immediate VM kills, and sudden power loss can cause data
corruption, thus requiring chain resynchronization for recovery.
For compilation, [Go](http://golang.org) 1.16 or newer is required.
## Installation
https://github.com/btcsuite/btcd/releases
Acquire binary files from [releases](https://github.com/lbryio/lbcd/releases)
#### Linux/BSD/MacOSX/POSIX - Build from Source
### To build from Source on Linux/BSD/MacOSX/POSIX
- Install Go according to the installation instructions here:
http://golang.org/doc/install
Install Go according to its [installation instructions](http://golang.org/doc/install).
- Ensure Go was installed properly and is a supported version:
``` sh
git clone https://github.com/lbryio/lbcd
cd lbcd
```bash
$ go version
$ go env GOROOT GOPATH
# Build lbcd
go build .
# Build lbcctl
go build ./cmd/lbcctl
```
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.
Both [GoLand](https://www.jetbrains.com/go/)
and [VS Code](https://code.visualstudio.com/docs/languages/go) IDEs are supported.
- Run the following commands to obtain btcd, all dependencies, and install it:
## Usage
```bash
$ cd $GOPATH/src/github.com/btcsuite/btcd
$ GO111MODULE=on go install -v . ./cmd/...
By default, data and logs are stored in `<LBCDDIR>`:
- Linux: `~/.lbcd/`
- MacOS: `/Users/<username>/Library/Application Support/Lbcd/`
To enable RPC access a username and password is required. Example:
``` sh
./lbcd --txindex --rpcuser=rpcuser --rpcpass=rpcpass
```
- 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.
Interact with lbcd via RPC using `lbcctl`
## Updating
#### Linux/BSD/MacOSX/POSIX - Build from Source
- Run the following commands to update btcd, all dependencies, and install it:
```bash
$ cd $GOPATH/src/github.com/btcsuite/btcd
$ git pull
$ GO111MODULE=on go install -v . ./cmd/...
``` sh
./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass getblockcount
./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass getblocktemplate
```
## Getting Started
By default, the RPCs are served over TLS. `lbcd` generates (if not exists) `rpc.cert` and
`rpc.key` under `<LBCDDIR>` where `lbcctl` would search and use them.
btcd has several configuration options available to tweak how it runs, but all
of the basic operations described in the intro section work with zero
configuration.
The RPCs can also be served without TLS *(on localhost only)* using (`--notls`)
#### Linux/BSD/POSIX/Source
```bash
$ ./btcd
``` sh
./lbcd --txindex --rpcuser=rpcuser --rpcpass=rpcpass --notls
./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass --notls getblockcount
```
## IRC
## Working with Different Networks
- irc.libera.chat
- channel #btcd
- [webchat](https://web.libera.chat/gamja/?channels=btcd)
By default, `lbcd` and `lbcctl` use the following ports for different networks respectively:
## Issue Tracker
| Network | RPC Port | Network Port |
| ------- | -------- | ------------ |
| mainnet | 9245 | 9246 |
| testnet | 19245 | 19246 |
| regtest | 29245 | 29246 |
The [integrated github issue tracker](https://github.com/btcsuite/btcd/issues)
is used for this project.
Running `lbcd` and `lbcctl` with `--testnet` or `--regtest` would use different chain params as well as default RPC and Network ports.
## Documentation
``` sh
./lbcd --txindex --rpcuser=rpcuser --rpcpass=rpcpass --regtest
./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass --regtest getblockcount
```
The documentation is a work-in-progress. It is located in the [docs](https://github.com/btcsuite/btcd/tree/master/docs) folder.
The default Network and RPC ports of `lbcd` can be overriden using `--listen` and `--rpclisten`
`lbcctl` can also connect to RPC server specified by `--rpcserver`
## Release Verification
``` sh
./lbcd --txindex --rpcuser=rpcuser --rpcpass=rpcpass --regtest --listen=127.0.0.1:29248 --rpclisten=127.0.0.1:29247
./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass --regtest --rpcserver=127.0.0.1:29247 getblockcount
```
Note: Wallet related RPCs are provided by [lbcwallet](https://github.com/lbryio/lbcwallet).
## Contributing
Contributions to this project are welcome, encouraged, and compensated.
The [integrated github issue tracker](https://github.com/lbryio/lbcd/issues)
is used for this project. All pull requests will be considered.
<!-- ## Release Verification
Please see our [documentation on the current build/verification
process](https://github.com/btcsuite/btcd/tree/master/release) for all our
process](https://github.com/lbryio/lbcd/tree/master/release) for all our
releases for information on how to verify the integrity of published releases
using our reproducible build system.
-->
## License
btcd is licensed under the [copyfree](http://copyfree.org) ISC License.
lbcd is licensed under the [copyfree](http://copyfree.org) ISC License.

68
blockchain/README.md
View file

@ -1,30 +1,9 @@
blockchain
==========
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain)
Package blockchain implements bitcoin block handling and chain selection rules.
The test coverage is currently only around 60%, but will be increasing over
time. See `test_coverage.txt` for the gocov coverage report. Alternatively, if
you are running a POSIX OS, you can run the `cov_report.sh` script for a
real-time report. Package blockchain is licensed under the liberal ISC license.
There is an associated blog post about the release of this package
[here](https://blog.conformal.com/btcchain-the-bitcoin-chain-package-from-bctd/).
This package has intentionally been designed so it can be used as a standalone
package for any projects needing to handle processing of blocks into the bitcoin
block chain.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/blockchain
```
## Bitcoin Chain Processing Overview
### Bitcoin Chain Processing Overview
Before a block is allowed into the block chain, it must go through an intensive
series of validation rules. The following list serves as a general outline of
@ -57,47 +36,4 @@ is by no means exhaustive:
transaction values
- Run the transaction scripts to verify the spender is allowed to spend the
coins
- Insert the block into the block database
## Examples
* [ProcessBlock Example](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain#example-BlockChain-ProcessBlock)
Demonstrates how to create a new chain instance and use ProcessBlock to
attempt to add a block to the chain. This example intentionally
attempts to insert a duplicate genesis block to illustrate how an invalid
block is handled.
* [CompactToBig Example](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain#example-CompactToBig)
Demonstrates how to convert the compact "bits" in a block header which
represent the target difficulty to a big integer and display it using the
typical hex notation.
* [BigToCompact Example](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain#example-BigToCompact)
Demonstrates how to convert a target difficulty into the
compact "bits" in a block header which represent that target difficulty.
## 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:
- 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
Package blockchain is licensed under the [copyfree](http://copyfree.org) ISC
License.
- Insert the block into the block database

6
blockchain/fullblocktests/README.md
View file

@ -1,9 +1,9 @@
fullblocktests
==============
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain/fullblocktests)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/lbryio/lbcd/blockchain/fullblocktests)
Package fullblocktests provides a set of full block tests to be used for testing
the consensus validation rules. The tests are intended to be flexible enough to
@ -20,7 +20,7 @@ of blocks that exercise the consensus validation rules.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/blockchain/fullblocktests
$ go get -u github.com/lbryio/lbcd/blockchain/fullblocktests
```
## License

6
blockchain/indexers/README.md
View file

@ -1,9 +1,9 @@
indexers
========
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain/indexers?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain/indexers)
[![GoDoc](https://pkg.go.dev/github.com/lbryio/lbcd/blockchain/indexers?status.png)](https://pkg.go.dev/github.com/lbryio/lbcd/blockchain/indexers)
Package indexers implements optional block chain indexes.
@ -23,7 +23,7 @@ via an RPC interface.
## Installation
```bash
$ go get -u github.com/btcsuite/btcd/blockchain/indexers
$ go get -u github.com/lbryio/lbcd/blockchain/indexers
```
## License

61
btcec/README.md
View file

@ -1,68 +1,11 @@
btcec
=====
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/btcec?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/btcec)
Package btcec implements elliptic curve cryptography needed for working with
btcec implements elliptic curve cryptography needed for working with
Bitcoin (secp256k1 only for now). It is designed so that it may be used with the
standard crypto/ecdsa packages provided with go. A comprehensive suite of test
is provided to ensure proper functionality. Package btcec was originally based
on work from ThePiachu which is licensed under the same terms as Go, but it has
signficantly diverged since then. The btcsuite developers original is licensed
under the liberal ISC license.
Although this package was primarily written for btcd, it has intentionally been
designed so it can be used as a standalone package for any projects needing to
use secp256k1 elliptic curve cryptography.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/btcec
```
## Examples
* [Sign Message](https://pkg.go.dev/github.com/btcsuite/btcd/btcec#example-package--SignMessage)
Demonstrates signing a message with a secp256k1 private key that is first
parsed form raw bytes and serializing the generated signature.
* [Verify Signature](https://pkg.go.dev/github.com/btcsuite/btcd/btcec#example-package--VerifySignature)
Demonstrates verifying a secp256k1 signature against a public key that is
first parsed from raw bytes. The signature is also parsed from raw bytes.
* [Encryption](https://pkg.go.dev/github.com/btcsuite/btcd/btcec#example-package--EncryptMessage)
Demonstrates encrypting a message for a public key that is first parsed from
raw bytes, then decrypting it using the corresponding private key.
* [Decryption](https://pkg.go.dev/github.com/btcsuite/btcd/btcec#example-package--DecryptMessage)
Demonstrates decrypting a message using a private key that is first parsed
from raw bytes.
## 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:
- 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
Package btcec is licensed under the [copyfree](http://copyfree.org) ISC License
except for btcec.go and btcec_test.go which is under the same license as Go.
signficantly diverged since then.

64
btcjson/README.md
View file

@ -1,70 +1,8 @@
btcjson
=======
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson)
Package btcjson implements concrete types for marshalling to and from the
bitcoin JSON-RPC API. A comprehensive suite of tests is provided to ensure
proper functionality.
Although this package was primarily written for the btcsuite, it has
intentionally been designed so it can be used as a standalone package for any
projects needing to marshal to and from bitcoin JSON-RPC requests and responses.
Note that although it's possible to use this package directly to implement an
RPC client, it is not recommended since it is only intended as an infrastructure
package. Instead, RPC clients should use the
[btcrpcclient](https://github.com/btcsuite/btcrpcclient) package which provides
a full blown RPC client with many features such as automatic connection
management, websocket support, automatic notification re-registration on
reconnect, and conversion from the raw underlying RPC types (strings, floats,
ints, etc) to higher-level types with many nice and useful properties.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/btcjson
```
## Examples
* [Marshal Command](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson#example-MarshalCmd)
Demonstrates how to create and marshal a command into a JSON-RPC request.
* [Unmarshal Command](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson#example-UnmarshalCmd)
Demonstrates how to unmarshal a JSON-RPC request and then unmarshal the
concrete request into a concrete command.
* [Marshal Response](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson#example-MarshalResponse)
Demonstrates how to marshal a JSON-RPC response.
* [Unmarshal Response](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson#example-package--UnmarshalResponse)
Demonstrates how to unmarshal a JSON-RPC response and then unmarshal the
result field in the response to a concrete type.
## 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:
- 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
Package btcjson is licensed under the [copyfree](http://copyfree.org) ISC
License.
proper functionality.

81
chaincfg/README.md
View file

@ -1,85 +1,8 @@
chaincfg
========
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/chaincfg)
Package chaincfg defines chain configuration parameters for the three standard
Bitcoin networks and provides the ability for callers to define their own custom
Bitcoin networks.
Although this package was primarily written for btcd, it has intentionally been
designed so it can be used as a standalone package for any projects needing to
use parameters for the standard Bitcoin networks or for projects needing to
define their own network.
## Sample Use
```Go
package main
import (
"flag"
"fmt"
"log"
"github.com/btcsuite/btcutil"
"github.com/btcsuite/btcd/chaincfg"
)
var testnet = flag.Bool("testnet", false, "operate on the testnet Bitcoin network")
// By default (without -testnet), use mainnet.
var chainParams = &chaincfg.MainNetParams
func main() {
flag.Parse()
// Modify active network parameters if operating on testnet.
if *testnet {
chainParams = &chaincfg.TestNet3Params
}
// later...
// Create and print new payment address, specific to the active network.
pubKeyHash := make([]byte, 20)
addr, err := btcutil.NewAddressPubKeyHash(pubKeyHash, chainParams)
if err != nil {
log.Fatal(err)
}
fmt.Println(addr)
}
```
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/chaincfg
```
## 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:
- 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
Package chaincfg is licensed under the [copyfree](http://copyfree.org) ISC
License.
LBRY networks and provides the ability for callers to define their own custom
LBRY networks.

6
chaincfg/chainhash/README.md
View file

@ -1,9 +1,9 @@
chainhash
=========
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/chaincfg/chainhash)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/lbryio/lbcd/chaincfg/chainhash)
=======
chainhash provides a generic hash type and associated functions that allows the
@ -12,7 +12,7 @@ specific hash algorithm to be abstracted.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/chaincfg/chainhash
$ go get -u github.com/lbryio/lbcd/chaincfg/chainhash
```
## GPG Verification Key

20
connmgr/README.md
View file

@ -1,13 +1,11 @@
connmgr
=======
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/connmgr)
Package connmgr implements a generic Bitcoin network connection manager.
Package connmgr implements a generic network connection manager.
## Overview
### Overview
Connection Manager handles all the general connection concerns such as
maintaining a set number of outbound connections, sourcing peers, banning,
@ -18,20 +16,10 @@ connection requests from a source or a set of given addresses, dial them and
notify the caller on connections. The main intended use is to initialize a pool
of active connections and maintain them to remain connected to the P2P network.
In addition the connection manager provides the following utilities:
In addition, the connection manager provides the following utilities:
- Notifications on connections or disconnections
- Handle failures and retry new addresses from the source
- Connect only to specified addresses
- Permanent connections with increasing backoff retry timers
- Disconnect or Remove an established connection
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/connmgr
```
## License
Package connmgr is licensed under the [copyfree](http://copyfree.org) ISC License.
- Disconnect or Remove an established connection

30
database/README.md
View file

@ -1,9 +1,7 @@
database
========
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/database)
Package database provides a block and metadata storage database.
@ -13,8 +11,8 @@ one entity can have the database open at a time (for most database backends),
and that entity will be btcd.
When a client wants programmatic access to the data provided by btcd, they'll
likely want to use the [rpcclient](https://github.com/btcsuite/btcd/tree/master/rpcclient)
package which makes use of the [JSON-RPC API](https://github.com/btcsuite/btcd/tree/master/docs/json_rpc_api.md).
likely want to use the [rpcclient](https://github.com/lbryio/lbcd/tree/master/rpcclient)
package which makes use of the [JSON-RPC API](https://github.com/lbryio/lbcd/tree/master/docs/json_rpc_api.md).
However, this package could be extremely useful for any applications requiring
Bitcoin block storage capabilities.
@ -32,26 +30,4 @@ storage, and strict checksums in key areas to ensure data integrity.
- Nested buckets
- Iteration support including cursors with seek capability
- Supports registration of backend databases
- Comprehensive test coverage
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/database
```
## Examples
* [Basic Usage Example](https://pkg.go.dev/github.com/btcsuite/btcd/database#example-package--BasicUsage)
Demonstrates creating a new database and using a managed read-write
transaction to store and retrieve metadata.
* [Block Storage and Retrieval Example](https://pkg.go.dev/github.com/btcsuite/btcd/database#example-package--BlockStorageAndRetrieval)
Demonstrates creating a new database, using a managed read-write transaction
to store a block, and then using a managed read-only transaction to fetch the
block.
## License
Package database is licensed under the [copyfree](http://copyfree.org) ISC
License.
- Comprehensive test coverage

4
database/ffldb/README.md
View file

@ -1,9 +1,9 @@
ffldb
=====
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/database/ffldb?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/database/ffldb)
[![GoDoc](https://pkg.go.dev/github.com/lbryio/lbcd/database/ffldb?status.png)](https://pkg.go.dev/github.com/lbryio/lbcd/database/ffldb)
=======
Package ffldb implements a driver for the database package that uses leveldb for

4
database/internal/treap/README.md
View file

@ -1,9 +1,9 @@
treap
=====
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/database/internal/treap?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/database/internal/treap)
[![GoDoc](https://pkg.go.dev/github.com/lbryio/lbcd/database/internal/treap?status.png)](https://pkg.go.dev/github.com/lbryio/lbcd/database/internal/treap)
Package treap implements a treap data structure that is used to hold ordered
key/value pairs using a combination of binary search tree and heap semantics.

6
doc.go
View file

@ -71,8 +71,8 @@ Application Options:
fee to the given amount in thousands of bytes per
minute (default: 15)
--listen= Add an interface/port to listen for connections
(default all interfaces port: 8333, testnet:
18333, signet: 38333)
(default all interfaces port: 9246, testnet:
19246, regtest: 29246, signet: 39246)
--logdir= Directory to log output
--maxorphantx= Max number of orphan transactions to keep in
memory (default: 100)
@ -123,7 +123,7 @@ Application Options:
--rpclimitpass= Password for limited RPC connections
--rpclimituser= Username for limited RPC connections
--rpclisten= Add an interface/port to listen for RPC
connections (default port: 8334, testnet: 18334)
connections (default port: 9245, testnet: 19245, regtest: 29245)
--rpcmaxclients= Max number of RPC clients for standard
connections (default: 10)
--rpcmaxconcurrentreqs= Max number of concurrent RPC requests that may be

319
docs/code_contribution_guidelines.md
View file

@ -1,319 +0,0 @@
# Code contribution guidelines
Developing cryptocurrencies is an exciting endeavor that touches a wide variety
of areas such as wire protocols, peer-to-peer networking, databases,
cryptography, language interpretation (transaction scripts), RPC, and
websockets. They also represent a radical shift to the current fiscal system
and as a result provide an opportunity to help reshape the entire financial
system. There are few projects that offer this level of diversity and impact
all in one code base.
However, as exciting as it is, one must keep in mind that cryptocurrencies
represent real money and introducing bugs and security vulnerabilities can have
far more dire consequences than in typical projects where having a small bug is
minimal by comparison. In the world of cryptocurrencies, even the smallest bug
in the wrong area can cost people a significant amount of money. For this
reason, the btcd suite has a formalized and rigorous development process which
is outlined on this page.
We highly encourage code contributions, however it is imperative that you adhere
to the guidelines established on this page.
## Minimum Recommended Skillset
The following list is a set of core competencies that we recommend you possess
before you really start attempting to contribute code to the project. These are
not hard requirements as we will gladly accept code contributions as long as
they follow the guidelines set forth on this page. That said, if you don't have
the following basic qualifications you will likely find it quite difficult to
contribute.
- A reasonable understanding of bitcoin at a high level (see the
[Required Reading](#ReqReading) section for the original white paper)
- Experience in some type of C-like language
- An understanding of data structures and their performance implications
- Familiarity with unit testing
- Debugging experience
- Ability to understand not only the area you are making a change in, but also
the code your change relies on, and the code which relies on your changed code
Building on top of those core competencies, the recommended skill set largely
depends on the specific areas you are looking to contribute to. For example,
if you wish to contribute to the cryptography code, you should have a good
understanding of the various aspects involved with cryptography such as the
security and performance implications.
## Required Reading
- [Effective Go](http://golang.org/doc/effective_go.html) - The entire btcd
suite follows the guidelines in this document. For your code to be accepted,
it must follow the guidelines therein.
- [Original Satoshi Whitepaper](http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fbitcoin.org%2Fbitcoin.pdf&ei=os3VUuH8G4SlsASV74GoAg&usg=AFQjCNEipPLigou_1MfB7DQjXCNdlylrBg&sig2=FaHDuT5z36GMWDEnybDJLg&bvm=bv.59378465,d.b2I) - This is the white paper that started it all. Having a solid
foundation to build on will make the code much more comprehensible.
## Development Practices
Developers are expected to work in their own trees and submit pull requests when
they feel their feature or bug fix is ready for integration into the master
branch.
## Share Early, Share Often
We firmly believe in the share early, share often approach. The basic premise
of the approach is to announce your plans **before** you start work, and once
you have started working, craft your changes into a stream of small and easily
reviewable commits.
This approach has several benefits:
- Announcing your plans to work on a feature **before** you begin work avoids
duplicate work
- It permits discussions which can help you achieve your goals in a way that is
consistent with the existing architecture
- It minimizes the chances of you spending time and energy on a change that
might not fit with the consensus of the community or existing architecture and
potentially be rejected as a result
- Incremental development helps ensure you are on the right track with regards
to the rest of the community
- The quicker your changes are merged to master, the less time you will need to
spend rebasing and otherwise trying to keep up with the main code base
## Testing
One of the major design goals of all core btcd packages is to aim for complete
test coverage. This is financial software so bugs and regressions can cost
people real money. For this reason every effort must be taken to ensure the
code is as accurate and bug-free as possible. Thorough testing is a good way to
help achieve that goal.
Unless a new feature you submit is completely trivial, it will probably be
rejected unless it is also accompanied by adequate test coverage for both
positive and negative conditions. That is to say, the tests must ensure your
code works correctly when it is fed correct data as well as incorrect data
(error paths).
Go provides an excellent test framework that makes writing test code and
checking coverage statistics straight forward. For more information about the
test coverage tools, see the [golang cover blog post](http://blog.golang.org/cover).
A quick summary of test practices follows:
- All new code should be accompanied by tests that ensure the code behaves
correctly when given expected values, and, perhaps even more importantly, that
it handles errors gracefully
- When you fix a bug, it should be accompanied by tests which exercise the bug
to both prove it has been resolved and to prevent future regressions
## Code Documentation and Commenting
- At a minimum every function must be commented with its intended purpose and
any assumptions that it makes
- Function comments must always begin with the name of the function per
[Effective Go](http://golang.org/doc/effective_go.html)
- Function comments should be complete sentences since they allow a wide
variety of automated presentations such as [go.dev](https://go.dev)
- The general rule of thumb is to look at it as if you were completely
unfamiliar with the code and ask yourself, would this give me enough
information to understand what this function does and how I'd probably want
to use it?
- Exported functions should also include detailed information the caller of the
function will likely need to know and/or understand:
**WRONG**
```Go
// convert a compact uint32 to big.Int
func CompactToBig(compact uint32) *big.Int {
```
**RIGHT**
```Go
// CompactToBig converts a compact representation of a whole number N to a
// big integer. The representation is similar to IEEE754 floating point
// numbers.
//
// Like IEEE754 floating point, there are three basic components: the sign,
// the exponent, and the mantissa. They are broken out as follows:
//
// * the most significant 8 bits represent the unsigned base 256 exponent
// * bit 23 (the 24th bit) represents the sign bit
// * the least significant 23 bits represent the mantissa
//
// -------------------------------------------------
// | Exponent | Sign | Mantissa |
// -------------------------------------------------
// | 8 bits [31-24] | 1 bit [23] | 23 bits [22-00] |
// -------------------------------------------------
//
// The formula to calculate N is:
// N = (-1^sign) * mantissa * 256^(exponent-3)
//
// This compact form is only used in bitcoin to encode unsigned 256-bit numbers
// which represent difficulty targets, thus there really is not a need for a
// sign bit, but it is implemented here to stay consistent with bitcoind.
func CompactToBig(compact uint32) *big.Int {
```
- Comments in the body of the code are highly encouraged, but they should
explain the intention of the code as opposed to just calling out the
obvious
**WRONG**
```Go
// return err if amt is less than 5460
if amt < 5460 {
return err
}
```
**RIGHT**
```Go
// Treat transactions with amounts less than the amount which is considered dust
// as non-standard.
if amt < 5460 {
return err
}
```
**NOTE:** The above should really use a constant as opposed to a magic number,
but it was left as a magic number to show how much of a difference a good
comment can make.
## Model Git Commit Messages
This project prefers to keep a clean commit history with well-formed commit
messages. This section illustrates a model commit message and provides a bit
of background for it. This content was originally created by Tim Pope and made
available on his website, however that website is no longer active, so it is
being provided here.
Here’s a model Git commit message:
```text
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Write your commit message in the present tense: "Fix bug" and not "Fixed
bug." This convention matches up with commit messages generated by
commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indent
```
Prefix the summary with the subsystem/package when possible. Many other
projects make use of the code and this makes it easier for them to tell when
something they're using has changed. Have a look at [past
commits](https://github.com/btcsuite/btcd/commits/master) for examples of
commit messages.
Here are some of the reasons why wrapping your commit messages to 72 columns is
a good thing.
- git log doesn’t do any special special wrapping of the commit messages. With
the default pager of less -S, this means your paragraphs flow far off the edge
of the screen, making them difficult to read. On an 80 column terminal, if we
subtract 4 columns for the indent on the left and 4 more for symmetry on the
right, we’re left with 72 columns.
- git format-patch --stdout converts a series of commits to a series of emails,
using the messages for the message body. Good email netiquette dictates we
wrap our plain text emails such that there’s room for a few levels of nested
reply indicators without overflow in an 80 column terminal.
## Code Approval Process
This section describes the code approval process that is used for code
contributions. This is how to get your changes into btcd.
## Code Review
All code which is submitted will need to be reviewed before inclusion into the
master branch. This process is performed by the project maintainers and usually
other committers who are interested in the area you are working in as well.
## Code Review Timeframe
The timeframe for a code review will vary greatly depending on factors such as
the number of other pull requests which need to be reviewed, the size and
complexity of the contribution, how well you followed the guidelines presented
on this page, and how easy it is for the reviewers to digest your commits. For
example, if you make one monolithic commit that makes sweeping changes to things
in multiple subsystems, it will obviously take much longer to review. You will
also likely be asked to split the commit into several smaller, and hence more
manageable, commits.
Keeping the above in mind, most small changes will be reviewed within a few
days, while large or far reaching changes may take weeks. This is a good reason
to stick with the [Share Early, Share Often](#ShareOften) development practice
outlined above.
## What is the review looking for?
The review is mainly ensuring the code follows the [Development Practices](#DevelopmentPractices)
and [Code Contribution Standards](#Standards). However, there are a few other
checks which are generally performed as follows:
- The code is stable and has no stability or security concerns
- The code is properly using existing APIs and generally fits well into the
overall architecture
- The change is not something which is deemed inappropriate by community
consensus
## Rework Code (if needed)
After the code review, the change will be accepted immediately if no issues are
found. If there are any concerns or questions, you will be provided with
feedback along with the next steps needed to get your contribution merged with
master. In certain cases the code reviewer(s) or interested committers may help
you rework the code, but generally you will simply be given feedback for you to
make the necessary changes.
This process will continue until the code is finally accepted.
## Acceptance
Once your code is accepted, it will be integrated with the master branch.
Typically it will be rebased and fast-forward merged to master as we prefer to
keep a clean commit history over a tangled weave of merge commits. However,
regardless of the specific merge method used, the code will be integrated with
the master branch and the pull request will be closed.
Rejoice as you will now be listed as a [contributor](https://github.com/btcsuite/btcd/graphs/contributors)!
## Contribution Standards
## Contribution Checklist
- [&nbsp;&nbsp;] All changes are Go version 1.3 compliant
- [&nbsp;&nbsp;] The code being submitted is commented according to the
[Code Documentation and Commenting](#CodeDocumentation) section
- [&nbsp;&nbsp;] For new code: Code is accompanied by tests which exercise both
the positive and negative (error paths) conditions (if applicable)
- [&nbsp;&nbsp;] For bug fixes: Code is accompanied by new tests which trigger
the bug being fixed to prevent regressions
- [&nbsp;&nbsp;] Any new logging statements use an appropriate subsystem and
logging level
- [&nbsp;&nbsp;] Code has been formatted with `go fmt`
- [&nbsp;&nbsp;] Running `go test` does not fail any tests
- [&nbsp;&nbsp;] Running `go vet` does not report any issues
- [&nbsp;&nbsp;] Running [golint](https://github.com/golang/lint) does not
report any **new** issues that did not already exist
## Licensing of Contributions
All contributions must be licensed with the
[ISC license](https://github.com/btcsuite/btcd/blob/master/LICENSE). This is
the same license as all of the code in the btcd suite.

110
docs/configuration.md
View file

@ -1,11 +1,11 @@
# Configuration
btcd has a number of [configuration](https://pkg.go.dev/github.com/btcsuite/btcd)
options, which can be viewed by running: `$ btcd --help`.
lbcd has a number of configuration
options, which can be viewed by running: `$ lbcd --help`.
## Peer server listen interface
btcd allows you to bind to specific interfaces which enables you to setup
lbcd allows you to bind to specific interfaces which enables you to setup
configurations with varying levels of complexity. The listen parameter can be
specified on the command line as shown below with the -- prefix or in the
configuration file without the -- prefix (as can all long command line options).
@ -16,42 +16,42 @@ interfaces as a couple of the examples below illustrate.
Command Line Examples:
|Flags|Comment|
|----------|------------|
|--listen=|all interfaces on default port which is changed by `--testnet` and `--regtest` (**default**)|
|--listen=0.0.0.0|all IPv4 interfaces on default port which is changed by `--testnet` and `--regtest`|
|--listen=::|all IPv6 interfaces on default port which is changed by `--testnet` and `--regtest`|
|--listen=:8333|all interfaces on port 8333|
|--listen=0.0.0.0:8333|all IPv4 interfaces on port 8333|
|--listen=[::]:8333|all IPv6 interfaces on port 8333|
|--listen=127.0.0.1:8333|only IPv4 localhost on port 8333|
|--listen=[::1]:8333|only IPv6 localhost on port 8333|
|--listen=:8336|all interfaces on non-standard port 8336|
|--listen=0.0.0.0:8336|all IPv4 interfaces on non-standard port 8336|
|--listen=[::]:8336|all IPv6 interfaces on non-standard port 8336|
|--listen=127.0.0.1:8337 --listen=[::1]:8333|IPv4 localhost on port 8337 and IPv6 localhost on port 8333|
|--listen=:8333 --listen=:8337|all interfaces on ports 8333 and 8337|
| Flags | Comment |
| ------------------------------------------- | -------------------------------------------------------------------------------------------- |
| --listen= | all interfaces on default port which is changed by `--testnet` and `--regtest` (**default**) |
| --listen=0.0.0.0 | all IPv4 interfaces on default port which is changed by `--testnet` and `--regtest` |
| --listen=:: | all IPv6 interfaces on default port which is changed by `--testnet` and `--regtest` |
| --listen=:9246 | all interfaces on port 9246 |
| --listen=0.0.0.0:9246 | all IPv4 interfaces on port 9246 |
| --listen=[::]:9246 | all IPv6 interfaces on port 9246 |
| --listen=127.0.0.1:9246 | only IPv4 localhost on port 9246 |
| --listen=[::1]:9246 | only IPv6 localhost on port 9246 |
| --listen=:9247 | all interfaces on non-standard port 9247 |
| --listen=0.0.0.0:9247 | all IPv4 interfaces on non-standard port 9247 |
| --listen=[::]:9247 | all IPv6 interfaces on non-standard port 9247 |
| --listen=127.0.0.1:9248 --listen=[::1]:9246 | IPv4 localhost on port 9248 and IPv6 localhost on port 9246 |
| --listen=:9246 --listen=:9248 | all interfaces on ports 9246 and 9248 |
The following config file would configure btcd to only listen on localhost for both IPv4 and IPv6:
The following config file would configure lbcd to only listen on localhost for both IPv4 and IPv6:
```text
[Application Options]
listen=127.0.0.1:8333
listen=[::1]:8333
listen=127.0.0.1:9246
listen=[::1]:9246
```
In addition, if you are starting btcd with TLS and want to make it
In addition, if you are starting lbcd with TLS and want to make it
available via a hostname, then you will need to generate the TLS
certificates for that host. For example,
```
gencerts --host=myhostname.example.com --directory=/home/me/.btcd/
gencerts --host=myhostname.example.com --directory=/home/me/.lbcd/
```
## RPC server listen interface
btcd allows you to bind the RPC server to specific interfaces which enables you
lbcd allows you to bind the RPC server to specific interfaces which enables you
to setup configurations with varying levels of complexity. The `rpclisten`
parameter can be specified on the command line as shown below with the -- prefix
or in the configuration file without the -- prefix (as can all long command line
@ -76,23 +76,23 @@ A few things to note regarding the RPC server:
Command Line Examples:
|Flags|Comment|
|----------|------------|
|--rpclisten=|all interfaces on default port which is changed by `--testnet`|
|--rpclisten=0.0.0.0|all IPv4 interfaces on default port which is changed by `--testnet`|
|--rpclisten=::|all IPv6 interfaces on default port which is changed by `--testnet`|
|--rpclisten=:8334|all interfaces on port 8334|
|--rpclisten=0.0.0.0:8334|all IPv4 interfaces on port 8334|
|--rpclisten=[::]:8334|all IPv6 interfaces on port 8334|
|--rpclisten=127.0.0.1:8334|only IPv4 localhost on port 8334|
|--rpclisten=[::1]:8334|only IPv6 localhost on port 8334|
|--rpclisten=:8336|all interfaces on non-standard port 8336|
|--rpclisten=0.0.0.0:8336|all IPv4 interfaces on non-standard port 8336|
|--rpclisten=[::]:8336|all IPv6 interfaces on non-standard port 8336|
|--rpclisten=127.0.0.1:8337 --listen=[::1]:8334|IPv4 localhost on port 8337 and IPv6 localhost on port 8334|
|--rpclisten=:8334 --listen=:8337|all interfaces on ports 8334 and 8337|
| Flags | Comment |
| ---------------------------------------------- | ------------------------------------------------------------------- |
| --rpclisten= | all interfaces on default port which is changed by `--testnet` |
| --rpclisten=0.0.0.0 | all IPv4 interfaces on default port which is changed by `--testnet` |
| --rpclisten=:: | all IPv6 interfaces on default port which is changed by `--testnet` |
| --rpclisten=:9245 | all interfaces on port 9245 |
| --rpclisten=0.0.0.0:9245 | all IPv4 interfaces on port 9245 |
| --rpclisten=[::]:9245 | all IPv6 interfaces on port 9245 |
| --rpclisten=127.0.0.1:9245 | only IPv4 localhost on port 9245 |
| --rpclisten=[::1]:9245 | only IPv6 localhost on port 9245 |
| --rpclisten=:9247 | all interfaces on non-standard port 9247 |
| --rpclisten=0.0.0.0:9247 | all IPv4 interfaces on non-standard port 9247 |
| --rpclisten=[::]:9247 | all IPv6 interfaces on non-standard port 9247 |
| --rpclisten=127.0.0.1:9248 --listen=[::1]:9245 | IPv4 localhost on port 9248 and IPv6 localhost on port 9245 |
| --rpclisten=:9245 --listen=:9248 | all interfaces on ports 9245 and 9248 |
The following config file would configure the btcd RPC server to listen to all interfaces on the default port, including external interfaces, for both IPv4 and IPv6:
The following config file would configure the lbcd RPC server to listen to all interfaces on the default port, including external interfaces, for both IPv4 and IPv6:
```text
[Application Options]
@ -102,21 +102,21 @@ rpclisten=
## Default ports
While btcd is highly configurable when it comes to the network configuration,
While lbcd is highly configurable when it comes to the network configuration,
the following is intended to be a quick reference for the default ports used so
port forwarding can be configured as required.
btcd provides a `--upnp` flag which can be used to automatically map the bitcoin
lbcd by default will automatically map the
peer-to-peer listening port if your router supports UPnP. If your router does
not support UPnP, or you don't wish to use it, please note that only the bitcoin
not support UPnP, or you don't wish to use it, please note that only the
peer-to-peer port should be forwarded unless you specifically want to allow RPC
access to your btcd from external sources such as in more advanced network
configurations.
access to your lbcd from external sources such as in more advanced network
configurations. You can disable UPnP with the `--noupnp` daemon option.
|Name|Port|
|----|----|
|Default Bitcoin peer-to-peer port|TCP 8333|
|Default RPC port|TCP 8334|
| Name | Port |
| ------------------------- | -------- |
| Default peer-to-peer port | TCP 9246 |
| Default RPC port | TCP 9245 |
## Using bootstrap.dat
@ -129,7 +129,7 @@ on the last time it was updated.
See [this](https://bitcointalk.org/index.php?topic=145386.0) thread on
bitcointalk for more details.
**NOTE:** Using bootstrap.dat is entirely optional. Btcd will download the
**NOTE:** Using bootstrap.dat is entirely optional. lbcd will download the
block chain from other peers through the Bitcoin protocol with no extra
configuration needed.
@ -165,14 +165,14 @@ checkpoints for the known-good block chain at periodic intervals. This ensures
that not only is it a valid chain, but it is the same chain that everyone else
is using.
### How do I use bootstrap.dat with btcd?
### How do I use bootstrap.dat with lbcd?
btcd comes with a separate utility named `addblock` which can be used to import
lbcd comes with a separate utility named `addblock` which can be used to import
`bootstrap.dat`. This approach is used since the import is a one-time operation
and we prefer to keep the daemon itself as lightweight as possible.
1. Stop btcd if it is already running. This is required since addblock needs to
access the database used by btcd and it will be locked if btcd is using it.
1. Stop lbcd if it is already running. This is required since addblock needs to
access the database used by lbcd and it will be locked if lbcd is using it.
2. Note the path to the downloaded bootstrap.dat file.
3. Run the addblock utility with the `-i` argument pointing to the location of
boostrap.dat:
@ -180,7 +180,7 @@ and we prefer to keep the daemon itself as lightweight as possible.
**Windows:**
```bat
"%PROGRAMFILES%\Btcd Suite\Btcd\addblock" -i C:\Path\To\bootstrap.dat
"%PROGRAMFILES%\lbcd Suite\lbcd\addblock" -i C:\Path\To\bootstrap.dat
```
**Linux/Unix/BSD/POSIX:**

34
docs/configuring_tor.md
View file

@ -1,9 +1,9 @@
# Configuring TOR
btcd provides full support for anonymous networking via the
lbcd provides full support for anonymous networking via the
[Tor Project](https://www.torproject.org/), including [client-only](#Client)
and [hidden service](#HiddenService) configurations along with
[stream isolation](#TorStreamIsolation). In addition, btcd supports a hybrid,
[stream isolation](#TorStreamIsolation). In addition, lbcd supports a hybrid,
[bridge mode](#Bridge) which is not anonymous, but allows it to operate as a
bridge between regular nodes and hidden service nodes without routing the
regular connections through Tor.
@ -15,15 +15,15 @@ hidden service for this reason.
## Client-only
Configuring btcd as a Tor client is straightforward. The first step is
Configuring lbcd as a Tor client is straightforward. The first step is
obviously to install Tor and ensure it is working. Once that is done, all that
typically needs to be done is to specify the `--proxy` flag via the btcd command
line or in the btcd configuration file. Typically the Tor proxy address will be
typically needs to be done is to specify the `--proxy` flag via the lbcd command
line or in the lbcd configuration file. Typically the Tor proxy address will be
127.0.0.1:9050 (if using standalone Tor) or 127.0.0.1:9150 (if using the Tor
Browser Bundle). If you have Tor configured to require a username and password,
you may specify them with the `--proxyuser` and `--proxypass` flags.
By default, btcd assumes the proxy specified with `--proxy` is a Tor proxy and
By default, lbcd assumes the proxy specified with `--proxy` is a Tor proxy and
hence will send all traffic, including DNS resolution requests, via the
specified proxy.
@ -34,7 +34,7 @@ not be reachable for inbound connections unless you also configure a Tor
### Command line example
```bash
./btcd --proxy=127.0.0.1:9050
./lbcd --proxy=127.0.0.1:9050
```
### Config file example
@ -51,7 +51,7 @@ The first step is to configure Tor to provide a hidden service. Documentation
for this can be found on the Tor project website
[here](https://www.torproject.org/docs/tor-hidden-service.html.en). However,
there is no need to install a web server locally as the linked instructions
discuss since btcd will act as the server.
discuss since lbcd will act as the server.
In short, the instructions linked above entail modifying your `torrc` file to
add something similar to the following, restarting Tor, and opening the
@ -59,12 +59,12 @@ add something similar to the following, restarting Tor, and opening the
address.
```text
HiddenServiceDir /var/tor/btcd
HiddenServicePort 8333 127.0.0.1:8333
HiddenServiceDir /var/tor/lbcd
HiddenServicePort 9246 127.0.0.1:9246
```
Once Tor is configured to provide the hidden service and you have obtained your
generated .onion address, configuring btcd as a Tor hidden service requires
generated .onion address, configuring lbcd as a Tor hidden service requires
three flags:
* `--proxy` to identify the Tor (SOCKS 5) proxy to use for outgoing traffic.
@ -76,7 +76,7 @@ three flags:
### Command line example
```bash
./btcd --proxy=127.0.0.1:9050 --listen=127.0.0.1 --externalip=fooanon.onion
./lbcd --proxy=127.0.0.1:9050 --listen=127.0.0.1 --externalip=fooanon.onion
```
### Config file example
@ -91,13 +91,13 @@ externalip=fooanon.onion
## Bridge mode (not anonymous)
btcd provides support for operating as a bridge between regular nodes and hidden
lbcd provides support for operating as a bridge between regular nodes and hidden
service nodes. In particular this means only traffic which is directed to or
from a .onion address is sent through Tor while other traffic is sent normally.
_As a result, this mode is **NOT** anonymous._
This mode works by specifying an onion-specific proxy, which is pointed at Tor,
by using the `--onion` flag via the btcd command line or in the btcd
by using the `--onion` flag via the lbcd command line or in the lbcd
configuration file. If you have Tor configured to require a username and
password, you may specify them with the `--onionuser` and `--onionpass` flags.
@ -111,7 +111,7 @@ routed via Tor due to the `--onion` flag.
### Command line example
```bash
./btcd --onion=127.0.0.1:9050 --externalip=fooanon.onion
./lbcd --onion=127.0.0.1:9050 --externalip=fooanon.onion
```
### Config file example
@ -128,13 +128,13 @@ externalip=fooanon.onion
Tor stream isolation forces Tor to build a new circuit for each connection
making it harder to correlate connections.
btcd provides support for Tor stream isolation by using the `--torisolation`
lbcd provides support for Tor stream isolation by using the `--torisolation`
flag. This option requires --proxy or --onionproxy to be set.
### Command line example
```bash
./btcd --proxy=127.0.0.1:9050 --torisolation
./lbcd --proxy=127.0.0.1:9050 --torisolation
```
### Config file example

15
docs/contact.md
View file

@ -1,15 +0,0 @@
# Contact
## IRC
* [irc.libera.chat](irc://irc.libera.chat), channel `#btcd`
## Mailing Lists
* [btcd](mailto:btcd+subscribe@opensource.conformal.com): discussion of btcd and its packages.
* [btcd-commits](mailto:btcd-commits+subscribe@opensource.conformal.com): readonly mail-out of source code changes.
## Issue Tracker
The [integrated github issue tracker](https://github.com/btcsuite/btcd/issues)
is used for this project.

12
docs/controlling.md
View file

@ -1,11 +1,11 @@
# Controlling and querying btcd via btcctl
# Controlling and querying lbcd via lbcctl
btcctl is a command line utility that can be used to both control and query btcd
via [RPC](http://www.wikipedia.org/wiki/Remote_procedure_call). btcd does
lbcctl is a command line utility that can be used to both control and query lbcd
via [RPC](http://www.wikipedia.org/wiki/Remote_procedure_call). lbcd does
**not** enable its RPC server by default; You must configure at minimum both an
RPC username and password or both an RPC limited username and password:
* btcd.conf configuration file
* lbcd.conf configuration file
```bash
[Application Options]
@ -15,7 +15,7 @@ rpclimituser=mylimituser
rpclimitpass=Limitedp4ssw0rd
```
* btcctl.conf configuration file
* lbcctl.conf configuration file
```bash
[Application Options]
@ -31,4 +31,4 @@ rpclimituser=mylimituser
rpclimitpass=Limitedp4ssw0rd
```
For a list of available options, run: `$ btcctl --help`
For a list of available options, run: `$ lbcctl --help`

37
docs/developer_resources.md
View file

@ -1,37 +0,0 @@
# Developer Resources
* [Code Contribution Guidelines](https://github.com/btcsuite/btcd/tree/master/docs/code_contribution_guidelines.md)
* [JSON-RPC Reference](https://github.com/btcsuite/btcd/tree/master/docs/json_rpc_api.md)
* [RPC Examples](https://github.com/btcsuite/btcd/tree/master/docs/json_rpc_api.md#ExampleCode)
* The btcsuite Bitcoin-related Go Packages:
* [btcrpcclient](https://github.com/btcsuite/btcd/tree/master/rpcclient) - Implements a
robust and easy to use Websocket-enabled Bitcoin JSON-RPC client
* [btcjson](https://github.com/btcsuite/btcd/tree/master/btcjson) - Provides an extensive API
for the underlying JSON-RPC command and return values
* [wire](https://github.com/btcsuite/btcd/tree/master/wire) - Implements the
Bitcoin wire protocol
* [peer](https://github.com/btcsuite/btcd/tree/master/peer) -
Provides a common base for creating and managing Bitcoin network peers.
* [blockchain](https://github.com/btcsuite/btcd/tree/master/blockchain) -
Implements Bitcoin block handling and chain selection rules
* [blockchain/fullblocktests](https://github.com/btcsuite/btcd/tree/master/blockchain/fullblocktests) -
Provides a set of block tests for testing the consensus validation rules
* [txscript](https://github.com/btcsuite/btcd/tree/master/txscript) -
Implements the Bitcoin transaction scripting language
* [btcec](https://github.com/btcsuite/btcd/tree/master/btcec) - Implements
support for the elliptic curve cryptographic functions needed for the
Bitcoin scripts
* [database](https://github.com/btcsuite/btcd/tree/master/database) -
Provides a database interface for the Bitcoin block chain
* [mempool](https://github.com/btcsuite/btcd/tree/master/mempool) -
Package mempool provides a policy-enforced pool of unmined bitcoin
transactions.
* [btcutil](https://github.com/btcsuite/btcutil) - Provides Bitcoin-specific
convenience functions and types
* [chainhash](https://github.com/btcsuite/btcd/tree/master/chaincfg/chainhash) -
Provides a generic hash type and associated functions that allows the
specific hash algorithm to be abstracted.
* [connmgr](https://github.com/btcsuite/btcd/tree/master/connmgr) -
Package connmgr implements a generic Bitcoin network connection manager.

48
docs/index.md
View file

@ -1,57 +1,11 @@
# btcd
# lbcd
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd)
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
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.
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
blog entry [here](https://web.archive.org/web/20171125143919/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.
## Documentation
Documentation is a work-in-progress. It is available at [btcd.readthedocs.io](https://btcd.readthedocs.io).
## Contents
* [Installation](installation.md)
* [Update](update.md)
* [Configuration](configuration.md)
* [Configuring TOR](configuring_tor.md)
* [Docker](using_docker.md)
* [Controlling](controlling.md)
* [Mining](mining.md)
* [Wallet](wallet.md)
* [Developer resources](developer_resources.md)
* [JSON RPC API](json_rpc_api.md)
* [Code contribution guidelines](code_contribution_guidelines.md)
* [Contact](contact.md)
## License
btcd is licensed under the [copyfree](http://copyfree.org) ISC License.

76
docs/installation.md
View file

@ -1,76 +0,0 @@
# Installation
The first step is to install btcd. See one of the following sections for
details on how to install on the supported operating systems.
## Requirements
[Go](http://golang.org) 1.16 or newer.
## 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:
* Download the Conformal public key:
https://raw.githubusercontent.com/btcsuite/btcd/master/release/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
```
## Windows Installation
* Install the MSI available at: [btcd windows installer](https://github.com/btcsuite/btcd/releases)
* Launch btcd from the Start Menu
## Linux/BSD/MacOSX/POSIX Installation
* Install Go according to the [installation instructions](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:
```bash
git clone https://github.com/btcsuite/btcd $GOPATH/src/github.com/btcsuite/btcd
cd $GOPATH/src/github.com/btcsuite/btcd
GO111MODULE=on go install -v . ./cmd/...
```
* 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.
## Gentoo Linux Installation
* [Install Layman](https://gitlab.com/bitcoin/gentoo) and enable the Bitcoin overlay.
* Copy or symlink `/var/lib/layman/bitcoin/Documentation/package.keywords/btcd-live` to `/etc/portage/package.keywords/`
* Install btcd: `$ emerge net-p2p/btcd`
## Startup
Typically btcd will run and start downloading the block chain with no extra
configuration necessary, however, there is an optional method to use a
`bootstrap.dat` file that may speed up the initial block chain download process.
* [Using bootstrap.dat](https://github.com/btcsuite/btcd/blob/master/docs/configuration.md#using-bootstrapdat)

1160
docs/json_rpc_api.md
View file

File diff suppressed because it is too large Load diff

16
docs/mining.md
View file

@ -1,6 +1,6 @@
# Mining
btcd supports the `getblocktemplate` RPC.
lbcd supports the `getblocktemplate` RPC.
The limited user cannot access this RPC.
## Add the payment addresses with the `miningaddr` option
@ -13,18 +13,20 @@ miningaddr=12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX
miningaddr=1M83ju3EChKYyysmM2FXtLNftbacagd8FR
```
## Add btcd's RPC TLS certificate to system Certificate Authority list
## Add lbcd's RPC TLS certificate to system Certificate Authority list
`cgminer` uses [curl](http://curl.haxx.se/) to fetch data from the RPC server.
Since curl validates the certificate by default, we must install the `btcd` RPC
Various miners use [curl](http://curl.haxx.se/) to fetch data from the RPC server.
Since curl validates the certificate by default, we must install the `lbcd` RPC
certificate into the default system Certificate Authority list.
## Ubuntu
1. Copy rpc.cert to /usr/share/ca-certificates: `# cp /home/user/.btcd/rpc.cert /usr/share/ca-certificates/btcd.crt`
2. Add btcd.crt to /etc/ca-certificates.conf: `# echo btcd.crt >> /etc/ca-certificates.conf`
1. Copy rpc.cert to /usr/share/ca-certificates: `# cp /home/user/.lbcd/rpc.cert /usr/share/ca-certificates/lbcd.crt`
2. Add lbcd.crt to /etc/ca-certificates.conf: `# echo lbcd.crt >> /etc/ca-certificates.conf`
3. Update the CA certificate list: `# update-ca-certificates`
## Set your mining software url to use https
`cgminer -o https://127.0.0.1:8334 -u rpcuser -p rpcpassword`
`cgminer -o https://127.0.0.1:9245 -u rpcuser -p rpcpassword`
Alternatively, you can disable TLS with the `--notls` option for the server.

13
docs/table_of_content.md
View file

@ -1,13 +0,0 @@
# Contents
* [Installation](installation.md)
* [Update](update.md)
* [Configuration](configuration.md)
* [Configuring TOR](configuring_tor.md)
* [Controlling](controlling.md)
* [Mining](mining.md)
* [Wallet](wallet.md)
* [Developer resources](developer_resources.md)
* [JSON RPC API](json_rpc_api.md)
* [Code contribution guidelines](code_contribution_guidelines.md)
* [Contact](contact.md)

8
docs/update.md
View file

@ -1,8 +0,0 @@
# Update
* Run the following commands to update btcd, all dependencies, and install it:
```bash
cd $GOPATH/src/github.com/btcsuite/btcd
git pull && GO111MODULE=on go install -v . ./cmd/...
```

160
docs/using_docker.md
View file

@ -1,160 +0,0 @@
# Using Docker
- [Using Docker](#using-docker)
- [Introduction](#introduction)
- [Docker volumes](#docker-volumes)
- [Known error messages when starting the btcd container](#known-error-messages-when-starting-the-btcd-container)
- [Examples](#examples)
- [Preamble](#preamble)
- [Full node without RPC port](#full-node-without-rpc-port)
- [Full node with RPC port](#full-node-with-rpc-port)
- [Full node with RPC port running on TESTNET](#full-node-with-rpc-port-running-on-testnet)
## Introduction
With Docker you can easily set up *btcd* to run your Bitcoin full node. You can find the official *btcd* Docker images on Docker Hub [btcsuite/btcd](https://hub.docker.com/r/btcsuite/btcd). The Docker source file of this image is located at [Dockerfile](https://github.com/btcsuite/btcd/blob/master/Dockerfile).
This documentation focuses on running Docker container with *docker-compose.yml* files. These files are better to read and you can use them as a template for your own use. For more information about Docker and Docker compose visit the official [Docker documentation](https://docs.docker.com/).
## Docker volumes
**Special diskspace hint**: The following examples are using a Docker managed volume. The volume is named *btcd-data* This will use a lot of disk space, because it contains the full Bitcoin blockchain. Please make yourself familiar with [Docker volumes](https://docs.docker.com/storage/volumes/).
The *btcd-data* volume will be reused, if you upgrade your *docker-compose.yml* file. Keep in mind, that it is not automatically removed by Docker, if you delete the btcd container. If you don't need the volume anymore, please delete it manually with the command:
```bash
docker volume ls
docker volume rm btcd-data
```
For binding a local folder to your *btcd* container please read the [Docker documentation](https://docs.docker.com/). The preferred way is to use a Docker managed volume.
## Known error messages when starting the btcd container
We pass all needed arguments to *btcd* as command line parameters in our *docker-compose.yml* file. It doesn't make sense to create a *btcd.conf* file. This would make things too complicated. Anyhow *btcd* will complain with following log messages when starting. These messages can be ignored:
```bash
Error creating a default config file: open /sample-btcd.conf: no such file or directory
...
[WRN] BTCD: open /root/.btcd/btcd.conf: no such file or directory
```
## Examples
### Preamble
All following examples uses some defaults:
- container_name: btcd
Name of the docker container that is be shown by e.g. ```docker ps -a```
- hostname: btcd **(very important to set a fixed name before first start)**
The internal hostname in the docker container. By default, docker is recreating the hostname every time you change the *docker-compose.yml* file. The default hostnames look like *ef00548d4fa5*. This is a problem when using the *btcd* RPC port. The RPC port is using a certificate to validate the hostname. If the hostname changes you need to recreate the certificate. To avoid this, you should set a fixed hostname before the first start. This ensures, that the docker volume is created with a certificate with this hostname.
- restart: unless-stopped
Starts the *btcd* container when Docker starts, except that when the container is stopped (manually or otherwise), it is not restarted even after Docker restarts.
To use the following examples create an empty directory. In this directory create a file named *docker-compose.yml*, copy and paste the example into the *docker-compose.yml* file and run it.
```bash
mkdir ~/btcd-docker
cd ~/btcd-docker
touch docker-compose.yaml
nano docker-compose.yaml (use your favourite editor to edit the compose file)
docker-compose up (creates and starts a new btcd container)
```
With the following commands you can control *docker-compose*:
```docker-compose up -d``` (creates and starts the container in background)
```docker-compose down``` (stops and delete the container. **The docker volume btcd-data will not be deleted**)
```docker-compose stop``` (stops the container)
```docker-compose start``` (starts the container)
```docker ps -a``` (list all running and stopped container)
```docker volume ls``` (lists all docker volumes)
```docker logs btcd``` (shows the log )
```docker-compose help``` (brings up some helpful information)
### Full node without RPC port
Let's start with an easy example. If you just want to create a full node without the need of using the RPC port, you can use the following example. This example will launch *btcd* and exposes only the default p2p port 8333 to the outside world:
```yaml
version: "2"
services:
btcd:
container_name: btcd
hostname: btcd
image: btcsuite/btcd:latest
restart: unless-stopped
volumes:
- btcd-data:/root/.btcd
ports:
- 8333:8333
volumes:
btcd-data:
```
### Full node with RPC port
To use the RPC port of *btcd* you need to specify a *username* and a very strong *password*. If you want to connect to the RPC port from the internet, you need to expose port 8334(RPC) as well.
```yaml
version: "2"
services:
btcd:
container_name: btcd
hostname: btcd
image: btcsuite/btcd:latest
restart: unless-stopped
volumes:
- btcd-data:/root/.btcd
ports:
- 8333:8333
- 8334:8334
command: [
"--rpcuser=[CHOOSE_A_USERNAME]",
"--rpcpass=[CREATE_A_VERY_HARD_PASSWORD]"
]
volumes:
btcd-data:
```
### Full node with RPC port running on TESTNET
To run a node on testnet, you need to provide the *--testnet* argument. The ports for testnet are 18333 (p2p) and 18334 (RPC):
```yaml
version: "2"
services:
btcd:
container_name: btcd
hostname: btcd
image: btcsuite/btcd:latest
restart: unless-stopped
volumes:
- btcd-data:/root/.btcd
ports:
- 18333:18333
- 18334:18334
command: [
"--testnet",
"--rpcuser=[CHOOSE_A_USERNAME]",
"--rpcpass=[CREATE_A_VERY_HARD_PASSWORD]"
]
volumes:
btcd-data:
```

5
docs/wallet.md
View file

@ -1,5 +0,0 @@
# Wallet
btcd was intentionally developed without an integrated wallet for security
reasons. Please see [btcwallet](https://github.com/btcsuite/btcwallet) for more
information.

7
integration/README.md
View file

@ -1,13 +1,8 @@
integration
===========
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
This contains integration tests which make use of the
[rpctest](https://github.com/btcsuite/btcd/tree/master/integration/rpctest)
[rpctest](https://github.com/lbryio/lbcd/tree/master/integration/rpctest)
package to programmatically drive nodes via RPC.
## License
This code is licensed under the [copyfree](http://copyfree.org) ISC License.

14
integration/rpctest/README.md
View file

@ -1,9 +1,7 @@
rpctest
=======
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/integration/rpctest)
Package rpctest provides a btcd-specific RPC testing harness crafting and
executing integration tests by driving a `btcd` instance via the `RPC`
@ -16,15 +14,3 @@ This package was designed specifically to act as an RPC testing harness for
`btcd`. However, the constructs presented are general enough to be adapted to
any project wishing to programmatically drive a `btcd` instance of its
systems/integration tests.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/integration/rpctest
```
## License
Package rpctest is licensed under the [copyfree](http://copyfree.org) ISC
License.

18
mempool/README.md
View file

@ -1,9 +1,7 @@
mempool
=======
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/mempool)
Package mempool provides a policy-enforced pool of unmined bitcoin transactions.
@ -33,11 +31,6 @@ proceed. Typically, this will involve things such as relaying the transactions
to other peers on the network and notifying the mining process that new
transactions are available.
This package has intentionally been designed so it can be used as a standalone
package for any projects needing the ability create an in-memory pool of bitcoin
transactions that are not only valid by consensus rules, but also adhere to a
configurable policy.
## Feature Overview
The following is a quick overview of the major features. It is not intended to
@ -70,14 +63,3 @@ be an exhaustive list.
- The starting priority for the transaction
- Manual control of transaction removal
- Recursive removal of all dependent transactions
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/mempool
```
## License
Package mempool is licensed under the [copyfree](http://copyfree.org) ISC
License.

15
mining/README.md
View file

@ -1,21 +1,8 @@
mining
======
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/mining)
## Overview
This package is currently a work in progress.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/mining
```
## License
Package mining is licensed under the [copyfree](http://copyfree.org) ISC
License.
This package is currently a work in progress.

6
mining/cpuminer/README.md
View file

@ -1,9 +1,9 @@
cpuminer
========
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/mining/cpuminer)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/lbryio/lbcd/mining/cpuminer)
=======
## Overview
@ -16,7 +16,7 @@ now.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/mining/cpuminer
$ go get -u github.com/lbryio/lbcd/mining/cpuminer
```
## License

12
netsync/README.md
View file

@ -1,9 +1,7 @@
netsync
=======
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/netsync)
## Overview
@ -13,13 +11,3 @@ download, keep the chain and unconfirmed transaction pool in sync, and announce
new blocks connected to the chain. Currently the sync manager selects a single
sync peer that it downloads all blocks from until it is up to date with the
longest chain the sync peer is aware of.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/netsync
```
## License
Package netsync is licensed under the [copyfree](http://copyfree.org) ISC License.

23
peer/README.md
View file

@ -1,16 +1,11 @@
peer
====
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/peer)
Package peer provides a common base for creating and managing bitcoin network
peers.
This package has intentionally been designed so it can be used as a standalone
package for any projects needing a full featured bitcoin peer base to build on.
## Overview
This package builds upon the wire package, which provides the fundamental
@ -54,20 +49,4 @@ A quick overview of the major features peer provides are as follows:
filtering and address randomization
- Ability to wait for shutdown/disconnect
- Comprehensive test coverage
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/peer
```
## Examples
* [New Outbound Peer Example](https://pkg.go.dev/github.com/btcsuite/btcd/peer#example-package--NewOutboundPeer)
Demonstrates the basic process for initializing and creating an outbound peer.
Peers negotiate by exchanging version and verack messages. For demonstration,
a simple handler for the version message is attached to the peer.
## License
Package peer is licensed under the [copyfree](http://copyfree.org) ISC License.

181
release/README.md
View file

@ -1,181 +0,0 @@
# `btcd`'s Reproducible Build System
This package contains the build script that the `btcd` project uses in order to
build binaries for each new release. As of `go1.13`, with some new build flags,
binaries are now reproducible, allowing developers to build the binary on
distinct machines, and end up with a byte-for-byte identical binary.
Every release should note which Go version was used to build the release, so
that version should be used for verifying the release.
## Building a New Release
### Tagging and pushing a new tag (for maintainers)
Before running release scripts, a few things need to happen in order to finally
create a release and make sure there are no mistakes in the release process.
First, make sure that before the tagged commit there are modifications to the
[CHANGES](../CHANGES) file committed.
The CHANGES file should be a changelog that roughly mirrors the release notes.
Generally, the PRs that have been merged since the last release have been
listed in the CHANGES file and categorized.
For example, these changes have had the following format in the past:
```
Changes in X.YY.Z (Month Day Year):
- Protocol and Network-related changes:
- PR Title One (#PRNUM)
- PR Title Two (#PRNUMTWO)
...
- RPC changes:
- Crypto changes:
...
- Contributors (alphabetical order):
- Contributor A
- Contributor B
- Contributor C
...
```
If the previous tag is, for example, `vA.B.C`, then you can get the list of
contributors (from `vA.B.C` until the current `HEAD`) using the following command:
```bash
git log vA.B.C..HEAD --pretty="%an" | sort | uniq
```
After committing changes to the CHANGES file, the tagged release commit
should be created.
The tagged commit should be a commit that bumps version numbers in `version.go`
and `cmd/btcctl/version.go`.
For example (taken from [f3ec130](https://github.com/btcsuite/btcd/commit/f3ec13030e4e828869954472cbc51ac36bee5c1d)):
```diff
diff --git a/cmd/btcctl/version.go b/cmd/btcctl/version.go
index 2195175c71..f65cacef7e 100644
--- a/cmd/btcctl/version.go
+++ b/cmd/btcctl/version.go
@@ -18,7 +18,7 @@ const semanticAlphabet = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqr
const (
appMajor uint = 0
appMinor uint = 20
- appPatch uint = 0
+ appPatch uint = 1
// appPreRelease MUST only contain characters from semanticAlphabet
// per the semantic versioning spec.
diff --git a/version.go b/version.go
index 92fd60fdd4..fba55b5a37 100644
--- a/version.go
+++ b/version.go
@@ -18,7 +18,7 @@ const semanticAlphabet = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqr
const (
appMajor uint = 0
appMinor uint = 20
- appPatch uint = 0
+ appPatch uint = 1
// appPreRelease MUST only contain characters from semanticAlphabet
// per the semantic versioning spec.
```
Next, this commit should be signed by the maintainer using `git commit -S`.
The commit should be tagged and signed with `git tag <TAG> -s`, and should be
pushed using `git push origin TAG`.
### Building a release on macOS/Linux/Windows (WSL)
No prior set up is needed on Linux or macOS is required in order to build the
release binaries. However, on Windows, the only way to build the release
binaries at the moment is by using the Windows Subsystem Linux. One can build
the release binaries following these steps:
1. `git clone https://github.com/btcsuite/btcd.git`
2. `cd btcd`
3. `./release/release.sh <TAG> # <TAG> is the name of the next release/tag`
This will then create a directory of the form `btcd-<TAG>` containing archives
of the release binaries for each supported operating system and architecture,
and a manifest file containing the hash of each archive.
### Pushing a release (for maintainers)
Now that the directory `btcd-<TAG>` is created, the manifest file needs to be
signed by a maintainer and the release files need to be published to GitHub.
Sign the `manifest-<TAG>.txt` file like so:
```sh
gpg --sign --detach-sig manifest-<TAG>.txt
```
This will create a file named `manifest-<TAG>.txt.sig`, which will must
be included in the release files later.
#### Note before publishing
Before publishing, go through the reproducible build process that is outlined
in this document with the files created from `release/release.sh`. This includes
verifying commit and tag signatures using `git verify-commit` and git `verify-tag`
respectively.
Now that we've double-checked everything and have all of the necessary files,
it's time to publish release files on GitHub.
Follow [this documentation](https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository)
to create a release using the GitHub UI, and make sure to write release notes
which roughly follow the format of [previous release notes](https://github.com/btcsuite/btcd/releases/tag/v0.20.1-beta).
This is different from the [CHANGES](../CHANGES) file, which should be before the
tagged commit in the git history.
Much of the information in the release notes will be the same as the CHANGES
file.
It's important to include the Go version used to produce the release files in
the release notes, so users know the correct version of Go to use to reproduce
and verify the build.
When following the GitHub documentation, include every file in the `btcd-<TAG>`
directory.
At this point, a signed commit and tag on that commit should be pushed to the main
branch. The directory created from running `release/release.sh` should be included
as release files in the GitHub release UI, and the `manifest-<TAG>.txt` file
signature, called `manifest-<TAG>.txt.sig`, should also be included.
A release notes document should be created and written in the GitHub release UI.
Once all of this is done, feel free to click `Publish Release`!
## Verifying a Release
With `go1.13`, it's now possible for third parties to verify release binaries.
Before this version of `go`, one had to trust the release manager(s) to build the
proper binary. With this new system, third parties can now _independently_ run
the release process, and verify that all the hashes of the release binaries
match exactly that of the release binaries produced by said third parties.
To verify a release, one must obtain the following tools (many of these come
installed by default in most Unix systems): `gpg`/`gpg2`, `shashum`, and
`tar`/`unzip`.
Once done, verifiers can proceed with the following steps:
1. Acquire the archive containing the release binaries for one's specific
operating system and architecture, and the manifest file along with its
signature.
2. Verify the signature of the manifest file with `gpg --verify
manifest-<TAG>.txt.sig`. This will require obtaining the PGP keys which
signed the manifest file, which are included in the release notes.
3. Recompute the `SHA256` hash of the archive with `shasum -a 256 <filename>`,
locate the corresponding one in the manifest file, and ensure they match
__exactly__.
At this point, verifiers can use the release binaries acquired if they trust
the integrity of the release manager(s). Otherwise, one can proceed with the
guide to verify the release binaries were built properly by obtaining `shasum`
and `go` (matching the same version used in the release):
4. Extract the release binaries contained within the archive, compute their
hashes as done above, and note them down.
5. Ensure `go` is installed, matching the same version as noted in the release
notes.
6. Obtain a copy of `btcd`'s source code with `git clone
https://github.com/btcsuite/btcd` and checkout the source code of the
release with `git checkout <TAG>`.
7. Proceed to verify the tag with `git verify-tag <TAG>` and compile the
binaries from source for the intended operating system and architecture with
`BTCDBUILDSYS=OS-ARCH ./release/release.sh <TAG>`.
8. Extract the archive found in the `btcd-<TAG>` directory created by the
release script and recompute the `SHA256` hash of the release binaries (btcd
and btcctl) with `shasum -a 256 <filename>`. These should match __exactly__
as the ones noted above.

37
rpcclient/README.md
View file

@ -1,13 +1,11 @@
rpcclient
=========
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/rpcclient)
rpcclient implements a Websocket-enabled Bitcoin JSON-RPC client package written
in [Go](http://golang.org/). It provides a robust and easy to use client for
interfacing with a Bitcoin RPC server that uses a btcd/bitcoin core compatible
interfacing with a Bitcoin RPC server that uses a lbcd/bitcoin core compatible
Bitcoin JSON-RPC API.
## Status
@ -16,26 +14,11 @@ This package is currently under active development. It is already stable and
the infrastructure is complete. However, there are still several RPCs left to
implement and the API is not stable yet.
## Documentation
* [API Reference](https://pkg.go.dev/github.com/btcsuite/btcd/rpcclient)
* [btcd Websockets Example](https://github.com/btcsuite/btcd/tree/master/rpcclient/examples/btcdwebsockets)
Connects to a btcd RPC server using TLS-secured websockets, registers for
block connected and block disconnected notifications, and gets the current
block count
* [btcwallet Websockets Example](https://github.com/btcsuite/btcd/tree/master/rpcclient/examples/btcwalletwebsockets)
Connects to a btcwallet RPC server using TLS-secured websockets, registers for
notifications about changes to account balances, and gets a list of unspent
transaction outputs (utxos) the wallet can sign
* [Bitcoin Core HTTP POST Example](https://github.com/btcsuite/btcd/tree/master/rpcclient/examples/bitcoincorehttp)
Connects to a bitcoin core RPC server using HTTP POST mode with TLS disabled
and gets the current block count
## Major Features
* Supports Websockets (btcd/btcwallet) and HTTP POST mode (bitcoin core)
* Provides callback and registration functions for btcd/btcwallet notifications
* Supports btcd extensions
* Supports Websockets (lbcd/lbcwallet) and HTTP POST mode (bitcoin core)
* Provides callback and registration functions for lbcd/lbcwallet notifications
* Supports lbcd extensions
* Translates to and from higher-level and easier to use Go types
* Offers a synchronous (blocking) and asynchronous API
* When running in Websockets mode (the default):
@ -43,14 +26,4 @@ implement and the API is not stable yet.
* Outstanding commands are automatically reissued
* Registered notifications are automatically reregistered
* Back-off support on reconnect attempts
## Installation
```bash
$ go get -u github.com/btcsuite/btcd/rpcclient
```
## License
Package rpcclient is licensed under the [copyfree](http://copyfree.org) ISC
License.

4
rpcclient/examples/bitcoincorehttp/README.md
View file

@ -10,7 +10,7 @@ block count.
The first step is to use `go get` to download and install the rpcclient package:
```bash
$ go get github.com/btcsuite/btcd/rpcclient
$ go get github.com/lbryio/lbcd/rpcclient
```
Next, modify the `main.go` source to specify the correct RPC username and
@ -24,7 +24,7 @@ password for the RPC server:
Finally, navigate to the example's directory and run it with:
```bash
$ cd $GOPATH/src/github.com/btcsuite/btcd/rpcclient/examples/bitcoincorehttp
$ cd $GOPATH/src/github.com/lbryio/lbcd/rpcclient/examples/bitcoincorehttp
$ go run *.go
```

4
rpcclient/examples/bitcoincorehttpbulk/README.md
View file

@ -8,7 +8,7 @@ This example shows how to use the rpclient package to connect to a Bitcoin Core
The first step is to use `go get` to download and install the rpcclient package:
```bash
$ go get github.com/btcsuite/btcd/rpcclient
$ go get github.com/lbryio/lbcd/rpcclient
```
Next, modify the `main.go` source to specify the correct RPC username and
@ -22,7 +22,7 @@ password for the RPC server:
Finally, navigate to the example's directory and run it with:
```bash
$ cd $GOPATH/src/github.com/btcsuite/btcd/rpcclient/examples/bitcoincorehttp
$ cd $GOPATH/src/github.com/lbryio/lbcd/rpcclient/examples/bitcoincorehttp
$ go run *.go
```

4
rpcclient/examples/btcdwebsockets/README.md
View file

@ -13,7 +13,7 @@ demonstrate clean shutdown.
The first step is to use `go get` to download and install the rpcclient package:
```bash
$ go get github.com/btcsuite/btcd/rpcclient
$ go get github.com/lbryio/lbcd/rpcclient
```
Next, modify the `main.go` source to specify the correct RPC username and
@ -27,7 +27,7 @@ password for the RPC server:
Finally, navigate to the example's directory and run it with:
```bash
$ cd $GOPATH/src/github.com/btcsuite/btcd/rpcclient/examples/btcdwebsockets
$ cd $GOPATH/src/github.com/lbryio/lbcd/rpcclient/examples/btcdwebsockets
$ go run *.go
```

4
rpcclient/examples/btcwalletwebsockets/README.md
View file

@ -14,7 +14,7 @@ demonstrate clean shutdown.
The first step is to use `go get` to download and install the rpcclient package:
```bash
$ go get github.com/btcsuite/btcd/rpcclient
$ go get github.com/lbryio/lbcd/rpcclient
```
Next, modify the `main.go` source to specify the correct RPC username and
@ -28,7 +28,7 @@ password for the RPC server:
Finally, navigate to the example's directory and run it with:
```bash
$ cd $GOPATH/src/github.com/btcsuite/btcd/rpcclient/examples/btcwalletwebsockets
$ cd $GOPATH/src/github.com/lbryio/lbcd/rpcclient/examples/btcwalletwebsockets
$ go run *.go
```

4
rpcclient/examples/customcommand/README.md
View file

@ -9,7 +9,7 @@ implementing the `name_show` command from Namecoin Core.
The first step is to use `go get` to download and install the rpcclient package:
```bash
$ go get github.com/btcsuite/btcd/rpcclient
$ go get github.com/lbryio/lbcd/rpcclient
```
Next, modify the `main.go` source to specify the correct RPC username and
@ -23,7 +23,7 @@ password for the RPC server of your Namecoin Core node:
Finally, navigate to the example's directory and run it with:
```bash
$ cd $GOPATH/src/github.com/btcsuite/btcd/rpcclient/examples/customcommand
$ cd $GOPATH/src/github.com/lbryio/lbcd/rpcclient/examples/customcommand
$ go run *.go
```

4
rpcclient/examples/customcommand/main.go
View file

@ -9,8 +9,8 @@ import (
"encoding/json"
"log"
"github.com/btcsuite/btcd/btcjson"
"github.com/btcsuite/btcd/rpcclient"
"github.com/lbryio/lbcd/btcjson"
"github.com/lbryio/lbcd/rpcclient"
)
// NameShowCmd defines the name_show JSON-RPC command.

44
sample-btcd.conf → sample-lbcd.conf
View file

@ -6,12 +6,12 @@
; The directory to store data such as the block chain and peer addresses. The
; block chain takes several GB, so this location must have a lot of free space.
; The default is ~/.btcd/data on POSIX OSes, $LOCALAPPDATA/Btcd/data on Windows,
; ~/Library/Application Support/Btcd/data on Mac OS, and $home/btcd/data on
; The default is ~/.lbcd/data on POSIX OSes, $LOCALAPPDATA/Lbcd/data on Windows,
; ~/Library/Application Support/Lbcd/data on Mac OS, and $home/lbcd/data on
; Plan9. Environment variables are expanded so they may be used. NOTE: Windows
; environment variables are typically %VARIABLE%, but they must be accessed with
; $VARIABLE here. Also, ~ is expanded to $LOCALAPPDATA on Windows.
; datadir=~/.btcd/data
; datadir=~/.lbcd/data
; ------------------------------------------------------------------------------
@ -52,7 +52,7 @@
; upnp=1
; Specify the external IP addresses your node is listening on. One address per
; line. btcd will not contact 3rd-party sites to obtain external ip addresses.
; line. lbcd will not contact 3rd-party sites to obtain external ip addresses.
; This means if you are behind NAT, your node will not be able to advertise a
; reachable address unless you specify it here or enable the 'upnp' option (and
; have a supported device).
@ -64,7 +64,7 @@
;
; Only one of the following two options, 'addpeer' and 'connect', may be
; specified. Both allow you to specify peers that you want to stay connected
; with, but the behavior is slightly different. By default, btcd will query DNS
; with, but the behavior is slightly different. By default, lbcd will query DNS
; to find peers to connect to, so unless you have a specific reason such as
; those described below, you probably won't need to modify anything here.
;
@ -86,9 +86,9 @@
; You may specify each IP address with or without a port. The default port will
; be added automatically if one is not specified here.
; addpeer=192.168.1.1
; addpeer=10.0.0.2:8333
; addpeer=10.0.0.2:9246
; addpeer=fe80::1
; addpeer=[fe80::2]:8333
; addpeer=[fe80::2]:9246
; Add persistent peers that you ONLY want to connect to as desired. One peer
; per line. You may specify each IP address with or without a port. The
@ -96,9 +96,9 @@
; NOTE: Specifying this option has other side effects as described above in
; the 'addpeer' versus 'connect' summary section.
; connect=192.168.1.1
; connect=10.0.0.2:8333
; connect=10.0.0.2:9246
; connect=fe80::1
; connect=[fe80::2]:8333
; connect=[fe80::2]:9246
; Maximum number of inbound and outbound peers.
; maxpeers=125
@ -121,7 +121,7 @@
; whitelist=192.168.0.0/24
; whitelist=fd00::/16
; Disable DNS seeding for peers. By default, when btcd starts, it will use
; Disable DNS seeding for peers. By default, when lbcd starts, it will use
; DNS to query for available peers to connect with.
; nodnsseed=1
@ -135,16 +135,16 @@
; listen=0.0.0.0
; All ipv6 interfaces on default port:
; listen=::
; All interfaces on port 8333:
; listen=:8333
; All ipv4 interfaces on port 8333:
; listen=0.0.0.0:8333
; All ipv6 interfaces on port 8333:
; listen=[::]:8333
; Only ipv4 localhost on port 8333:
; listen=127.0.0.1:8333
; Only ipv6 localhost on port 8333:
; listen=[::1]:8333
; All interfaces on port 9246:
; listen=:9246
; All ipv4 interfaces on port 9246:
; listen=0.0.0.0:9246
; All ipv6 interfaces on port 9246:
; listen=[::]:9246
; Only ipv4 localhost on port 9246:
; listen=127.0.0.1:9246
; Only ipv6 localhost on port 9246:
; listen=[::1]:9246
; Only ipv4 localhost on non-standard port 8336:
; listen=127.0.0.1:8336
; All interfaces on non-standard port 8336:
@ -172,7 +172,7 @@
; ------------------------------------------------------------------------------
; RPC server options - The following options control the built-in RPC server
; which is used to control and query information from a running btcd process.
; which is used to control and query information from a running lbcd process.
;
; NOTE: The RPC server is disabled by default if rpcuser AND rpcpass, or
; rpclimituser AND rpclimitpass, are not specified.
@ -335,7 +335,7 @@
; Debug logging level.
; Valid levels are {trace, debug, info, warn, error, critical}
; You may also specify <subsystem>=<level>,<subsystem2>=<level>,... to set
; log level for individual subsystems. Use btcd --debuglevel=show to list
; log level for individual subsystems. Use lbcd --debuglevel=show to list
; available subsystems.
; debuglevel=info

58
txscript/README.md
View file

@ -1,67 +1,15 @@
txscript
========
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/txscript?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/txscript)
Package txscript implements the bitcoin transaction script language. There is
a comprehensive test suite.
This package has intentionally been designed so it can be used as a standalone
package for any projects needing to use or validate bitcoin transaction scripts.
This package has been augmented to include support for LBRY's custom claim operations.
See https://lbry.tech/spec
## Bitcoin Scripts
Bitcoin provides a stack-based, FORTH-like language for the scripts in
the bitcoin transactions. This language is not turing complete
although it is still fairly powerful. A description of the language
can be found at https://en.bitcoin.it/wiki/Script
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/txscript
```
## Examples
* [Standard Pay-to-pubkey-hash Script](https://pkg.go.dev/github.com/btcsuite/btcd/txscript#example-PayToAddrScript)
Demonstrates creating a script which pays to a bitcoin address. It also
prints the created script hex and uses the DisasmString function to display
the disassembled script.
* [Extracting Details from Standard Scripts](https://pkg.go.dev/github.com/btcsuite/btcd/txscript#example-ExtractPkScriptAddrs)
Demonstrates extracting information from a standard public key script.
* [Manually Signing a Transaction Output](https://pkg.go.dev/github.com/btcsuite/btcd/txscript#example-SignTxOutput)
Demonstrates manually creating and signing a redeem transaction.
* [Counting Opcodes in Scripts](http://godoc.org/github.com/decred/dcrd/txscript#example-ScriptTokenizer)
Demonstrates creating a script tokenizer instance and using it to count the
number of opcodes a script contains.
## 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:
- 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
Package txscript is licensed under the [copyfree](http://copyfree.org) ISC
License.
can be found at https://en.bitcoin.it/wiki/Script

43
wire/README.md
View file

@ -1,26 +1,14 @@
wire
====
[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
[![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/wire)
=======
Package wire implements the bitcoin wire protocol. A comprehensive suite of
tests with 100% test coverage is provided to ensure proper functionality.
There is an associated blog post about the release of this package
[here](https://blog.conformal.com/btcwire-the-bitcoin-wire-protocol-package-from-btcd/).
This package has intentionally been designed so it can be used as a standalone
package for any projects needing to interface with bitcoin peers at the wire
protocol level.
## Installation and Updating
```bash
$ go get -u github.com/btcsuite/btcd/wire
```
This package has been augmented from the original btcd implementation.
The block header was modified to contain the claimtrie hash.
## Bitcoin Message Overview
@ -85,29 +73,4 @@ from a remote peer is:
if err != nil {
// Log and handle the error
}
```
## 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:
- 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
Package wire is licensed under the [copyfree](http://copyfree.org) ISC
License.
```