[lbry] docs: update docs for LBRY
Co-authored-by: Roy Lee <roylee17@gmail.com>
This commit is contained in:
Brannon King
Roy Lee
parent
1b823c055f
commit
4dd4505706
47 changed files with 836 additions and 3414 deletions
1
LICENSE
1
LICENSE
|
|
@ -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
168
README.md
|
|
@ -1,121 +1,133 @@
|
|||
btcd
|
||||
====
|
||||
# lbcd
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](https://coveralls.io/github/btcsuite/btcd?branch=master)
|
||||
[](https://github.com/lbryio/lbcd/actions)
|
||||
[](https://coveralls.io/github/lbryio/lbcd?branch=master)
|
||||
[](http://copyfree.org)
|
||||
[](https://pkg.go.dev/github.com/btcsuite/btcd)
|
||||
<!--[](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 --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 --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 --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 --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.
|
||||
|
|
|
|||
|
|
@ -1,30 +1,9 @@
|
|||
blockchain
|
||||
==========
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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
|
||||
|
|
@ -58,46 +37,3 @@ is by no means exhaustive:
|
|||
- 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.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
fullblocktests
|
||||
==============
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](https://github.com/lbryio/lbcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain/fullblocktests)
|
||||
[](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
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
indexers
|
||||
========
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](https://github.com/lbryio/lbcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain/indexers)
|
||||
[](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
|
||||
|
|
|
|||
|
|
@ -1,68 +1,11 @@
|
|||
btcec
|
||||
=====
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
|
@ -1,70 +1,8 @@
|
|||
btcjson
|
||||
=======
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
|
|
|||
|
|
@ -1,85 +1,8 @@
|
|||
chaincfg
|
||||
========
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
|
@ -1,9 +1,9 @@
|
|||
chainhash
|
||||
=========
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](https://github.com/lbryio/lbcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](https://pkg.go.dev/github.com/btcsuite/btcd/chaincfg/chainhash)
|
||||
[](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
|
||||
|
|
|
|||
|
|
@ -1,13 +1,11 @@
|
|||
connmgr
|
||||
=======
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
database
|
||||
========
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
|
@ -33,25 +31,3 @@ storage, and strict checksums in key areas to ensure data integrity.
|
|||
- 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.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
ffldb
|
||||
=====
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](https://github.com/lbryio/lbcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](https://pkg.go.dev/github.com/btcsuite/btcd/database/ffldb)
|
||||
[](https://pkg.go.dev/github.com/lbryio/lbcd/database/ffldb)
|
||||
=======
|
||||
|
||||
Package ffldb implements a driver for the database package that uses leveldb for
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
treap
|
||||
=====
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](https://github.com/lbryio/lbcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](https://pkg.go.dev/github.com/btcsuite/btcd/database/internal/treap)
|
||||
[](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
6
doc.go
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
- [ ] All changes are Go version 1.3 compliant
|
||||
- [ ] The code being submitted is commented according to the
|
||||
[Code Documentation and Commenting](#CodeDocumentation) section
|
||||
- [ ] For new code: Code is accompanied by tests which exercise both
|
||||
the positive and negative (error paths) conditions (if applicable)
|
||||
- [ ] For bug fixes: Code is accompanied by new tests which trigger
|
||||
the bug being fixed to prevent regressions
|
||||
- [ ] Any new logging statements use an appropriate subsystem and
|
||||
logging level
|
||||
- [ ] Code has been formatted with `go fmt`
|
||||
- [ ] Running `go test` does not fail any tests
|
||||
- [ ] Running `go vet` does not report any issues
|
||||
- [ ] 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.
|
||||
|
|
@ -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:**
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -1,57 +1,11 @@
|
|||
# btcd
|
||||
# lbcd
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
1036
docs/json_rpc_api.md
1036
docs/json_rpc_api.md
File diff suppressed because it is too large
Load diff
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
@ -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/...
|
||||
```
|
||||
|
|
@ -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:
|
||||
```
|
||||
|
|
@ -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.
|
||||
|
|
@ -1,13 +1,8 @@
|
|||
integration
|
||||
===========
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](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.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
rpctest
|
||||
=======
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
mempool
|
||||
=======
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
|
|
|||
|
|
@ -1,21 +1,8 @@
|
|||
mining
|
||||
======
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
cpuminer
|
||||
========
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](https://github.com/lbryio/lbcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](https://pkg.go.dev/github.com/btcsuite/btcd/mining/cpuminer)
|
||||
[](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
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
netsync
|
||||
=======
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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.
|
||||
|
|
|
|||
|
|
@ -1,16 +1,11 @@
|
|||
peer
|
||||
====
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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
|
||||
|
|
@ -55,19 +50,3 @@ A quick overview of the major features peer provides are as follows:
|
|||
- 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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -1,13 +1,11 @@
|
|||
rpcclient
|
||||
=========
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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):
|
||||
|
|
@ -44,13 +27,3 @@ implement and the API is not stable yet.
|
|||
* 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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -124,7 +124,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
|
||||
|
||||
|
|
@ -138,16 +138,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:
|
||||
|
|
@ -185,7 +185,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.
|
||||
|
|
@ -369,7 +369,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
|
||||
|
||||
|
|
@ -1,15 +1,11 @@
|
|||
txscript
|
||||
========
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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
|
||||
|
||||
|
|
@ -17,51 +13,3 @@ 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.
|
||||
|
|
|
|||
|
|
@ -1,26 +1,14 @@
|
|||
wire
|
||||
====
|
||||
|
||||
[](https://github.com/btcsuite/btcd/actions)
|
||||
[](http://copyfree.org)
|
||||
[](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
|
||||
|
||||
|
|
@ -86,28 +74,3 @@ from a remote peer is:
|
|||
// 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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue