[lbry] docs: update docs for LBRY

Co-authored-by: Roy Lee <roylee17@gmail.com>
2021-08-19 14:41:48 -04:00 · 2021-08-19 14:41:48 -04:00 · 4e63bef33b
commit 4e63bef33b
parent a09c895f49
47 changed files with 836 additions and 3414 deletions
--- a/1230
+++ b/1230
--- a/1
+++ b/1
@ -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
--- a/README.md
+++ b/README.md
@ -1,121 +1,133 @@
-btcd
+# lbcd
 ====
-[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
+[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
-[![Coverage Status](https://coveralls.io/repos/github/btcsuite/btcd/badge.svg?branch=master)](https://coveralls.io/github/btcsuite/btcd?branch=master)
+[![Coverage Status](https://coveralls.io/repos/github/lbryio/lbcd/badge.svg?branch=master)](https://coveralls.io/github/lbryio/lbcd?branch=master)
 [![ISC License](https://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
-[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd)
+<!--[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/lbryio/lbcd)-->
-btcd is an alternative full node bitcoin implementation written in Go (golang).
+`lbcd` is a full node implementation of LBRY's blockchain written in Go (golang).
-This project is currently under active development and is in a Beta state.  It
+This project is currently under active development and is in a Beta state while
-is extremely stable and has been in production use since October 2013.
+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
+Note: `lbcd` does *NOT* include wallet functionality.  That functionality is provided by the
-rules (including consensus bugs) for block acceptance as Bitcoin Core.  We have
+[lbcwallet](https://github.com/lbryio/lbcwallet) and the [LBRY SDK](https://github.com/lbryio/lbry-sdk).
 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
+## Security
 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
+We take security seriously. Please contact [security](mailto:security@lbry.com) regarding any security issues.
-wallet functionality and this was a very intentional design decision.  See the
+Our PGP key is [here](https://lbry.com/faq/pgp-key) if you need it.
-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
+We maintain a mailing list for notifications of upgrades, security issues,
-directly with btcd.  That functionality is provided by the
+and soft/hard forks. To join, visit [fork list](https://lbry.com/forklist)
 [btcwallet](https://github.com/btcsuite/btcwallet) and
 [Paymetheus](https://github.com/btcsuite/Paymetheus) (Windows-only) projects
 which are both under active development.
 ## 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:
+Install Go according to its [installation instructions](http://golang.org/doc/install).
  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
+# Build lbcd
-$ go version
+go build .
-$ go env GOROOT GOPATH
+
 # Build lbcctl
 go build ./cmd/lbcctl
 ```
-NOTE: The `GOROOT` and `GOPATH` above must not be the same path.  It is
+Both [GoLand](https://www.jetbrains.com/go/)
-recommended that `GOPATH` is set to a directory in your home directory such as
+and [VS Code](https://code.visualstudio.com/docs/languages/go) IDEs are supported.
 `~/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:
+## Usage
-```bash
+By default, data and logs are stored in `<LBCDDIR>`:
-$ cd $GOPATH/src/github.com/btcsuite/btcd
+
-$ GO111MODULE=on go install -v . ./cmd/...
+- Linux: `~/.lbcd/`
 - MacOS: `/Users/<username>/Library/Application Support/Lbcd/`
 To enable RPC access a username and password is required. Example:
 ``` sh
 ./lbcd --txindex --rpcuser=rpcuser --rpcpass=rpcpass
 ```
- btcd (and utilities) will now be installed in ```$GOPATH/bin```.  If you did
+Interact with lbcd via RPC using `lbcctl`
  not already add the bin directory to your system path during Go installation,
  we recommend you do so now.
-## Updating
+``` sh
-
+./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass getblockcount
-#### Linux/BSD/MacOSX/POSIX - Build from Source
+./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass getblocktemplate
 - 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/...
 ```
-## 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
+The RPCs can also be served without TLS *(on localhost only)* using (`--notls`)
 of the basic operations described in the intro section work with zero
 configuration.
-#### Linux/BSD/POSIX/Source
+``` sh
-
+./lbcd --txindex --rpcuser=rpcuser --rpcpass=rpcpass --notls
-```bash
+./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass --notls getblockcount
 $ ./btcd
 ```
-## IRC
+## Working with Different Networks
- irc.libera.chat
+By default, `lbcd` and `lbcctl` use the following ports for different networks respectively:
 - channel #btcd
 - [webchat](https://web.libera.chat/gamja/?channels=btcd)
-## 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)
+Running `lbcd` and `lbcctl` with `--testnet` or `--regtest` would use different chain params as well as default RPC and Network ports.
 is used for this project.
-## Documentation
+``` sh
 ./lbcd --txindex --rpcuser=rpcuser --rpcpass=rpcpass --regtest
 ./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass --regtest getblockcount
 ```
-The documentation is a work-in-progress.  It is located in the [docs](https://github.com/btcsuite/btcd/tree/master/docs) folder.
+The default Network and RPC ports of `lbcd` can be overriden using `--listen` and `--rpclisten`
 `lbcctl` can also connect to RPC server specified by `--rpcserver`
-## Release Verification
+``` sh
 ./lbcd --txindex --rpcuser=rpcuser --rpcpass=rpcpass --regtest --listen=127.0.0.1:29248 --rpclisten=127.0.0.1:29247
 ./lbcctl --rpcuser=rpcuser --rpcpass=rpcpass --regtest --rpcserver=127.0.0.1:29247 getblockcount
 ```
 Note: Wallet related RPCs are provided by [lbcwallet](https://github.com/lbryio/lbcwallet).
 ## Contributing
 Contributions to this project are welcome, encouraged, and compensated.
 The [integrated github issue tracker](https://github.com/lbryio/lbcd/issues)
 is used for this project. All pull requests will be considered.
 <!-- ## Release Verification
 Please see our [documentation on the current build/verification
-process](https://github.com/btcsuite/btcd/tree/master/release) for all our
+process](https://github.com/lbryio/lbcd/tree/master/release) for all our
 releases for information on how to verify the integrity of published releases
 using our reproducible build system.
 -->
 ## License
-btcd is licensed under the [copyfree](http://copyfree.org) ISC License.
+lbcd is licensed under the [copyfree](http://copyfree.org) ISC License.
--- a/blockchain/README.md
+++ b/blockchain/README.md
@ -1,30 +1,9 @@
 blockchain
 ==========
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain)
-Package blockchain implements bitcoin block handling and chain selection rules.
+### Bitcoin Chain Processing Overview
 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
 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.
--- a/blockchain/fullblocktests/README.md
+++ b/blockchain/fullblocktests/README.md
@ -1,9 +1,9 @@
 fullblocktests
 ==============
-[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
+[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
-[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain/fullblocktests)
+[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/lbryio/lbcd/blockchain/fullblocktests)
 Package fullblocktests provides a set of full block tests to be used for testing
 the consensus validation rules.  The tests are intended to be flexible enough to
@ -20,7 +20,7 @@ of blocks that exercise the consensus validation rules.
 ## Installation and Updating
 ```bash
-$ go get -u github.com/btcsuite/btcd/blockchain/fullblocktests
+$ go get -u github.com/lbryio/lbcd/blockchain/fullblocktests
 ```
 ## License
--- a/blockchain/indexers/README.md
+++ b/blockchain/indexers/README.md
@ -1,9 +1,9 @@
 indexers
 ========
-[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
+[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
-[![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain/indexers?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/blockchain/indexers)
+[![GoDoc](https://pkg.go.dev/github.com/lbryio/lbcd/blockchain/indexers?status.png)](https://pkg.go.dev/github.com/lbryio/lbcd/blockchain/indexers)
 Package indexers implements optional block chain indexes.
@ -23,7 +23,7 @@ via an RPC interface.
 ## Installation
 ```bash
-$ go get -u github.com/btcsuite/btcd/blockchain/indexers
+$ go get -u github.com/lbryio/lbcd/blockchain/indexers
 ```
 ## License
--- a/btcec/README.md
+++ b/btcec/README.md
@ -1,68 +1,11 @@
 btcec
 =====
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/btcec?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/btcec)
-Package btcec implements elliptic curve cryptography needed for working with
+btcec implements elliptic curve cryptography needed for working with
 Bitcoin (secp256k1 only for now). It is designed so that it may be used with the
 standard crypto/ecdsa packages provided with go.  A comprehensive suite of test
 is provided to ensure proper functionality.  Package btcec was originally based
 on work from ThePiachu which is licensed under the same terms as Go, but it has
-signficantly diverged since then.  The btcsuite developers original is licensed
+signficantly diverged since then.
 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.
--- a/btcjson/README.md
+++ b/btcjson/README.md
@ -1,70 +1,8 @@
 btcjson
 =======
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson)
 Package btcjson implements concrete types for marshalling to and from the
 bitcoin JSON-RPC API.  A comprehensive suite of tests is provided to ensure
 proper functionality.
 Although this package was primarily written for the btcsuite, it has
 intentionally been designed so it can be used as a standalone package for any
 projects needing to marshal to and from bitcoin JSON-RPC requests and responses.
 Note that although it's possible to use this package directly to implement an
 RPC client, it is not recommended since it is only intended as an infrastructure
 package.  Instead, RPC clients should use the
 [btcrpcclient](https://github.com/btcsuite/btcrpcclient) package which provides
 a full blown RPC client with many features such as automatic connection
 management, websocket support, automatic notification re-registration on
 reconnect, and conversion from the raw underlying RPC types (strings, floats,
 ints, etc) to higher-level types with many nice and useful properties.
 ## Installation and Updating
 ```bash
 $ go get -u github.com/btcsuite/btcd/btcjson
 ```
 ## Examples
 * [Marshal Command](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson#example-MarshalCmd)  
  Demonstrates how to create and marshal a command into a JSON-RPC request.
 * [Unmarshal Command](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson#example-UnmarshalCmd)  
  Demonstrates how to unmarshal a JSON-RPC request and then unmarshal the
  concrete request into a concrete command.
 * [Marshal Response](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson#example-MarshalResponse)  
  Demonstrates how to marshal a JSON-RPC response.
 * [Unmarshal Response](https://pkg.go.dev/github.com/btcsuite/btcd/btcjson#example-package--UnmarshalResponse)  
  Demonstrates how to unmarshal a JSON-RPC response and then unmarshal the
  result field in the response to a concrete type.
 ## GPG Verification Key
 All official release tags are signed by Conformal so users can ensure the code
 has not been tampered with and is coming from the btcsuite developers.  To
 verify the signature perform the following:
 - Download the public key from the Conformal website at
  https://opensource.conformal.com/GIT-GPG-KEY-conformal.txt
 - Import the public key into your GPG keyring:
  ```bash
  gpg --import GIT-GPG-KEY-conformal.txt
  ```
 - Verify the release tag with the following command where `TAG_NAME` is a
  placeholder for the specific tag:
  ```bash
  git tag -v TAG_NAME
  ```
 ## License
 Package btcjson is licensed under the [copyfree](http://copyfree.org) ISC
 License.
--- a/chaincfg/README.md
+++ b/chaincfg/README.md
@ -1,85 +1,8 @@
 chaincfg
 ========
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/chaincfg)
 Package chaincfg defines chain configuration parameters for the three standard
-Bitcoin networks and provides the ability for callers to define their own custom
+LBRY networks and provides the ability for callers to define their own custom
-Bitcoin networks.
+LBRY 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.
--- a/chaincfg/chainhash/README.md
+++ b/chaincfg/chainhash/README.md
@ -1,9 +1,9 @@
 chainhash
 =========
-[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
+[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
-[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/chaincfg/chainhash)
+[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/lbryio/lbcd/chaincfg/chainhash)
 =======
 chainhash provides a generic hash type and associated functions that allows the
@ -12,7 +12,7 @@ specific hash algorithm to be abstracted.
 ## Installation and Updating
 ```bash
-$ go get -u github.com/btcsuite/btcd/chaincfg/chainhash
+$ go get -u github.com/lbryio/lbcd/chaincfg/chainhash
 ```
 ## GPG Verification Key
--- a/connmgr/README.md
+++ b/connmgr/README.md
@ -1,13 +1,11 @@
 connmgr
 =======
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/connmgr)
-Package connmgr implements a generic Bitcoin network connection manager.
+Package connmgr implements a generic network connection manager.
-## Overview
+### Overview
 Connection Manager handles all the general connection concerns such as
 maintaining a set number of outbound connections, sourcing peers, banning,
@ -18,20 +16,10 @@ connection requests from a source or a set of given addresses, dial them and
 notify the caller on connections. The main intended use is to initialize a pool
 of active connections and maintain them to remain connected to the P2P network.
-In addition the connection manager provides the following utilities:
+In addition, the connection manager provides the following utilities:
 - Notifications on connections or disconnections
 - Handle failures and retry new addresses from the source
 - Connect only to specified addresses
 - Permanent connections with increasing backoff retry timers
 - Disconnect or Remove an established connection
 ## Installation and Updating
 ```bash
 $ go get -u github.com/btcsuite/btcd/connmgr
 ```
 ## License
 Package connmgr is licensed under the [copyfree](http://copyfree.org) ISC License.
--- a/database/README.md
+++ b/database/README.md
@ -1,9 +1,7 @@
 database
 ========
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/database)
 Package database provides a block and metadata storage database.
@ -13,8 +11,8 @@ one entity can have the database open at a time (for most database backends),
 and that entity will be btcd.
 When a client wants programmatic access to the data provided by btcd, they'll
-likely want to use the [rpcclient](https://github.com/btcsuite/btcd/tree/master/rpcclient)
+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/btcsuite/btcd/tree/master/docs/json_rpc_api.md).
+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.
--- a/database/ffldb/README.md
+++ b/database/ffldb/README.md
@ -1,9 +1,9 @@
 ffldb
 =====
-[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
+[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
-[![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/database/ffldb?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/database/ffldb)
+[![GoDoc](https://pkg.go.dev/github.com/lbryio/lbcd/database/ffldb?status.png)](https://pkg.go.dev/github.com/lbryio/lbcd/database/ffldb)
 =======
 Package ffldb implements a driver for the database package that uses leveldb for
--- a/database/internal/treap/README.md
+++ b/database/internal/treap/README.md
@ -1,9 +1,9 @@
 treap
 =====
-[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
+[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
-[![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/database/internal/treap?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/database/internal/treap)
+[![GoDoc](https://pkg.go.dev/github.com/lbryio/lbcd/database/internal/treap?status.png)](https://pkg.go.dev/github.com/lbryio/lbcd/database/internal/treap)
 Package treap implements a treap data structure that is used to hold ordered
 key/value pairs using a combination of binary search tree and heap semantics.
--- a/doc.go
+++ b/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:
+                              (default all interfaces port: 9246, testnet:
-                              18333, signet: 38333)
+                              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
--- a/docs/code_contribution_guidelines.md
+++ b/docs/code_contribution_guidelines.md
@ -1,319 +0,0 @@
 # Code contribution guidelines
 Developing cryptocurrencies is an exciting endeavor that touches a wide variety
 of areas such as wire protocols, peer-to-peer networking, databases,
 cryptography, language interpretation (transaction scripts), RPC, and
 websockets.  They also represent a radical shift to the current fiscal system
 and as a result provide an opportunity to help reshape the entire financial
 system.  There are few projects that offer this level of diversity and impact
 all in one code base.
 However, as exciting as it is, one must keep in mind that cryptocurrencies
 represent real money and introducing bugs and security vulnerabilities can have
 far more dire consequences than in typical projects where having a small bug is
 minimal by comparison.  In the world of cryptocurrencies, even the smallest bug
 in the wrong area can cost people a significant amount of money.  For this
 reason, the btcd suite has a formalized and rigorous development process which
 is outlined on this page.
 We highly encourage code contributions, however it is imperative that you adhere
 to the guidelines established on this page.
 ## Minimum Recommended Skillset
 The following list is a set of core competencies that we recommend you possess
 before you really start attempting to contribute code to the project.  These are
 not hard requirements as we will gladly accept code contributions as long as
 they follow the guidelines set forth on this page.  That said, if you don't have
 the following basic qualifications you will likely find it quite difficult to
 contribute.
 - A reasonable understanding of bitcoin at a high level (see the
  [Required Reading](#ReqReading) section for the original white paper)
 - Experience in some type of C-like language
 - An understanding of data structures and their performance implications
 - Familiarity with unit testing
 - Debugging experience
 - Ability to understand not only the area you are making a change in, but also
  the code your change relies on, and the code which relies on your changed code
 Building on top of those core competencies, the recommended skill set largely
 depends on the specific areas you are looking to contribute to.  For example,
 if you wish to contribute to the cryptography code, you should have a good
 understanding of the various aspects involved with cryptography such as the
 security and performance implications.
 ## Required Reading
 - [Effective Go](http://golang.org/doc/effective_go.html) - The entire btcd
  suite follows the guidelines in this document.  For your code to be accepted,
  it must follow the guidelines therein.
 - [Original Satoshi Whitepaper](http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fbitcoin.org%2Fbitcoin.pdf&ei=os3VUuH8G4SlsASV74GoAg&usg=AFQjCNEipPLigou_1MfB7DQjXCNdlylrBg&sig2=FaHDuT5z36GMWDEnybDJLg&bvm=bv.59378465,d.b2I) - This is the white paper that started it all.  Having a solid
  foundation to build on will make the code much more comprehensible.
 ## Development Practices
 Developers are expected to work in their own trees and submit pull requests when
 they feel their feature or bug fix is ready for integration into the  master
 branch.
 ## Share Early, Share Often
 We firmly believe in the share early, share often approach.  The basic premise
 of the approach is to announce your plans **before** you start work, and once
 you have started working, craft your changes into a stream of small and easily
 reviewable commits.
 This approach has several benefits:
 - Announcing your plans to work on a feature **before** you begin work avoids
  duplicate work
 - It permits discussions which can help you achieve your goals in a way that is
  consistent with the existing architecture
 - It minimizes the chances of you spending time and energy on a change that
  might not fit with the consensus of the community or existing architecture and
  potentially be rejected as a result
 - Incremental development helps ensure you are on the right track with regards
  to the rest of the community
 - The quicker your changes are merged to master, the less time you will need to
  spend rebasing and otherwise trying to keep up with the main code base
 ## Testing
 One of the major design goals of all core btcd packages is to aim for complete
 test coverage.  This is financial software so bugs and regressions can cost
 people real money.  For this reason every effort must be taken to ensure the
 code is as accurate and bug-free as possible.  Thorough testing is a good way to
 help achieve that goal.
 Unless a new feature you submit is completely trivial, it will probably be
 rejected unless it is also accompanied by adequate test coverage for both
 positive and negative conditions.  That is to say, the tests must ensure your
 code works correctly when it is fed correct data as well as incorrect data
 (error paths).
 Go provides an excellent test framework that makes writing test code and
 checking coverage statistics straight forward.  For more information about the
 test coverage tools, see the [golang cover blog post](http://blog.golang.org/cover).
 A quick summary of test practices follows:
 - All new code should be accompanied by tests that ensure the code behaves
  correctly when given expected values, and, perhaps even more importantly, that
  it handles errors gracefully
 - When you fix a bug, it should be accompanied by tests which exercise the bug
  to both prove it has been resolved and to prevent future regressions
 ## Code Documentation and Commenting
 - At a minimum every function must be commented with its intended purpose and
  any assumptions that it makes
  - Function comments must always begin with the name of the function per
    [Effective Go](http://golang.org/doc/effective_go.html)
  - Function comments should be complete sentences since they allow a wide
    variety of automated presentations such as [go.dev](https://go.dev)
  - The general rule of thumb is to look at it as if you were completely
    unfamiliar with the code and ask yourself, would this give me enough
    information to understand what this function does and how I'd probably want
    to use it?
 - Exported functions should also include detailed information the caller of the
  function will likely need to know and/or understand:
 **WRONG**
 ```Go
 // convert a compact uint32 to big.Int
 func CompactToBig(compact uint32) *big.Int {
 ```
 **RIGHT**
 ```Go
 // CompactToBig converts a compact representation of a whole number N to a
 // big integer.  The representation is similar to IEEE754 floating point
 // numbers.
 //
 // Like IEEE754 floating point, there are three basic components: the sign,
 // the exponent, and the mantissa. They are broken out as follows:
 //
 //        * the most significant 8 bits represent the unsigned base 256 exponent
 //        * bit 23 (the 24th bit) represents the sign bit
 //        * the least significant 23 bits represent the mantissa
 //
 //        -------------------------------------------------
 //        |   Exponent     |    Sign    |    Mantissa     |
 //        -------------------------------------------------
 //        | 8 bits [31-24] | 1 bit [23] | 23 bits [22-00] |
 //        -------------------------------------------------
 //
 // The formula to calculate N is:
 //         N = (-1^sign) * mantissa * 256^(exponent-3)
 //
 // This compact form is only used in bitcoin to encode unsigned 256-bit numbers
 // which represent difficulty targets, thus there really is not a need for a
 // sign bit, but it is implemented here to stay consistent with bitcoind.
 func CompactToBig(compact uint32) *big.Int {
 ```
 - Comments in the body of the code are highly encouraged, but they should
  explain the intention of the code as opposed to just calling out the
  obvious
 **WRONG**
 ```Go
 // return err if amt is less than 5460
 if amt < 5460 {
  return err
 }
 ```
 **RIGHT**
 ```Go
 // Treat transactions with amounts less than the amount which is considered dust
 // as non-standard.
 if amt < 5460 {
  return err
 }
 ```
 **NOTE:** The above should really use a constant as opposed to a magic number,
 but it was left as a magic number to show how much of a difference a good
 comment can make.
 ## Model Git Commit Messages
 This project prefers to keep a clean commit history with well-formed commit
 messages.  This section illustrates a model commit message and provides a bit
 of background for it.  This content was originally created by Tim Pope and made
 available on his website, however that website is no longer active, so it is
 being provided here.
 Here’s a model Git commit message:
 ```text
 Short (50 chars or less) summary of changes
 More detailed explanatory text, if necessary.  Wrap it to about 72
 characters or so.  In some contexts, the first line is treated as the
 subject of an email and the rest of the text as the body.  The blank
 line separating the summary from the body is critical (unless you omit
 the body entirely); tools like rebase can get confused if you run the
 two together.
 Write your commit message in the present tense: "Fix bug" and not "Fixed
 bug."  This convention matches up with commit messages generated by
 commands like git merge and git revert.
 Further paragraphs come after blank lines.
 - Bullet points are okay, too
 - Typically a hyphen or asterisk is used for the bullet, preceded by a
  single space, with blank lines in between, but conventions vary here
 - Use a hanging indent
 ```
 Prefix the summary with the subsystem/package when possible. Many other
 projects make use of the code and this makes it easier for them to tell when
 something they're using has changed. Have a look at [past
 commits](https://github.com/btcsuite/btcd/commits/master) for examples of
 commit messages.
 Here are some of the reasons why wrapping your commit messages to 72 columns is
 a good thing.
 - git log doesn’t do any special special wrapping of the commit messages. With
  the default pager of less -S, this means your paragraphs flow far off the edge
  of the screen, making them difficult to read. On an 80 column terminal, if we
  subtract 4 columns for the indent on the left and 4 more for symmetry on the
  right, we’re left with 72 columns.
 - git format-patch --stdout converts a series of commits to a series of emails,
  using the messages for the message body.  Good email netiquette dictates we
  wrap our plain text emails such that there’s room for a few levels of nested
  reply indicators without overflow in an 80 column terminal.
 ## Code Approval Process
 This section describes the code approval process that is used for code
 contributions.  This is how to get your changes into btcd.
 ## Code Review
 All code which is submitted will need to be reviewed before inclusion into the
 master branch.  This process is performed by the project maintainers and usually
 other committers who are interested in the area you are working in as well.
 ## Code Review Timeframe
 The timeframe for a code review will vary greatly depending on factors such as
 the number of other pull requests which need to be reviewed, the size and
 complexity of the contribution, how well you followed the guidelines presented
 on this page, and how easy it is for the reviewers to digest your commits.  For
 example, if you make one monolithic commit that makes sweeping changes to things
 in multiple subsystems, it will obviously take much longer to review.  You will
 also likely be asked to split the commit into several smaller, and hence more
 manageable, commits.
 Keeping the above in mind, most small changes will be reviewed within a few
 days, while large or far reaching changes may take weeks.  This is a good reason
 to stick with the [Share Early, Share Often](#ShareOften) development practice
 outlined above.
 ## What is the review looking for?
 The review is mainly ensuring the code follows the [Development Practices](#DevelopmentPractices)
 and [Code Contribution Standards](#Standards).  However, there are a few other
 checks which are generally performed as follows:
 - The code is stable and has no stability or security concerns
 - The code is properly using existing APIs and generally fits well into the
  overall architecture
 - The change is not something which is deemed inappropriate by community
  consensus
 ## Rework Code (if needed)
 After the code review, the change will be accepted immediately if no issues are
 found.  If there are any concerns or questions, you will be provided with
 feedback along with the next steps needed to get your contribution merged with
 master.  In certain cases the code reviewer(s) or interested committers may help
 you rework the code, but generally you will simply be given feedback for you to
 make the necessary changes.
 This process will continue until the code is finally accepted.
 ## Acceptance
 Once your code is accepted, it will be integrated with the master branch.
 Typically it will be rebased and fast-forward merged to master as we prefer to
 keep a clean commit history over a tangled weave of merge commits.  However,
 regardless of the specific merge method used, the code will be integrated with
 the master branch and the pull request will be closed.
 Rejoice as you will now be listed as a [contributor](https://github.com/btcsuite/btcd/graphs/contributors)!
 ## Contribution Standards
 ## Contribution Checklist
 - [&nbsp;&nbsp;] All changes are Go version 1.3 compliant
 - [&nbsp;&nbsp;] The code being submitted is commented according to the
  [Code Documentation and Commenting](#CodeDocumentation) section
 - [&nbsp;&nbsp;] For new code: Code is accompanied by tests which exercise both
  the positive and negative (error paths) conditions (if applicable)
 - [&nbsp;&nbsp;] For bug fixes: Code is accompanied by new tests which trigger
  the bug being fixed to prevent regressions
 - [&nbsp;&nbsp;] Any new logging statements use an appropriate subsystem and
  logging level
 - [&nbsp;&nbsp;] Code has been formatted with `go fmt`
 - [&nbsp;&nbsp;] Running `go test` does not fail any tests
 - [&nbsp;&nbsp;] Running `go vet` does not report any issues
 - [&nbsp;&nbsp;] Running [golint](https://github.com/golang/lint) does not
  report any **new** issues that did not already exist
 ## Licensing of Contributions
 All contributions must be licensed with the
 [ISC license](https://github.com/btcsuite/btcd/blob/master/LICENSE).  This is
 the same license as all of the code in the btcd suite.
--- a/docs/configuration.md
+++ b/docs/configuration.md
@ -1,11 +1,11 @@
 # Configuration
-btcd has a number of [configuration](https://pkg.go.dev/github.com/btcsuite/btcd)
+lbcd has a number of configuration
-options, which can be viewed by running: `$ btcd --help`.
+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|
+| Flags                                       | Comment                                                                                      |
-|----------|------------|
+| ------------------------------------------- | -------------------------------------------------------------------------------------------- |
-|--listen=|all interfaces on default port which is changed by `--testnet` and `--regtest` (**default**)|
+| --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=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=::                                 | all IPv6 interfaces on default port which is changed by `--testnet` and `--regtest`          |
-|--listen=:8333|all interfaces on port 8333|
+| --listen=:9246                              | all interfaces on port 9246                                                                  |
-|--listen=0.0.0.0:8333|all IPv4 interfaces on port 8333|
+| --listen=0.0.0.0:9246                       | all IPv4 interfaces on port 9246                                                             |
-|--listen=[::]:8333|all IPv6 interfaces on port 8333|
+| --listen=[::]:9246                          | all IPv6 interfaces on port 9246                                                             |
-|--listen=127.0.0.1:8333|only IPv4 localhost on port 8333|
+| --listen=127.0.0.1:9246                     | only IPv4 localhost on port 9246                                                             |
-|--listen=[::1]:8333|only IPv6 localhost on port 8333|
+| --listen=[::1]:9246                         | only IPv6 localhost on port 9246                                                             |
-|--listen=:8336|all interfaces on non-standard port 8336|
+| --listen=:9247                              | all interfaces on non-standard port 9247                                                     |
-|--listen=0.0.0.0:8336|all IPv4 interfaces on non-standard port 8336|
+| --listen=0.0.0.0:9247                       | all IPv4 interfaces on non-standard port 9247                                                |
-|--listen=[::]:8336|all IPv6 interfaces on non-standard port 8336|
+| --listen=[::]:9247                          | all IPv6 interfaces on non-standard port 9247                                                |
-|--listen=127.0.0.1:8337 --listen=[::1]:8333|IPv4 localhost on port 8337 and IPv6 localhost on port 8333|
+| --listen=127.0.0.1:9248 --listen=[::1]:9246 | IPv4 localhost on port 9248 and IPv6 localhost on port 9246                                  |
-|--listen=:8333 --listen=:8337|all interfaces on ports 8333 and 8337|
+| --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=127.0.0.1:9246
-listen=[::1]:8333
+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|
+| Flags                                          | Comment                                                             |
-|----------|------------|
+| ---------------------------------------------- | ------------------------------------------------------------------- |
-|--rpclisten=|all interfaces on default port which is changed by `--testnet`|
+| --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=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=::                                 | all IPv6 interfaces on default port which is changed by `--testnet` |
-|--rpclisten=:8334|all interfaces on port 8334|
+| --rpclisten=:9245                              | all interfaces on port 9245                                         |
-|--rpclisten=0.0.0.0:8334|all IPv4 interfaces on port 8334|
+| --rpclisten=0.0.0.0:9245                       | all IPv4 interfaces on port 9245                                    |
-|--rpclisten=[::]:8334|all IPv6 interfaces on port 8334|
+| --rpclisten=[::]:9245                          | all IPv6 interfaces on port 9245                                    |
-|--rpclisten=127.0.0.1:8334|only IPv4 localhost on port 8334|
+| --rpclisten=127.0.0.1:9245                     | only IPv4 localhost on port 9245                                    |
-|--rpclisten=[::1]:8334|only IPv6 localhost on port 8334|
+| --rpclisten=[::1]:9245                         | only IPv6 localhost on port 9245                                    |
-|--rpclisten=:8336|all interfaces on non-standard port 8336|
+| --rpclisten=:9247                              | all interfaces on non-standard port 9247                            |
-|--rpclisten=0.0.0.0:8336|all IPv4 interfaces on non-standard port 8336|
+| --rpclisten=0.0.0.0:9247                       | all IPv4 interfaces on non-standard port 9247                       |
-|--rpclisten=[::]:8336|all IPv6 interfaces on non-standard port 8336|
+| --rpclisten=[::]:9247                          | all IPv6 interfaces on non-standard port 9247                       |
-|--rpclisten=127.0.0.1:8337 --listen=[::1]:8334|IPv4 localhost on port 8337 and IPv6 localhost on port 8334|
+| --rpclisten=127.0.0.1:9248 --listen=[::1]:9245 | IPv4 localhost on port 9248 and IPv6 localhost on port 9245         |
-|--rpclisten=:8334 --listen=:8337|all interfaces on ports 8334 and 8337|
+| --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
+access to your lbcd from external sources such as in more advanced network
-configurations.
+configurations. You can disable UPnP with the `--noupnp` daemon option.
-|Name|Port|
+| Name                      | Port     |
-|----|----|
+| ------------------------- | -------- |
-|Default Bitcoin peer-to-peer port|TCP 8333|
+| Default peer-to-peer port | TCP 9246 |
-|Default RPC port|TCP 8334|
+| 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
+1. Stop lbcd 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.
+   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:**
--- a/docs/configuring_tor.md
+++ b/docs/configuring_tor.md
@ -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
+typically needs to be done is to specify the `--proxy` flag via the lbcd command
-line or in the btcd configuration file.  Typically the Tor proxy address will be
+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
+HiddenServiceDir /var/tor/lbcd
-HiddenServicePort 8333 127.0.0.1:8333
+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
--- a/docs/contact.md
+++ b/docs/contact.md
@ -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.
--- a/docs/controlling.md
+++ b/docs/controlling.md
@ -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
+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).  btcd does
+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`
--- a/docs/developer_resources.md
+++ b/docs/developer_resources.md
@ -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.
--- a/docs/index.md
+++ b/docs/index.md
@ -1,57 +1,11 @@
-# btcd
+# lbcd
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd)
 btcd is an alternative full node bitcoin implementation written in Go (golang).
 This project is currently under active development and is in a Beta state.  It
 is extremely stable and has been in production use since October 2013.
 It properly downloads, validates, and serves the block chain using the exact
 rules (including consensus bugs) for block acceptance as Bitcoin Core.  We have
 taken great care to avoid btcd causing a fork to the block chain.  It includes a
 full block validation testing framework which contains all of the 'official'
 block acceptance tests (and some additional ones) that is run on every pull
 request to help ensure it properly follows consensus.  Also, it passes all of
 the JSON test data in the Bitcoin Core code.
 It also properly relays newly mined blocks, maintains a transaction pool, and
 relays individual transactions that have not yet made it into a block.  It
 ensures all individual transactions admitted to the pool follow the rules
 required by the block chain and also includes more strict checks which filter
 transactions based on miner requirements ("standard" transactions).
 One key difference between btcd and Bitcoin Core is that btcd does *NOT* include
 wallet functionality and this was a very intentional design decision.  See the
 blog entry [here](https://web.archive.org/web/20171125143919/https://blog.conformal.com/btcd-not-your-moms-bitcoin-daemon)
 for more details.  This means you can't actually make or receive payments
 directly with btcd.  That functionality is provided by the
 [btcwallet](https://github.com/btcsuite/btcwallet) and
 [Paymetheus](https://github.com/btcsuite/Paymetheus) (Windows-only) projects
 which are both under active development.
 ## Documentation
 Documentation is a work-in-progress. It is available at [btcd.readthedocs.io](https://btcd.readthedocs.io).
 ## Contents
 * [Installation](installation.md)
 * [Update](update.md)
 * [Configuration](configuration.md)
 * [Configuring TOR](configuring_tor.md)
 * [Docker](using_docker.md)
 * [Controlling](controlling.md)
 * [Mining](mining.md)
 * [Wallet](wallet.md)
 * [Developer resources](developer_resources.md)
 * [JSON RPC API](json_rpc_api.md)
 * [Code contribution guidelines](code_contribution_guidelines.md)
 * [Contact](contact.md)
 ## License
 btcd is licensed under the [copyfree](http://copyfree.org) ISC License.
--- a/docs/installation.md
+++ b/docs/installation.md
@ -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)
--- a/docs/json_rpc_api.md
+++ b/docs/json_rpc_api.md
--- a/docs/mining.md
+++ b/docs/mining.md
@ -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.
+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 `btcd` RPC
+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`
+1. Copy rpc.cert to /usr/share/ca-certificates: `# cp /home/user/.lbcd/rpc.cert /usr/share/ca-certificates/lbcd.crt`
-2. Add btcd.crt to /etc/ca-certificates.conf: `# echo btcd.crt >> /etc/ca-certificates.conf`
+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.
--- a/docs/table_of_content.md
+++ b/docs/table_of_content.md
@ -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)
--- a/docs/update.md
+++ b/docs/update.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/...
 ```
--- a/docs/using_docker.md
+++ b/docs/using_docker.md
@ -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:
 ```
--- a/docs/wallet.md
+++ b/docs/wallet.md
@ -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.
--- a/integration/README.md
+++ b/integration/README.md
@ -1,13 +1,8 @@
 integration
 ===========
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 This contains integration tests which make use of the
-[rpctest](https://github.com/btcsuite/btcd/tree/master/integration/rpctest)
+[rpctest](https://github.com/lbryio/lbcd/tree/master/integration/rpctest)
 package to programmatically drive nodes via RPC.
 ## License
 This code is licensed under the [copyfree](http://copyfree.org) ISC License.
--- a/integration/rpctest/README.md
+++ b/integration/rpctest/README.md
@ -1,9 +1,7 @@
 rpctest
 =======
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/integration/rpctest)
 Package rpctest provides a btcd-specific RPC testing harness crafting and
 executing integration tests by driving a `btcd` instance via the `RPC`
@ -16,15 +14,3 @@ This package was designed specifically to act as an RPC testing harness for
 `btcd`. However, the constructs presented are general enough to be adapted to
 any project wishing to programmatically drive a `btcd` instance of its
 systems/integration tests.
 ## Installation and Updating
 ```bash
 $ go get -u github.com/btcsuite/btcd/integration/rpctest
 ```
 ## License
 Package rpctest is licensed under the [copyfree](http://copyfree.org) ISC
 License.
--- a/mempool/README.md
+++ b/mempool/README.md
@ -1,9 +1,7 @@
 mempool
 =======
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/mempool)
 Package mempool provides a policy-enforced pool of unmined bitcoin transactions.
@ -33,11 +31,6 @@ proceed.  Typically, this will involve things such as relaying the transactions
 to other peers on the network and notifying the mining process that new
 transactions are available.
 This package has intentionally been designed so it can be used as a standalone
 package for any projects needing the ability create an in-memory pool of bitcoin
 transactions that are not only valid by consensus rules, but also adhere to a
 configurable policy.
 ## Feature Overview
 The following is a quick overview of the major features.  It is not intended to
@ -70,14 +63,3 @@ be an exhaustive list.
  - The starting priority for the transaction
 - Manual control of transaction removal
  - Recursive removal of all dependent transactions
 ## Installation and Updating
 ```bash
 $ go get -u github.com/btcsuite/btcd/mempool
 ```
 ## License
 Package mempool is licensed under the [copyfree](http://copyfree.org) ISC
 License.
--- a/mining/README.md
+++ b/mining/README.md
@ -1,21 +1,8 @@
 mining
 ======
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/mining)
 ## Overview
 This package is currently a work in progress.
 ## Installation and Updating
 ```bash
 $ go get -u github.com/btcsuite/btcd/mining
 ```
 ## License
 Package mining is licensed under the [copyfree](http://copyfree.org) ISC
 License.
--- a/mining/cpuminer/README.md
+++ b/mining/cpuminer/README.md
@ -1,9 +1,9 @@
 cpuminer
 ========
-[![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
+[![Build Status](https://github.com/lbryio/lbcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/lbryio/lbcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
-[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/mining/cpuminer)
+[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/lbryio/lbcd/mining/cpuminer)
 =======
 ## Overview
@ -16,7 +16,7 @@ now.
 ## Installation and Updating
 ```bash
-$ go get -u github.com/btcsuite/btcd/mining/cpuminer
+$ go get -u github.com/lbryio/lbcd/mining/cpuminer
 ```
 ## License
--- a/netsync/README.md
+++ b/netsync/README.md
@ -1,9 +1,7 @@
 netsync
 =======
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/netsync)
 ## Overview
@ -13,13 +11,3 @@ download, keep the chain and unconfirmed transaction pool in sync, and announce
 new blocks connected to the chain. Currently the sync manager selects a single
 sync peer that it downloads all blocks from until it is up to date with the
 longest chain the sync peer is aware of.
 ## Installation and Updating
 ```bash
 $ go get -u github.com/btcsuite/btcd/netsync
 ```
 ## License
 Package netsync is licensed under the [copyfree](http://copyfree.org) ISC License.
--- a/peer/README.md
+++ b/peer/README.md
@ -1,16 +1,11 @@
 peer
 ====
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/peer)
 Package peer provides a common base for creating and managing bitcoin network
 peers.
 This package has intentionally been designed so it can be used as a standalone
 package for any projects needing a full featured bitcoin peer base to build on.
 ## Overview
 This package builds upon the wire package, which provides the fundamental
@ -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.
--- a/release/README.md
+++ b/release/README.md
@ -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.
--- a/rpcclient/README.md
+++ b/rpcclient/README.md
@ -1,13 +1,11 @@
 rpcclient
 =========
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/rpcclient)
 rpcclient implements a Websocket-enabled Bitcoin JSON-RPC client package written
 in [Go](http://golang.org/).  It provides a robust and easy to use client for
-interfacing with a Bitcoin RPC server that uses a btcd/bitcoin core compatible
+interfacing with a Bitcoin RPC server that uses a lbcd/bitcoin core compatible
 Bitcoin JSON-RPC API.
 ## Status
@ -16,26 +14,11 @@ This package is currently under active development.  It is already stable and
 the infrastructure is complete.  However, there are still several RPCs left to
 implement and the API is not stable yet.
 ## Documentation
 * [API Reference](https://pkg.go.dev/github.com/btcsuite/btcd/rpcclient)
 * [btcd Websockets Example](https://github.com/btcsuite/btcd/tree/master/rpcclient/examples/btcdwebsockets)
  Connects to a btcd RPC server using TLS-secured websockets, registers for
  block connected and block disconnected notifications, and gets the current
  block count
 * [btcwallet Websockets Example](https://github.com/btcsuite/btcd/tree/master/rpcclient/examples/btcwalletwebsockets)
  Connects to a btcwallet RPC server using TLS-secured websockets, registers for
  notifications about changes to account balances, and gets a list of unspent
  transaction outputs (utxos) the wallet can sign
 * [Bitcoin Core HTTP POST Example](https://github.com/btcsuite/btcd/tree/master/rpcclient/examples/bitcoincorehttp)
  Connects to a bitcoin core RPC server using HTTP POST mode with TLS disabled
  and gets the current block count
 ## Major Features
-* Supports Websockets (btcd/btcwallet) and HTTP POST mode (bitcoin core)
+* Supports Websockets (lbcd/lbcwallet) and HTTP POST mode (bitcoin core)
-* Provides callback and registration functions for btcd/btcwallet notifications
+* Provides callback and registration functions for lbcd/lbcwallet notifications
-* Supports btcd extensions
+* 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.
--- a/rpcclient/examples/bitcoincorehttp/README.md
+++ b/rpcclient/examples/bitcoincorehttp/README.md
@ -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
 ```
--- a/rpcclient/examples/bitcoincorehttpbulk/README.md
+++ b/rpcclient/examples/bitcoincorehttpbulk/README.md
@ -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
 ```
--- a/rpcclient/examples/btcdwebsockets/README.md
+++ b/rpcclient/examples/btcdwebsockets/README.md
@ -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
 ```
--- a/rpcclient/examples/btcwalletwebsockets/README.md
+++ b/rpcclient/examples/btcwalletwebsockets/README.md
@ -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
 ```
--- a/rpcclient/examples/customcommand/README.md
+++ b/rpcclient/examples/customcommand/README.md
@ -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
 ```
--- a/rpcclient/examples/customcommand/main.go
+++ b/rpcclient/examples/customcommand/main.go
@ -9,8 +9,8 @@ import (
 	"encoding/json"
 	"log"
-	"github.com/btcsuite/btcd/btcjson"
+	"github.com/lbryio/lbcd/btcjson"
-	"github.com/btcsuite/btcd/rpcclient"
+	"github.com/lbryio/lbcd/rpcclient"
 )
 // NameShowCmd defines the name_show JSON-RPC command.
--- a/sample-lbcd.conf
+++ b/sample-lbcd.conf
@ -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,
+; The default is ~/.lbcd/data on POSIX OSes, $LOCALAPPDATA/Lbcd/data on Windows,
-; ~/Library/Application Support/Btcd/data on Mac OS, and $home/btcd/data on
+; ~/Library/Application Support/Lbcd/data on Mac OS, and $home/lbcd/data on
 ; Plan9.  Environment variables are expanded so they may be used.  NOTE: Windows
 ; environment variables are typically %VARIABLE%, but they must be accessed with
 ; $VARIABLE here.  Also, ~ is expanded to $LOCALAPPDATA on Windows.
-; datadir=~/.btcd/data
+; datadir=~/.lbcd/data
 ; ------------------------------------------------------------------------------
@ -52,7 +52,7 @@
 ; upnp=1
 ; Specify the external IP addresses your node is listening on.  One address per
-; line.  btcd will not contact 3rd-party sites to obtain external ip addresses.
+; line.  lbcd will not contact 3rd-party sites to obtain external ip addresses.
 ; This means if you are behind NAT, your node will not be able to advertise a
 ; reachable address unless you specify it here or enable the 'upnp' option (and
 ; have a supported device).
@ -64,7 +64,7 @@
 ;
 ; Only one of the following two options, 'addpeer' and 'connect', may be
 ; specified.  Both allow you to specify peers that you want to stay connected
-; with, but the behavior is slightly different.  By default, btcd will query DNS
+; with, but the behavior is slightly different.  By default, lbcd will query DNS
 ; to find peers to connect to, so unless you have a specific reason such as
 ; those described below, you probably won't need to modify anything here.
 ;
@ -86,9 +86,9 @@
 ; You may specify each IP address with or without a port.  The default port will
 ; be added automatically if one is not specified here.
 ; addpeer=192.168.1.1
-; addpeer=10.0.0.2:8333
+; addpeer=10.0.0.2:9246
 ; addpeer=fe80::1
-; addpeer=[fe80::2]:8333
+; addpeer=[fe80::2]:9246
 ; Add persistent peers that you ONLY want to connect to as desired.  One peer
 ; per line.  You may specify each IP address with or without a port.  The
@ -96,9 +96,9 @@
 ; NOTE: Specifying this option has other side effects as described above in
 ; the 'addpeer' versus 'connect' summary section.
 ; connect=192.168.1.1
-; connect=10.0.0.2:8333
+; connect=10.0.0.2:9246
 ; connect=fe80::1
-; connect=[fe80::2]:8333
+; connect=[fe80::2]:9246
 ; Maximum number of inbound and outbound peers.
 ; maxpeers=125
@ -121,7 +121,7 @@
 ; whitelist=192.168.0.0/24
 ; whitelist=fd00::/16
-; Disable DNS seeding for peers.  By default, when btcd starts, it will use
+; Disable DNS seeding for peers.  By default, when lbcd starts, it will use
 ; DNS to query for available peers to connect with.
 ; nodnsseed=1
@ -135,16 +135,16 @@
 ;  listen=0.0.0.0
 ; All ipv6 interfaces on default port:
 ;   listen=::
-; All interfaces on port 8333:
+; All interfaces on port 9246:
-;   listen=:8333
+;   listen=:9246
-; All ipv4 interfaces on port 8333:
+; All ipv4 interfaces on port 9246:
-;   listen=0.0.0.0:8333
+;   listen=0.0.0.0:9246
-; All ipv6 interfaces on port 8333:
+; All ipv6 interfaces on port 9246:
-;   listen=[::]:8333
+;   listen=[::]:9246
-; Only ipv4 localhost on port 8333:
+; Only ipv4 localhost on port 9246:
-;   listen=127.0.0.1:8333
+;   listen=127.0.0.1:9246
-; Only ipv6 localhost on port 8333:
+; Only ipv6 localhost on port 9246:
-;   listen=[::1]:8333
+;   listen=[::1]:9246
 ; Only ipv4 localhost on non-standard port 8336:
 ;   listen=127.0.0.1:8336
 ; All interfaces on non-standard port 8336:
@ -172,7 +172,7 @@
 ; ------------------------------------------------------------------------------
 ; RPC server options - The following options control the built-in RPC server
-; which is used to control and query information from a running btcd process.
+; which is used to control and query information from a running lbcd process.
 ;
 ; NOTE: The RPC server is disabled by default if rpcuser AND rpcpass, or
 ; rpclimituser AND rpclimitpass, are not specified.
@ -335,7 +335,7 @@
 ; Debug logging level.
 ; Valid levels are {trace, debug, info, warn, error, critical}
 ; You may also specify <subsystem>=<level>,<subsystem2>=<level>,... to set
-; log level for individual subsystems.  Use btcd --debuglevel=show to list
+; log level for individual subsystems.  Use lbcd --debuglevel=show to list
 ; available subsystems.
 ; debuglevel=info
--- a/txscript/README.md
+++ b/txscript/README.md
@ -1,15 +1,11 @@
 txscript
 ========
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://pkg.go.dev/github.com/btcsuite/btcd/txscript?status.png)](https://pkg.go.dev/github.com/btcsuite/btcd/txscript)
 Package txscript implements the bitcoin transaction script language.  There is
 a comprehensive test suite.
-This package has intentionally been designed so it can be used as a standalone
+This package has been augmented to include support for LBRY's custom claim operations.
-package for any projects needing to use or validate bitcoin transaction scripts.
+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.
--- a/wire/README.md
+++ b/wire/README.md
@ -1,26 +1,14 @@
 wire
 ====
 [![Build Status](https://github.com/btcsuite/btcd/workflows/Build%20and%20Test/badge.svg)](https://github.com/btcsuite/btcd/actions)
 [![ISC License](http://img.shields.io/badge/license-ISC-blue.svg)](http://copyfree.org)
 [![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/btcsuite/btcd/wire)
 =======
 Package wire implements the bitcoin wire protocol.  A comprehensive suite of
 tests with 100% test coverage is provided to ensure proper functionality.
 There is an associated blog post about the release of this package
 [here](https://blog.conformal.com/btcwire-the-bitcoin-wire-protocol-package-from-btcd/).
-This package has intentionally been designed so it can be used as a standalone
+This package has been augmented from the original btcd implementation.
-package for any projects needing to interface with bitcoin peers at the wire
+The block header was modified to contain the claimtrie hash.
 protocol level.
 ## Installation and Updating
 ```bash
 $ go get -u github.com/btcsuite/btcd/wire
 ```
 ## 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.