diff --git a/CHANGES b/CHANGES
index 626601996..aff6f2c30 100644
--- a/CHANGES
+++ b/CHANGES
@@ -426,7 +426,7 @@ Changes in 0.9.0 (Sat Sep 20 2014)
- BIP0023 Block Proposals
- Implement built-in concurrent CPU miner
(https://github.com/conformal/btcd/issues/137)
- NOTE: CPU mining on mainnet is pointless. This has been provided
+ NOTE: CPU mining on mainnet is pointless. This has been provided
for testing purposes such as for the new simulation test network
- Add --generate flag to enable CPU mining
- Deprecate the --getworkkey flag in favor of --miningaddr which
@@ -933,7 +933,7 @@ Changes in 0.3.2 (Tue Oct 22 2013)
Changes in 0.3.1-alpha (Tue Oct 15 2013)
- Change default database to leveldb
- NOTE: This does mean you will have to redownload the block chain. Since we
+ NOTE: This does mean you will have to redownload the block chain. Since we
are still in alpha, we didn't feel writing a converter was worth the time as
it would take away from more important issues at this stage
- Add a warning if there are multiple block chain databases of different types
diff --git a/LICENSE b/LICENSE
index 10ecf9a08..7fe8161a4 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,6 +1,6 @@
ISC License
-Copyright (c) 2018-2019 DAGLabs
+Copyright (c) 2018-2019 The kaspanet developers
Copyright (c) 2013-2018 The btcsuite developers
Copyright (c) 2015-2016 The Decred developers
diff --git a/README.md b/README.md
index 264244c29..d1cbfaf32 100644
--- a/README.md
+++ b/README.md
@@ -1,49 +1,24 @@
-btcd
+
+Kaspad
+====
+Warning: This is pre-alpha software. There's no guarantee anything works.
====
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad)
Kaspad is the reference full node Kaspa 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://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.
+This project is currently under active development and is in a pre-Alpha state.
+Some things still don't work and APIs are far from finalized. The code is provided for reference only.
## Requirements
-[Go](http://golang.org) 1.8 or newer.
+Latest version of [Go](http://golang.org) (currently 1.13).
## Installation
-#### Windows - MSI Available
-
-https://github.com/kaspanet/kaspad/releases
-
-#### Linux/BSD/MacOSX/POSIX - Build from Source
+#### Build from Source
- Install Go according to the installation instructions here:
http://golang.org/doc/install
@@ -55,62 +30,39 @@ $ go version
$ go env GOROOT GOPATH
```
-NOTE: The `GOROOT` and `GOPATH` above must not be the same path. It is
+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
+`~/dev/go` 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:
+- Run the following commands to obtain and install kaspad including all dependencies:
```bash
-$ # Install dep: https://golang.github.io/dep/docs/installation.html
$ git clone https://github.com/kaspanet/kaspad $GOPATH/src/github.com/kaspanet/kaspad
$ cd $GOPATH/src/github.com/kaspanet/kaspad
-$ dep ensure
+$ ./test.sh
$ go install . ./cmd/...
```
+`./test.sh` tests can be skipped, but some things might not run correctly on your system if tests fail.
-- btcd (and utilities) will now be installed in ```$GOPATH/bin```. If you did
+- Kaspad (and utilities) should 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.
+ you are encouraged to do so now.
-## Updating
-
-#### Windows
-
-Install a newer MSI
-
-#### Linux/BSD/MacOSX/POSIX - Build from Source
-
-- Run the following commands to update btcd, all dependencies, and install it:
-
-```bash
-$ cd $GOPATH/src/github.com/kaspanet/kaspad
-$ git pull && dep ensure
-$ go install . ./cmd/...
-```
## Getting Started
-btcd has several configuration options available to tweak how it runs, but all
-of the basic operations described in the intro section work with zero
-configuration.
-
-#### Windows (Installed from MSI)
-
-Launch btcd from your Start menu.
+Kaspad has several configuration options available to tweak how it runs, but all
+of the basic operations work with zero configuration.
#### Linux/BSD/POSIX/Source
```bash
-$ ./btcd
+$ ./kaspad
```
-## IRC
-
-- irc.freenode.net
-- channel #btcd
-- [webchat](https://webchat.freenode.net/?channels=btcd)
+## Discord
+Join our discord server using the following link: https://discord.gg/WmGhhzk
## Issue Tracker
@@ -119,28 +71,9 @@ is used for this project.
## Documentation
-The documentation is a work-in-progress. It is located in the [docs](https://github.com/kaspanet/kaspad/tree/master/docs) folder.
-
-## 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
- ```
+The documentation is a work-in-progress. It is located in the [docs](https://github.com/kaspanet/kaspad/tree/master/docs) folder.
## License
-btcd is licensed under the [copyfree](http://copyfree.org) ISC License.
+Kaspad is licensed under the [copyfree](http://copyfree.org) ISC License.
+
diff --git a/blockdag/README.md b/blockdag/README.md
index b1f0c1b5e..542b147b3 100644
--- a/blockdag/README.md
+++ b/blockdag/README.md
@@ -1,33 +1,18 @@
blockchain
==========
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/blockchain)
-Package blockchain implements bitcoin block handling and chain selection rules.
-The test coverage is currently only around 60%, but will be increasing over
-time. See `test_coverage.txt` for the gocov coverage report. Alternatively, if
-you are running a POSIX OS, you can run the `cov_report.sh` script for a
-real-time report. Package blockchain is licensed under the liberal ISC license.
+Package blockdag implements Kaspa block handling, organization of the blockDAG,
+block sorting and UTXO-set maintenance.
+The test coverage is currently only around 75%, but will be increasing over
+time.
-There is an associated blog post about the release of this package
-[here](https://blog.conformal.com/btcchain-the-bitcoin-chain-package-from-bctd/).
+## Kaspad BlockDAG Processing Overview
-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/kaspanet/kaspad/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
+Before a block is allowed into the block DAG, it must go through an intensive
+series of validation rules. The following list serves as a general outline of
those rules to provide some intuition into what is going on under the hood, but
is by no means exhaustive:
@@ -35,69 +20,22 @@ is by no means exhaustive:
- Perform a series of sanity checks on the block and its transactions such as
verifying proof of work, timestamps, number and character of transactions,
transaction amounts, script complexity, and merkle root calculations
- - Compare the block against predetermined checkpoints for expected timestamps
- and difficulty based on elapsed time since the checkpoint
- Save the most recent orphan blocks for a limited time in case their parent
- blocks become available
- - Stop processing if the block is an orphan as the rest of the processing
- depends on the block's position within the block chain
+ blocks become available.
+ - Save blocks from the future for delayed processing
+ - Stop processing if the block is an orphan or delayed as the rest of the
+ processing depends on the block's position within the block chain
+ - Make sure the block does not violate finality rules
- Perform a series of more thorough checks that depend on the block's position
- within the block chain such as verifying block difficulties adhere to
+ within the blockDAG such as verifying block difficulties adhere to
difficulty retarget rules, timestamps are after the median of the last
several blocks, all transactions are finalized, checkpoint blocks match, and
block versions are in line with the previous blocks
- - Determine how the block fits into the chain and perform different actions
- accordingly in order to ensure any side chains which have higher difficulty
- than the main chain become the new main chain
- - When a block is being connected to the main chain (either through
- reorganization of a side chain to the main chain or just extending the
- main chain), perform further checks on the block's transactions such as
- verifying transaction duplicates, script complexity for the combination of
- connected scripts, coinbase maturity, double spends, and connected
- transaction values
+ - Determine how the block fits into the DAG and perform different actions
+ accordingly
- Run the transaction scripts to verify the spender is allowed to spend the
coins
+ - Run GhostDAG to fit the block in a canonical sorting
+ - Build the block's UTXO Set, as well as update the global UTXO Set accordingly
- Insert the block into the block database
-## Examples
-
-* [ProcessBlock Example](http://godoc.org/github.com/kaspanet/kaspad/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](http://godoc.org/github.com/kaspanet/kaspad/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](http://godoc.org/github.com/kaspanet/kaspad/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.
diff --git a/blockdag/fullblocktests/README.md b/blockdag/fullblocktests/README.md
index e4f81bf13..4705ba4f6 100644
--- a/blockdag/fullblocktests/README.md
+++ b/blockdag/fullblocktests/README.md
@@ -6,9 +6,9 @@ fullblocktests
[](http://godoc.org/github.com/kaspanet/kaspad/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
+the consensus validation rules. The tests are intended to be flexible enough to
allow both unit-style tests directly against the blockchain code as well as
-integration style tests over the peer-to-peer network. To achieve that goal,
+integration style tests over the peer-to-peer network. To achieve that goal,
each test contains additional information about the expected result, however
that information can be ignored when doing comparison tests between two
independent versions over the peer-to-peer network.
diff --git a/blockdag/indexers/README.md b/blockdag/indexers/README.md
index 18c7b72bc..0c1b67414 100644
--- a/blockdag/indexers/README.md
+++ b/blockdag/indexers/README.md
@@ -1,9 +1,8 @@
indexers
========
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
-[](http://godoc.org/github.com/kaspanet/kaspad/blockchain/indexers)
+[](http://godoc.org/github.com/kaspanet/kaspad/blockdag/indexers)
Package indexers implements optional block chain indexes.
@@ -12,21 +11,14 @@ via an RPC interface.
## Supported Indexers
-- Transaction-by-hash (txbyhashidx) Index
+- Transaction-by-hash (txindex) Index
- Creates a mapping from the hash of each transaction to the block that
contains it along with its offset and length within the serialized block
-- Transaction-by-address (txbyaddridx) Index
+- Transaction-by-address (addrindex) Index
- Creates a mapping from every address to all transactions which either credit
or debit the address
- Requires the transaction-by-hash index
+- AcceptanceData-by-block Index
+ - Creates a mapping from the hash of each block to the list of transaction this block
+ accepts from it's .Blues
-## Installation
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/blockchain/indexers
-```
-
-## License
-
-Package indexers is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/connmgr/README.md b/connmgr/README.md
index 7d87ab5c0..7d9646da3 100644
--- a/connmgr/README.md
+++ b/connmgr/README.md
@@ -1,11 +1,10 @@
connmgr
=======
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/connmgr)
-Package connmgr implements a generic Bitcoin network connection manager.
+Package connmgr implements a generic Kaspa network connection manager.
## Overview
@@ -26,12 +25,3 @@ In addition the connection manager provides the following utilities:
- Permanent connections with increasing backoff retry timers
- Disconnect or Remove an established connection
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/connmgr
-```
-
-## License
-
-Package connmgr is licensed under the [copyfree](http://copyfree.org) ISC License.
diff --git a/dagconfig/README.md b/dagconfig/README.md
index cd83fe9bb..f5c8c538e 100644
--- a/dagconfig/README.md
+++ b/dagconfig/README.md
@@ -1,18 +1,12 @@
-chaincfg
+dagconfig
========
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
-[](http://godoc.org/github.com/kaspanet/kaspad/chaincfg)
+[](http://godoc.org/github.com/kaspanet/kaspad/dagconfig)
-Package chaincfg defines chain configuration parameters for the three standard
-Bitcoin networks and provides the ability for callers to define their own custom
-Bitcoin networks.
-
-Although this package was primarily written for btcd, it has intentionally been
-designed so it can be used as a standalone package for any projects needing to
-use parameters for the standard Bitcoin networks or for projects needing to
-define their own network.
+Package dagconfig defines DAG configuration parameters for the four standard
+Kaspad networks and provides the ability for callers to define their own custom
+Kaspad networks.
## Sample Use
@@ -24,62 +18,31 @@ import (
"fmt"
"log"
- "github.com/kaspanet/kaspad/btcutil"
- "github.com/kaspanet/kaspad/chaincfg"
+ "github.com/kaspanet/kaspad/util"
+ "github.com/kaspanet/kaspad/dagconfig"
)
-var testnet = flag.Bool("testnet", false, "operate on the testnet Bitcoin network")
+var testnet = flag.Bool("testnet", false, "operate on the testnet Kaspa network")
-// By default (without -testnet), use mainnet.
-var chainParams = &chaincfg.MainNetParams
+// By default (without --testnet), use mainnet.
+var chainParams = &dagconfig.MainNetParams
func main() {
flag.Parse()
// Modify active network parameters if operating on testnet.
if *testnet {
- chainParams = &chaincfg.TestNetParams
+ dagParams = &dagconfig.TestNetParams
}
// later...
// Create and print new payment address, specific to the active network.
pubKeyHash := make([]byte, 20)
- addr, err := btcutil.NewAddressPubKeyHash(pubKeyHash, chainParams)
+ addr, err := util.NewAddressPubKeyHash(pubKeyHash, dagParams)
if err != nil {
log.Fatal(err)
}
fmt.Println(addr)
}
```
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/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.
diff --git a/database/README.md b/database/README.md
index 84ed17907..9e324125a 100644
--- a/database/README.md
+++ b/database/README.md
@@ -1,32 +1,28 @@
database
========
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/database)
Package database provides a block and metadata storage database.
-Please note that this package is intended to enable btcd to support different
+Please note that this package is intended to enable kaspad to support different
database backends and is not something that a client can directly access as only
one entity can have the database open at a time (for most database backends),
-and that entity will be btcd.
+and that entity will be kaspad.
-When a client wants programmatic access to the data provided by btcd, they'll
+When a client wants programmatic access to the data provided by kaspad, they'll
likely want to use the [rpcclient](https://github.com/kaspanet/kaspad/tree/master/rpcclient)
package which makes use of the [JSON-RPC API](https://github.com/kaspanet/kaspad/tree/master/docs/json_rpc_api.md).
-However, this package could be extremely useful for any applications requiring
-Bitcoin block storage capabilities.
-
The default backend, ffldb, has a strong focus on speed, efficiency, and
-robustness. It makes use of leveldb for the metadata, flat files for block
+robustness. It makes use of leveldb for the metadata, flat files for block
storage, and strict checksums in key areas to ensure data integrity.
## Feature Overview
- Key/value metadata store
-- Bitcoin block storage
+- Kaspa block storage
- Efficient retrieval of block headers and regions (transactions, scripts, etc)
- Read-only and read-write transactions with both manual and managed modes
- Nested buckets
@@ -34,24 +30,3 @@ storage, and strict checksums in key areas to ensure data integrity.
- Supports registration of backend databases
- Comprehensive test coverage
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/database
-```
-
-## Examples
-
-* [Basic Usage Example](http://godoc.org/github.com/kaspanet/kaspad/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](http://godoc.org/github.com/kaspanet/kaspad/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.
diff --git a/database/ffldb/README.md b/database/ffldb/README.md
index f6b4355a2..9adf49fd5 100644
--- a/database/ffldb/README.md
+++ b/database/ffldb/README.md
@@ -1,7 +1,6 @@
ffldb
=====
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/database/ffldb)
=======
@@ -9,16 +8,14 @@ ffldb
Package ffldb implements a driver for the database package that uses leveldb for
the backing metadata and flat files for block storage.
-This driver is the recommended driver for use with btcd. It makes use leveldb
+This driver is the recommended driver for use with kaspad. It makes use of leveldb
for the metadata, flat files for block storage, and checksums in key areas to
ensure data integrity.
-Package ffldb is licensed under the copyfree ISC license.
-
## Usage
This package is a driver to the database package and provides the database type
-of "ffldb". The parameters the Open and Create functions take are the
+of "ffldb". The parameters the Open and Create functions take are the
database path as a string and the block network.
```Go
@@ -35,7 +32,3 @@ if err != nil {
}
```
-## License
-
-Package ffldb is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/database/internal/treap/README.md b/database/internal/treap/README.md
index 3a8f57d88..5c4e4b5da 100644
--- a/database/internal/treap/README.md
+++ b/database/internal/treap/README.md
@@ -1,39 +1,27 @@
treap
=====
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/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.
It is a self-organizing and randomized data structure that doesn't require
-complex operations to to maintain balance. Search, insert, and delete
-operations are all O(log n). Both mutable and immutable variants are provided.
+complex operations to to maintain balance. Search, insert, and delete
+operations are all O(log n). Both mutable and immutable variants are provided.
The mutable variant is typically faster since it is able to simply update the
-treap when modifications are made. However, a mutable treap is not safe for
+treap when modifications are made. However, a mutable treap is not safe for
concurrent access without careful use of locking by the caller and care must be
taken when iterating since it can change out from under the iterator.
The immutable variant works by creating a new version of the treap for all
mutations by replacing modified nodes with new nodes that have updated values
-while sharing all unmodified nodes with the previous version. This is extremely
+while sharing all unmodified nodes with the previous version. This is extremely
useful in concurrent applications since the caller only has to atomically
replace the treap pointer with the newly returned version after performing any
-mutations. All readers can simply use their existing pointer as a snapshot
-since the treap it points to is immutable. This effectively provides O(1)
+mutations. All readers can simply use their existing pointer as a snapshot
+since the treap it points to is immutable. This effectively provides O(1)
snapshot capability with efficient memory usage characteristics since the old
nodes only remain allocated until there are no longer any references to them.
-Package treap is licensed under the copyfree ISC license.
-
-## Usage
-
-This package is only used internally in the database code and as such is not
-available for use outside of it.
-
-## License
-
-Package treap is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/dnsseeder/README.md b/dnsseeder/README.md
index cbe9145d5..4e8875c78 100644
--- a/dnsseeder/README.md
+++ b/dnsseeder/README.md
@@ -3,50 +3,56 @@ dnsseeder
## Requirements
-[Go](http://golang.org) 1.10 or newer.
+Latest version of [Go](http://golang.org) (currently 1.13)
## Getting Started
+- Install Go according to the installation instructions here:
+ http://golang.org/doc/install
+
+- Ensure Go was installed properly and is a supported version:
+
+- Launch a kaspad node for the dnsseeder to connect to
+
+```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
+`~/dev/go` 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 dnsseeder, all dependencies, and install it:
+
+```bash
+$ git clone https://github.com/kaspanet/dnsseeder $GOPATH/src/github.com/kaspanet/dnsseeder
+$ cd $GOPATH/src/github.com/kaspanet/dnsseeder
+$ go install .
+```
+
- dnsseeder will now be installed in either ```$GOROOT/bin``` or
- ```$GOPATH/bin``` depending on your configuration. If you did not already
+ ```$GOPATH/bin``` depending on your configuration. If you did not already
add the bin directory to your system path during Go installation, we
recommend you do so now.
-### Build from source (all platforms)
-
-Building or updating from source requires the following build dependencies:
-
-- **Go 1.10 or 1.11**
-
- Installation instructions can be found here: https://golang.org/doc/install.
- It is recommended to add `$GOPATH/bin` to your `PATH` at this point.
-
-- **Vgo (Go 1.10 only)**
-
-To build and install from a checked-out repo, run `go install` in the repo's
-root directory. Some notes:
-
-* Replace `go` with `vgo` when using Go 1.10.
-
-* The `dnsseeder` executable will be installed to `$GOPATH/bin`. `GOPATH`
- defaults to `$HOME/go` (or `%USERPROFILE%\go` on Windows) if unset.
-
-For more information about Daglabs and how to set up your software please go to
-our docs page at [docs.daglabs.org](https://docs.daglabs.org/getting-started/beginner-guide/).
-
-To start dnsseeder listening on udp 127.0.0.1:5354 with an initial connection to working testnet node 192.168.0.1:
+To start dnsseeder listening on udp 127.0.0.1:5354 with an initial connection to working testnet node running on 127.0.0.1:
```
-$ ./dnsseeder -n nameserver.example.com -H network-seed.example.com -s 192.168.0.1 --testnet
+$ ./dnsseeder -n nameserver.example.com -H network-seed.example.com -s 127.0.0.1 --testnet
```
You will then need to redirect DNS traffic on your public IP port 53 to 127.0.0.1:5354
+Note: to listen directly on port 53 on most Unix systems, one has to run dnsseeder as root, which is discouraged
-## Issue Tracker
+## Setting up DNS Records
-The [integrated github issue tracker](https://github.com/daglabs/dnsseeder/issues)
-is used for this project.
+To create a working set-up where dnsseeder can provide IPs to kaspad instances, set the following DNS records:
+```
+NAME TYPE VALUE
+---- ---- -----
+[your.domain.name] A [your ip address]
+[ns-your.domain.name] NS [your.domain.name]
+```
-## License
-
-dnsseeder is licensed under the [copyfree](http://copyfree.org) ISC License.
diff --git a/dnsseeder/config.go b/dnsseeder/config.go
index 3d8c8e843..0142ef0bb 100644
--- a/dnsseeder/config.go
+++ b/dnsseeder/config.go
@@ -6,13 +6,14 @@ package main
import (
"fmt"
- "github.com/kaspanet/kaspad/config"
- "github.com/pkg/errors"
"net"
"os"
"path/filepath"
"strings"
+ "github.com/kaspanet/kaspad/config"
+ "github.com/pkg/errors"
+
"github.com/jessevdk/go-flags"
"github.com/kaspanet/kaspad/util"
)
diff --git a/docs/README.md b/docs/README.md
index c3bae6f58..326cdc3cc 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -28,28 +28,28 @@
btcd is a full node bitcoin implementation written in [Go](http://golang.org),
licensed under the [copyfree](http://www.copyfree.org) ISC License.
-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. 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
+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
+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
+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
+wallet functionality and this was a very intentional design decision. See the
blog entry [here](https://blog.conformal.com/btcd-not-your-moms-bitcoin-daemon)
-for more details. This means you can't actually make or receive payments
-directly with btcd. That functionality is provided by the
+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.
@@ -62,7 +62,7 @@ which are both under active development.
**2.1 Installation**
-The first step is to install btcd. See one of the following sections for
+The first step is to install btcd. See one of the following sections for
details on how to install on the supported operating systems.
@@ -87,9 +87,9 @@ $ go version
$ go env GOROOT GOPATH
```
-NOTE: The `GOROOT` and `GOPATH` above must not be the same path. It is
+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
+`~/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:
@@ -102,7 +102,7 @@ $ glide install
$ go install . ./cmd/...
```
-- btcd (and utilities) will now be installed in ```$GOPATH/bin```. If you did
+- 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.
@@ -137,7 +137,7 @@ options, which can be viewed by running: `$ btcd --help`.
**2.3 Controlling and Querying btcd via btcctl**
btcctl is a command line utility that can be used to both control and query btcd
-via [RPC](http://www.wikipedia.org/wiki/Remote_procedure_call). btcd does
+via [RPC](http://www.wikipedia.org/wiki/Remote_procedure_call). btcd 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:
@@ -229,7 +229,7 @@ configuration necessary, however, there is an optional method to use a
**3.1 Wallet**
btcd was intentionally developed without an integrated wallet for security
-reasons. Please see [btcwallet](https://github.com/btcsuite/btcwallet) for more
+reasons. Please see [btcwallet](https://github.com/btcsuite/btcwallet) for more
information.
diff --git a/docs/code_contribution_guidelines.md b/docs/code_contribution_guidelines.md
index 98ea9c685..21c232683 100644
--- a/docs/code_contribution_guidelines.md
+++ b/docs/code_contribution_guidelines.md
@@ -22,17 +22,17 @@
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
+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
+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
+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 kaspad 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
@@ -43,9 +43,9 @@ to the guidelines established on this page.
### 2. 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
+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
+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.
@@ -59,7 +59,7 @@ contribute.
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,
+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.
@@ -69,9 +69,9 @@ security and performance implications.
### 3. 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,
+ 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
+- [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.
@@ -86,7 +86,7 @@ branch.
### 4.1 Share Early, Share Often
-We firmly believe in the share early, share often approach. The basic premise
+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.
@@ -110,19 +110,19 @@ This approach has several benefits:
### 4.2 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
+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
+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
+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:
@@ -156,7 +156,7 @@ 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
+// big integer. The representation is similar to IEEE754 floating point
// numbers.
//
// Like IEEE754 floating point, there are three basic components: the sign,
@@ -207,8 +207,8 @@ comment can make.
### 4.4 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
+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.
@@ -217,9 +217,9 @@ Here’s a model Git commit message:
```
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
+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.
@@ -251,7 +251,7 @@ a good thing.
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
+ 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.
@@ -260,14 +260,14 @@ a good thing.
### 5. 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.
+contributions. This is how to get your changes into btcd.
### 5.1 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
+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
@@ -275,21 +275,21 @@ other committers who are interested in the area you are working in as well.
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
+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
+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
+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
+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
@@ -303,9 +303,9 @@ checks which are generally performed as follows:
### 5.2 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
+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
+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.
@@ -317,7 +317,7 @@ This process will continue until the code is finally accepted.
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,
+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.
@@ -351,5 +351,5 @@ Rejoice as you will now be listed as a [contributor](https://github.com/kaspanet
### 6.2. Licensing of Contributions
All contributions must be licensed with the
-[ISC license](https://github.com/kaspanet/kaspad/blob/master/LICENSE). This is
+[ISC license](https://github.com/kaspanet/kaspad/blob/master/LICENSE). This is
the same license as all of the code in the btcd suite.
diff --git a/docs/configure_peer_server_listen_interfaces.md b/docs/configure_peer_server_listen_interfaces.md
index 26f5ec72a..e5839789c 100644
--- a/docs/configure_peer_server_listen_interfaces.md
+++ b/docs/configure_peer_server_listen_interfaces.md
@@ -1,5 +1,5 @@
btcd allows you to bind to specific interfaces which enables you to setup
-configurations with varying levels of complexity. The listen parameter can be
+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).
The configuration file takes one entry per line.
diff --git a/docs/configure_rpc_server_listen_interfaces.md b/docs/configure_rpc_server_listen_interfaces.md
index 3115d6a16..2554e91a4 100644
--- a/docs/configure_rpc_server_listen_interfaces.md
+++ b/docs/configure_rpc_server_listen_interfaces.md
@@ -1,24 +1,24 @@
btcd allows you to bind the RPC server to specific interfaces which enables you
-to setup configurations with varying levels of complexity. The `rpclisten`
+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
-options). The configuration file takes one entry per line.
+options). The configuration file takes one entry per line.
A few things to note regarding the RPC server:
* The RPC server will **not** be enabled unless the `rpcuser` and `rpcpass`
options are specified.
* When the `rpcuser` and `rpcpass` and/or `rpclimituser` and `rpclimitpass`
options are specified, the RPC server will only listen on localhost IPv4 and
- IPv6 interfaces by default. You will need to override the RPC listen
+ IPv6 interfaces by default. You will need to override the RPC listen
interfaces to include external interfaces if you want to connect from a remote
machine.
-* The RPC server has TLS enabled by default, even for localhost. You may use
+* The RPC server has TLS enabled by default, even for localhost. You may use
the `--notls` option to disable it, but only when all listeners are on
localhost interfaces.
* The `--rpclisten` flag can be specified multiple times to listen on multiple
interfaces as a couple of the examples below illustrate.
* The RPC server is disabled by default when using the `--regtest` and
- `--simnet` networks. You can override this by specifying listen interfaces.
+ `--simnet` networks. You can override this by specifying listen interfaces.
Command Line Examples:
diff --git a/docs/configuring_tor.md b/docs/configuring_tor.md
index 442930d6e..b0d9d674c 100644
--- a/docs/configuring_tor.md
+++ b/docs/configuring_tor.md
@@ -24,14 +24,14 @@
btcd 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, btcd 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.
While it is easier to only run as a client, it is more beneficial to the Bitcoin
network to run as both a client and a server so others may connect to you to as
-you are connecting to them. We recommend you take the time to setup a Tor
+you are connecting to them. We recommend you take the time to setup a Tor
hidden service for this reason.
@@ -42,12 +42,12 @@ hidden service for this reason.
**2.1 Description**
-Configuring btcd as a Tor client is straightforward. The first step is
+Configuring btcd as a Tor client is straightforward. The first step is
obviously to install Tor and ensure it is working. Once that is done, all that
typically needs to be done is to specify the `--proxy` flag via the btcd command
-line or in the btcd configuration file. Typically the Tor proxy address will be
+line or in the btcd 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,
+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
@@ -84,9 +84,9 @@ proxy=127.0.0.1:9050
**3.1 Description**
-The first step is to configure Tor to provide a hidden service. Documentation
+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,
+[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.
@@ -138,18 +138,18 @@ externalip=fooanon.onion
**4.1 Description**
btcd 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
+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
-configuration file. If you have Tor configured to require a username and
+configuration file. If you have Tor configured to require a username and
password, you may specify them with the `--onionuser` and `--onionpass` flags.
NOTE: This mode will also work in conjunction with a hidden service which means
you could accept inbound connections both via the normal network and to your
-hidden service through the Tor network. To enable your hidden service in bridge
+hidden service through the Tor network. To enable your hidden service in bridge
mode, you only need to specify your hidden service's .onion address via the
`--externalip` flag since traffic to and from .onion addresses are already
routed via Tor due to the `--onion` flag.
@@ -185,7 +185,7 @@ 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`
-flag. This option requires --proxy or --onionproxy to be set.
+flag. This option requires --proxy or --onionproxy to be set.
diff --git a/docs/default_ports.md b/docs/default_ports.md
index 14e4eea2a..deb7120c8 100644
--- a/docs/default_ports.md
+++ b/docs/default_ports.md
@@ -3,7 +3,7 @@ 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
-peer-to-peer listening port if your router supports UPnP. If your router does
+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
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
diff --git a/docs/json_rpc_api.md b/docs/json_rpc_api.md
index d9d199644..1412963ac 100644
--- a/docs/json_rpc_api.md
+++ b/docs/json_rpc_api.md
@@ -2,9 +2,9 @@
1. [Overview](#Overview)
2. [HTTP POST Versus Websockets](#HttpPostVsWebsockets)
3. [Authentication](#Authentication)
-3.1. [Overview](#AuthenticationOverview)
-3.2. [HTTP Basic Access Authentication](#HTTPAuth)
-3.3. [JSON-RPC Authenticate Command (Websocket-specific)](#JSONAuth)
+3.1. [Overview](#AuthenticationOverview)
+3.2. [HTTP Basic Access Authentication](#HTTPAuth)
+3.3. [JSON-RPC Authenticate Command (Websocket-specific)](#JSONAuth)
4. [Command-line Utility](#CLIUtil)
5. [Standard Methods](#Methods)
5.1. [Method Overview](#MethodOverview)
@@ -27,14 +27,14 @@
### 1. Overview
btcd provides a [JSON-RPC](http://json-rpc.org/wiki/specification) API that is
-fully compatible with the original bitcoind/bitcoin-qt. There are a few key
+fully compatible with the original bitcoind/bitcoin-qt. There are a few key
differences between btcd and bitcoind as far as how RPCs are serviced:
* Unlike bitcoind that has the wallet and chain intermingled in the same process
which leads to several issues, btcd intentionally splits the wallet and chain
- services into independent processes. See the blog post
+ services into independent processes. See the blog post
[here](https://blog.conformal.com/btcd-not-your-moms-bitcoin-daemon/) for
- further details on why they were separated. This means that if you are
- talking directly to btcd, only chain-related RPCs are available. However both
+ further details on why they were separated. This means that if you are
+ talking directly to btcd, only chain-related RPCs are available. However both
chain-related and wallet-related RPCs are available via
[btcwallet](https://github.com/btcsuite/btcwallet).
* btcd is secure by default which means that the RPC connection is TLS-enabled
@@ -45,7 +45,7 @@ differences between btcd and bitcoind as far as how RPCs are serviced:
Websockets are the preferred transport for btcd RPC and are used by applications
such as [btcwallet](https://github.com/btcsuite/btcwallet) for inter-process
-communication with btcd. The websocket connection endpoint for btcd is
+communication with btcd. The websocket connection endpoint for btcd is
`wss://your_ip_or_domain:8334/ws`.
In addition to the [standard API](#Methods), an [extension API](#WSExtMethods)
@@ -66,7 +66,7 @@ The original bitcoind/bitcoin-qt JSON-RPC API documentation is available at [htt
The btcd RPC server supports both [HTTP POST](http://en.wikipedia.org/wiki/POST_%28HTTP%29)
requests and the preferred [Websockets](http://en.wikipedia.org/wiki/WebSocket).
All of the [standard](#Methods) and [extension](#ExtensionMethods) methods
-described in this documentation can be accessed through both. As the name
+described in this documentation can be accessed through both. As the name
indicates, the [Websocket-specific extension](#WSExtMethods) methods can only be
accessed when connected via Websockets.
@@ -98,7 +98,7 @@ to a btcd RPC server:
* **rpclimituser** is the limited username configured for the btcd RPC server
* **rpclimitpass** is the limited password configured for the btcd RPC server
* **rpccert** is the PEM-encoded X.509 certificate (public key) that the btcd
- server is configured with. It is automatically generated by btcd and placed
+ server is configured with. It is automatically generated by btcd and placed
in the btcd home directory (which is typically `%LOCALAPPDATA%\Btcd` on
Windows and `~/.btcd` on POSIX-like OSes)
@@ -117,7 +117,7 @@ two, mutually exclusive, methods.
**3.2 HTTP Basic Access Authentication**
The btcd RPC server uses HTTP [basic access authentication](http://en.wikipedia.org/wiki/Basic_access_authentication) with the **rpcuser**
-and **rpcpass** detailed above. If the supplied credentials are invalid, you
+and **rpcpass** detailed above. If the supplied credentials are invalid, you
will be disconnected immediately upon making the connection.
@@ -125,11 +125,11 @@ will be disconnected immediately upon making the connection.
**3.3 JSON-RPC Authenticate Command (Websocket-specific)**
While the HTTP basic access authentication method is the preferred method, the
-ability to set HTTP headers from websockets is not always available. In that
+ability to set HTTP headers from websockets is not always available. In that
case, you will need to use the [authenticate](#authenticate) JSON-RPC method.
The [authenticate](#authenticate) command must be the first command sent after
-connecting to the websocket. Sending any other commands before authenticating,
+connecting to the websocket. Sending any other commands before authenticating,
supplying invalid credentials, or attempting to authenticate again when already
authenticated will cause the websocket to be closed immediately.
@@ -140,7 +140,7 @@ authenticated will cause the websocket to be closed immediately.
btcd comes with a separate utility named `btcctl` which can be used to issue
these RPC commands via HTTP POST requests to btcd after configuring it with the
-information in the [Authentication](#Authentication) section above. It can also
+information in the [Authentication](#Authentication) section above. It can also
be used to communicate with any server/daemon/service which provides a JSON-RPC
API compatible with the original bitcoind/bitcoin-qt client.
@@ -152,7 +152,7 @@ API compatible with the original bitcoind/bitcoin-qt client.
**5.1 Method Overview**
-The following is an overview of the RPC methods and their current status. Click
+The following is an overview of the RPC methods and their current status. Click
the method name for further details such as parameter and return information.
|#|Method|Safe for limited user?|Description|
@@ -184,7 +184,7 @@ the method name for further details such as parameter and return information.
|26|[setgenerate](#setgenerate) |N|Set the server to generate coins (mine) or not.
NOTE: Since btcd does not have the wallet integrated to provide payment addresses, btcd must be configured via the `--miningaddr` option to provide which payment addresses to pay created blocks to for this RPC to function.|
|27|[stop](#stop)|N|Shutdown btcd.|
|28|[submitblock](#submitblock)|Y|Attempts to submit a new serialized, hex-encoded block to the network.|
-|29|[validateaddress](#validateaddress)|Y|Verifies the given address is valid. NOTE: Since btcd does not have a wallet integrated, btcd will only return whether the address is valid or not.|
+|29|[validateaddress](#validateaddress)|Y|Verifies the given address is valid. NOTE: Since btcd does not have a wallet integrated, btcd will only return whether the address is valid or not.|
|30|[verifychain](#verifychain)|N|Verifies the block chain database.|
@@ -207,11 +207,11 @@ the method name for further details such as parameter and return information.
| | |
|---|---|
|Method|createrawtransaction|
-|Parameters|1. transaction inputs (JSON array, required) - json array of json objects
`[`
`{`
`"txid": "hash", (string, required) the hash of the input transaction`
`"vout": n (numeric, required) the specific output of the input transaction to redeem`
`}, ...`
`]`
2. addresses and amounts (JSON object, required) - json object with addresses as keys and amounts as values
`{`
`"address": n.nnn (numeric, required) the address to send to as the key and the amount in BTC as the value`
`, ...`
`}`
3. locktime (uint64, optional, default=0) - specifies the transaction locktime. If non-zero, the inputs will also have their locktimes activated. |
+|Parameters|1. transaction inputs (JSON array, required) - json array of json objects
`[`
`{`
`"txid": "hash", (string, required) the hash of the input transaction`
`"vout": n (numeric, required) the specific output of the input transaction to redeem`
`}, ...`
`]`
2. addresses and amounts (JSON object, required) - json object with addresses as keys and amounts as values
`{`
`"address": n.nnn (numeric, required) the address to send to as the key and the amount in BTC as the value`
`, ...`
`}`
3. locktime (uint64, optional, default=0) - specifies the transaction locktime. If non-zero, the inputs will also have their locktimes activated. |
|Description|Returns a new transaction spending the provided inputs and sending to the provided addresses.
The transaction inputs are not signed in the created transaction.
The `signrawtransaction` RPC command provided by wallet must be used to sign the resulting transaction.|
|Returns|`"transaction" (string) hex-encoded bytes of the serialized transaction`|
|Example Parameters|1. transaction inputs `[{"txid":"e6da89de7a6b8508ce8f371a3d0535b04b5e108cb1a6e9284602d3bfd357c018","vout":1}]`
2. addresses and amounts `{"13cgrTP7wgbZYWrY9BZ22BV6p82QXQT3nY": 0.49213337}`
3. locktime `0`|
-|Example Return|`010000000118c057d3bfd3024628e9a6b18c105e4bb035053d1a378fce08856b7ade89dae6010000`
`0000ffffffff0199efee02000000001976a9141cb013db35ecccc156fdfd81d03a11c51998f99388`
`ac00000000`
**Newlines added for display purposes. The actual return does not contain newlines.**|
+|Example Return|`010000000118c057d3bfd3024628e9a6b18c105e4bb035053d1a378fce08856b7ade89dae6010000`
`0000ffffffff0199efee02000000001976a9141cb013db35ecccc156fdfd81d03a11c51998f99388`
`ac00000000`
**Newlines added for display purposes. The actual return does not contain newlines.**|
[Return to Overview](#MethodOverview)
***
@@ -275,7 +275,7 @@ the method name for further details such as parameter and return information.
|Returns (verbose=false)|`"data" (string) hex-encoded bytes of the serialized block`|
|Returns (verbose=true, verbosetx=false)|`{ (json object)`
`"hash": "blockhash", (string) the hash of the block (same as provided)`
`"confirmations": n, (numeric) the number of confirmations`
`"size", n (numeric) the size of the block`
`"size": n, (numeric) the size of the block`
`"height": n, (numeric) the height of the block in the block chain`
`"version": n, (numeric) the block version`
`"merkleroot": "hash", (string) root hash of the merkle tree`
`"tx": [ (json array of string) the transaction hashes`
`"transactionhash", (string) hash of the parent transaction`
`...`
`]`
`"time": n, (numeric) the block time in seconds since 1 Jan 1970 GMT`
`"nonce": n, (numeric) the block nonce`
`"bits", n, (numeric) the bits which represent the block difficulty`
`difficulty: n.nn, (numeric) the proof-of-work difficulty as a multiple of the minimum difficulty`
`"previousblockhash": "hash", (string) the hash of the previous block`
`"nextblockhash": "hash", (string) the hash of the next block (only if there is one)`
`}`|
|Returns (verbose=true, verbosetx=true)|`{ (json object)`
`"hash": "blockhash", (string) the hash of the block (same as provided)`
`"confirmations": n, (numeric) the number of confirmations`
`"size", n (numeric) the size of the block`
`"size": n, (numeric) the size of the block`
`"height": n, (numeric) the height of the block in the block chain`
`"version": n, (numeric) the block version`
`"merkleroot": "hash", (string) root hash of the merkle tree`
`"rawtx": [ (array of json objects) the transactions as json objects`
`(see getrawtransaction json object details)`
`]`
`"time": n, (numeric) the block time in seconds since 1 Jan 1970 GMT`
`"nonce": n, (numeric) the block nonce`
`"bits", n, (numeric) the bits which represent the block difficulty`
`difficulty: n.nn, (numeric) the proof-of-work difficulty as a multiple of the minimum difficulty`
`"previousblockhash": "hash", (string) the hash of the previous block`
`"nextblockhash": "hash", (string) the hash of the next block`
`}`|
-|Example Return (verbose=false)|`"010000000000000000000000000000000000000000000000000000000000000000000000`
`3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49`
`ffff001d1dac2b7c01010000000100000000000000000000000000000000000000000000`
`00000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f`
`4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f`
`6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104`
`678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f`
`4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000"`
**Newlines added for display purposes. The actual return does not contain newlines.**|
+|Example Return (verbose=false)|`"010000000000000000000000000000000000000000000000000000000000000000000000`
`3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49`
`ffff001d1dac2b7c01010000000100000000000000000000000000000000000000000000`
`00000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f`
`4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f`
`6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104`
`678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f`
`4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000"`
**Newlines added for display purposes. The actual return does not contain newlines.**|
|Example Return (verbose=true, verbosetx=false)|`{`
`"hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",`
`"confirmations": 277113,`
`"size": 285,`
`"height": 0,`
`"version": 1,`
`"merkleroot": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",`
`"tx": [`
`"4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"`
`],`
`"time": 1231006505,`
`"nonce": 2083236893,`
`"bits": "1d00ffff",`
`"difficulty": 1,`
`"previousblockhash": "0000000000000000000000000000000000000000000000000000000000000000",`
`"nextblockhash": "ec85da8297525c2a2a5f3e826510ea1a48ee741e13a18b93ceeb2fb6c9848925,"`
`}`|
[Return to Overview](#MethodOverview)
@@ -313,7 +313,7 @@ the method name for further details such as parameter and return information.
|Description|Returns hex-encoded bytes of the serialized block header.|
|Returns (verbose=false)|`"data" (string) hex-encoded bytes of the serialized block`|
|Returns (verbose=true)|`{ (json object)`
`"hash": "blockhash", (string) the hash of the block (same as provided)`
`"confirmations": n, (numeric) the number of confirmations`
`"height": n, (numeric) the height of the block in the block chain`
`"version": n, (numeric) the block version`
`"merkleroot": "hash", (string) root hash of the merkle tree`
`"time": n, (numeric) the block time in seconds since 1 Jan 1970 GMT`
`"nonce": n, (numeric) the block nonce`
`"bits": n, (numeric) the bits which represent the block difficulty`
`"difficulty": n.nn, (numeric) the proof-of-work difficulty as a multiple of the minimum difficulty`
`"previousblockhash": "hash", (string) the hash of the previous block`
`"nextblockhash": "hash", (string) the hash of the next block (only if there is one)`
`}`|
-|Example Return (verbose=false)|`"0200000035ab154183570282ce9afc0b494c9fc6a3cfea05aa8c1add2ecc564900000000`
`38ba3d78e4500a5a7570dbe61960398add4410d278b21cd9708e6d9743f374d544fc0552`
`27f1001c29c1ea3b"`
**Newlines added for display purposes. The actual return does not contain newlines.**|
+|Example Return (verbose=false)|`"0200000035ab154183570282ce9afc0b494c9fc6a3cfea05aa8c1add2ecc564900000000`
`38ba3d78e4500a5a7570dbe61960398add4410d278b21cd9708e6d9743f374d544fc0552`
`27f1001c29c1ea3b"`
**Newlines added for display purposes. The actual return does not contain newlines.**|
|Example Return (verbose=true)|`{`
`"hash": "00000000009e2958c15ff9290d571bf9459e93b19765c6801ddeccadbb160a1e",`
`"confirmations": 392076,`
`"height": 100000,`
`"version": 2,`
`"merkleroot": "d574f343976d8e70d91cb278d21044dd8a396019e6db70755a0a50e4783dba38",`
`"time": 1376123972,`
`"nonce": 1005240617,`
`"bits": "1c00f127",`
`"difficulty": 271.75767393,`
`"previousblockhash": "000000004956cc2edd1a8caa05eacfa3c69f4c490bfc9ace820257834115ab35",`
`"nextblockhash": "0000000000629d100db387f37d0f37c51118f250fb0946310a8c37316cbc4028"`
`}`|
[Return to Overview](#MethodOverview)
@@ -371,7 +371,7 @@ the method name for further details such as parameter and return information.
|Method|getinfo|
|Parameters|None|
|Description|Returns a JSON object containing various state info.|
-|Notes|NOTE: Since btcd does NOT contain wallet functionality, wallet-related fields are not returned. See getinfo in btcwallet for a version which includes that information.|
+|Notes|NOTE: Since btcd does NOT contain wallet functionality, wallet-related fields are not returned. See getinfo in btcwallet for a version which includes that information.|
|Returns|`{ (json object)`
`"version": n, (numeric) the version of the server`
`"protocolversion": n, (numeric) the latest supported protocol version`
`"blocks": n, (numeric) the number of blocks processed`
`"timeoffset": n, (numeric) the time offset`
`"connections": n, (numeric) the number of connected peers`
`"proxy": "host:port", (string) the proxy used by the server`
`"difficulty": n.nn, (numeric) the current target difficulty`
`"testnet": true or false, (boolean) whether or not server is using testnet`
`"relayfee": n.nn, (numeric) the minimum relay fee for non-free transactions in BTC/KB`
`}`|
|Example Return|`{`
`"version": 70000`
`"protocolversion": 70001, `
`"blocks": 298963,`
`"timeoffset": 0,`
`"connections": 17,`
`"proxy": "",`
`"difficulty": 8000872135.97,`
`"testnet": false,`
`"relayfee": 0.00001,`
`}`|
[Return to Overview](#MethodOverview)
@@ -434,7 +434,7 @@ Example Return|`{`
`"bytes": 310768,`
`"size":
|Description|Returns information about a transaction given its hash.|
|Returns (verbose=0)|`"data" (string) hex-encoded bytes of the serialized transaction`|
|Returns (verbose=1)|`{ (json object)`
`"hex": "data", (string) hex-encoded transaction`
`"txid": "hash", (string) the hash of the transaction`
`"version": n, (numeric) the transaction version`
`"locktime": n, (numeric) the transaction lock time`
`"vin": [ (array of json objects) the transaction inputs as json objects`
For coinbase transactions:
`{ (json object)`
`"coinbase": "data", (string) the hex-encoded bytes of the signature script`
`"sequence": n, (numeric) the script sequence number`
`}`
For non-coinbase transactions:
`{ (json object)`
`"txid": "hash", (string) the hash of the origin transaction`
`"vout": n, (numeric) the index of the output being redeemed from the origin transaction`
`"scriptSig": { (json object) the signature script used to redeem the origin transaction`
`"asm": "asm", (string) disassembly of the script`
`"hex": "data", (string) hex-encoded bytes of the script`
`}`
`"sequence": n, (numeric) the script sequence number`
`}, ...`
`]`
`"vout": [ (array of json objects) the transaction outputs as json objects`
`{ (json object)`
`"value": n, (numeric) the value in BTC`
`"n": n, (numeric) the index of this transaction output`
`"scriptPubKey": { (json object) the public key script used to pay coins`
`"asm": "asm", (string) disassembly of the script`
`"hex": "data", (string) hex-encoded bytes of the script`
`"reqSigs": n, (numeric) the number of required signatures`
`"type": "scripttype" (string) the type of the script (e.g. 'pubkeyhash')`
`"addresses": [ (json array of string) the bitcoin addresses associated with this output`
`"bitcoinaddress", (string) the bitcoin address`
`...`
`]`
`}`
`}, ...`
`]`
`}`|
-|Example Return (verbose=0)|`"010000000104be666c7053ef26c6110597dad1c1e81b5e6be53d17a8b9d0b34772054bac60000000`
`008c493046022100cb42f8df44eca83dd0a727988dcde9384953e830b1f8004d57485e2ede1b9c8f`
`022100fbce8d84fcf2839127605818ac6c3e7a1531ebc69277c504599289fb1e9058df0141045a33`
`76eeb85e494330b03c1791619d53327441002832f4bd618fd9efa9e644d242d5e1145cb9c2f71965`
`656e276633d4ff1a6db5e7153a0a9042745178ebe0f5ffffffff0280841e00000000001976a91406`
`f1b6703d3f56427bfcfd372f952d50d04b64bd88ac4dd52700000000001976a9146b63f291c295ee`
`abd9aee6be193ab2d019e7ea7088ac00000000`
**Newlines added for display purposes. The actual return does not contain newlines.**|
+|Example Return (verbose=0)|`"010000000104be666c7053ef26c6110597dad1c1e81b5e6be53d17a8b9d0b34772054bac60000000`
`008c493046022100cb42f8df44eca83dd0a727988dcde9384953e830b1f8004d57485e2ede1b9c8f`
`022100fbce8d84fcf2839127605818ac6c3e7a1531ebc69277c504599289fb1e9058df0141045a33`
`76eeb85e494330b03c1791619d53327441002832f4bd618fd9efa9e644d242d5e1145cb9c2f71965`
`656e276633d4ff1a6db5e7153a0a9042745178ebe0f5ffffffff0280841e00000000001976a91406`
`f1b6703d3f56427bfcfd372f952d50d04b64bd88ac4dd52700000000001976a9146b63f291c295ee`
`abd9aee6be193ab2d019e7ea7088ac00000000`
**Newlines added for display purposes. The actual return does not contain newlines.**|
|Example Return (verbose=1)|`{`
`"hex": "01000000010000000000000000000000000000000000000000000000000000000000000000f...",`
`"txid": "90743aad855880e517270550d2a881627d84db5265142fd1e7fb7add38b08be9",`
`"version": 1,`
`"locktime": 0,`
`"vin": [`
For coinbase transactions:
`{ (json object)`
`"coinbase": "03708203062f503253482f04066d605108f800080100000ea2122f6f7a636f696e4065757374726174756d2f",`
`"sequence": 0,`
`}`
For non-coinbase transactions:
`{`
`"txid": "60ac4b057247b3d0b9a8173de56b5e1be8c1d1da970511c626ef53706c66be04",`
`"vout": 0,`
`"scriptSig": {`
`"asm": "3046022100cb42f8df44eca83dd0a727988dcde9384953e830b1f8004d57485e2ede1b9c8f0...",`
`"hex": "493046022100cb42f8df44eca83dd0a727988dcde9384953e830b1f8004d57485e2ede1b9c8...",`
`}`
`"sequence": 4294967295,`
`}`
`]`
`"vout": [`
`{`
`"value": 25.1394,`
`"n": 0,`
`"scriptPubKey": {`
`"asm": "OP_DUP OP_HASH160 ea132286328cfc819457b9dec386c4b5c84faa5c OP_EQUALVERIFY OP_CHECKSIG",`
`"hex": "76a914ea132286328cfc819457b9dec386c4b5c84faa5c88ac",`
`"reqSigs": 1,`
`"type": "pubkeyhash"`
`"addresses": [`
`"1NLg3QJMsMQGM5KEUaEu5ADDmKQSLHwmyh",`
`]`
`}`
`}`
`]`
`}`|
[Return to Overview](#MethodOverview)
@@ -541,8 +541,8 @@ Example Return|`{`
`"bytes": 310768,`
`"size":
|---|---|
|Method|verifychain|
|Parameters|1. checklevel (numeric, optional, default=3) - how in-depth the verification is (0=least amount of checks, higher levels are clamped to the highest supported level)
2. numblocks (numeric, optional, default=288) - the number of blocks starting from the end of the chain to verify|
-|Description|Verifies the block chain database.
The actual checks performed by the `checklevel` parameter is implementation specific. For btcd this is:
`checklevel=0` - Look up each block and ensure it can be loaded from the database.
`checklevel=1` - Perform basic context-free sanity checks on each block.|
-|Notes|Btcd currently only supports `checklevel` 0 and 1, but the default is still 3 for compatibility. Per the information in the Parameters section above, higher levels are automatically clamped to the highest supported level, so this means the default is effectively 1 for btcd.|
+|Description|Verifies the block chain database.
The actual checks performed by the `checklevel` parameter is implementation specific. For btcd this is:
`checklevel=0` - Look up each block and ensure it can be loaded from the database.
`checklevel=1` - Perform basic context-free sanity checks on each block.|
+|Notes|Btcd currently only supports `checklevel` 0 and 1, but the default is still 3 for compatibility. Per the information in the Parameters section above, higher levels are automatically clamped to the highest supported level, so this means the default is effectively 1 for btcd.|
|Returns|`true` or `false` (boolean)|
|Example Return|`true`|
[Return to Overview](#MethodOverview)
@@ -684,8 +684,8 @@ The following is an overview of the RPC methods which are implemented by btcd, b
**7.1 Method Overview**
-The following is an overview of the RPC method requests available exclusively to Websocket clients. All of these RPC methods are available to the limited
-user. Click the method name for further details such as parameter and return information.
+The following is an overview of the RPC method requests available exclusively to Websocket clients. All of these RPC methods are available to the limited
+user. Click the method name for further details such as parameter and return information.
|#|Method|Description|Notifications|
|---|------|-----------|-------------|
@@ -726,7 +726,7 @@ user. Click the method name for further details such as parameter and return in
|Method|notifyblocks|
|Notifications|[blockconnected](#blockconnected), [blockdisconnected](#blockdisconnected), [filteredblockconnected](#filteredblockconnected), and [filteredblockdisconnected](#filteredblockdisconnected)|
|Parameters|None|
-|Description|Request notifications for whenever a block is connected or disconnected from the main (best) chain.
NOTE: If a client subscribes to both block and transaction (recvtx and redeemingtx) notifications, the blockconnected notification will be sent after all transaction notifications have been sent. This allows clients to know when all relevant transactions for a block have been received.|
+|Description|Request notifications for whenever a block is connected or disconnected from the main (best) chain.
NOTE: If a client subscribes to both block and transaction (recvtx and redeemingtx) notifications, the blockconnected notification will be sent after all transaction notifications have been sent. This allows clients to know when all relevant transactions for a block have been received.|
|Returns|Nothing|
[Return to Overview](#WSExtMethodOverview)
@@ -752,7 +752,7 @@ user. Click the method name for further details such as parameter and return in
|Method|notifyreceived|
|Notifications|[recvtx](#recvtx) and [redeemingtx](#redeemingtx)|
|Parameters|1. Addresses (JSON array, required)
`[ (json array of strings)`
`"bitcoinaddress", (string) the bitcoin address`
`...`
`]`|
-|Description|*DEPRECATED, for similar functionality see [loadtxfilter](#loadtxfilter)*
Send a recvtx notification when a transaction added to mempool or appears in a newly-attached block contains a txout pkScript sending to any of the passed addresses. Matching outpoints are automatically registered for redeemingtx notifications.|
+|Description|*DEPRECATED, for similar functionality see [loadtxfilter](#loadtxfilter)*
Send a recvtx notification when a transaction added to mempool or appears in a newly-attached block contains a txout pkScript sending to any of the passed addresses. Matching outpoints are automatically registered for redeemingtx notifications.|
|Returns|Nothing|
[Return to Overview](#WSExtMethodOverview)
@@ -804,7 +804,7 @@ user. Click the method name for further details such as parameter and return in
|Method|rescan|
|Notifications|[recvtx](#recvtx), [redeemingtx](#redeemingtx), [rescanprogress](#rescanprogress), and [rescanfinished](#rescanfinished)|
|Parameters|1. BeginBlock (string, required) block hash to begin rescanning from
2. Addresses (JSON array, required)
`[ (json array of strings)`
`"bitcoinaddress", (string) the bitcoin address`
`...`
`]`
3. Outpoints (JSON array, required)
`[ (JSON array)`
`{ (JSON object)`
`"hash":"data", (string) the hex-encoded bytes of the outpoint hash`
`"index":n (numeric) the txout index of the outpoint`
`},`
`...`
`]`
4. EndBlock (string, optional) hash of final block to rescan|
-|Description|*DEPRECATED, for similar functionality see [rescanblocks](#rescanblocks)*
Rescan block chain for transactions to addresses, starting at block BeginBlock and ending at EndBlock. The current known UTXO set for all passed addresses at height BeginBlock should included in the Outpoints argument. If EndBlock is omitted, the rescan continues through the best block in the main chain. Additionally, if no EndBlock is provided, the client is automatically registered for transaction notifications for all rescanned addresses and the final UTXO set. Rescan results are sent as recvtx and redeemingtx notifications. This call returns once the rescan completes.|
+|Description|*DEPRECATED, for similar functionality see [rescanblocks](#rescanblocks)*
Rescan block chain for transactions to addresses, starting at block BeginBlock and ending at EndBlock. The current known UTXO set for all passed addresses at height BeginBlock should included in the Outpoints argument. If EndBlock is omitted, the rescan continues through the best block in the main chain. Additionally, if no EndBlock is provided, the client is automatically registered for transaction notifications for all rescanned addresses and the final UTXO set. Rescan results are sent as recvtx and redeemingtx notifications. This call returns once the rescan completes.|
|Returns|Nothing|
[Return to Overview](#WSExtMethodOverview)
@@ -816,7 +816,7 @@ user. Click the method name for further details such as parameter and return in
|---|---|
|Method|notifynewtransactions|
|Notifications|[txaccepted](#txaccepted) or [txacceptedverbose](#txacceptedverbose)|
-|Parameters|1. verbose (boolean, optional, default=false) - specifies which type of notification to receive. If verbose is true, then the caller receives [txacceptedverbose](#txacceptedverbose), otherwise the caller receives [txaccepted](#txaccepted)|
+|Parameters|1. verbose (boolean, optional, default=false) - specifies which type of notification to receive. If verbose is true, then the caller receives [txacceptedverbose](#txacceptedverbose), otherwise the caller receives [txaccepted](#txaccepted)|
|Description|Send either a [txaccepted](#txaccepted) or a [txacceptedverbose](#txacceptedverbose) notification when a new transaction is accepted into the mempool.|
|Returns|Nothing|
[Return to Overview](#WSExtMethodOverview)
@@ -843,7 +843,7 @@ user. Click the method name for further details such as parameter and return in
|Method|session|
|Notifications|None|
|Parameters|None|
-|Description|Return a JSON object with details regarding a websocket client's current connection to the RPC server. This currently only includes the session ID, a random unsigned 64-bit integer that is created for each newly connected client. Session IDs may be used to verify that the current connection was not lost and subsequently reestablished.|
+|Description|Return a JSON object with details regarding a websocket client's current connection to the RPC server. This currently only includes the session ID, a random unsigned 64-bit integer that is created for each newly connected client. Session IDs may be used to verify that the current connection was not lost and subsequently reestablished.|
|Returns|`{ (json object)`
`"sessionid": n (numeric) the session ID`
`}`|
|Example Return|`{`
`"sessionid": 67089679842`
`}`|
[Return to Overview](#WSExtMethodOverview)
@@ -869,7 +869,7 @@ user. Click the method name for further details such as parameter and return in
|---|---|
|Method|rescanblocks|
|Notifications|None|
-|Parameters|1. Blockhashes (JSON array, required) - List of hashes to rescan. Each next block must be a child of the previous.|
+|Parameters|1. Blockhashes (JSON array, required) - List of hashes to rescan. Each next block must be a child of the previous.|
|Description|Rescan blocks for transactions matching the loaded transaction filter.|
|Returns|`[ (JSON array)`
`{ (JSON object)`
`"hash": "data", (string) Hash of the matching block.`
`"transactions": [ (JSON array) List of matching transactions, serialized and hex-encoded.`
`"serializedtx" (string) Serialized and hex-encoded transaction.`
`]`
`}`
`]`|
|Example Return|`[`
`{`
`"hash": "0000002099417930b2ae09feda10e38b58c0f6bb44b4d60fa33f0e000000000000000000d53...",`
`"transactions": [`
`"493046022100cb42f8df44eca83dd0a727988dcde9384953e830b1f8004d57485e2ede1b9c8..."`
`]`
`}`
`]`|
@@ -879,13 +879,13 @@ user. Click the method name for further details such as parameter and return in
### 8. Notifications (Websocket-specific)
-btcd uses standard JSON-RPC notifications to notify clients of changes, rather than requiring clients to poll btcd for updates. JSON-RPC notifications are a subset of requests, but do not contain an ID. The notification type is categorized by the `method` field and additional details are sent as a JSON array in the `params` field.
+btcd uses standard JSON-RPC notifications to notify clients of changes, rather than requiring clients to poll btcd for updates. JSON-RPC notifications are a subset of requests, but do not contain an ID. The notification type is categorized by the `method` field and additional details are sent as a JSON array in the `params` field.
**8.1 Notification Overview**
-The following is an overview of the JSON-RPC notifications used for Websocket connections. Click the method name for further details of the context(s) in which they are sent and their parameters.
+The following is an overview of the JSON-RPC notifications used for Websocket connections. Click the method name for further details of the context(s) in which they are sent and their parameters.
|#|Method|Description|Request|
|---|------|-----------|-------|
@@ -912,7 +912,7 @@ The following is an overview of the JSON-RPC notifications used for Websocket co
|Method|blockconnected|
|Request|[notifyblocks](#notifyblocks)|
|Parameters|1. BlockHash (string) hex-encoded bytes of the attached block hash
2. BlockHeight (numeric) height of the attached block
3. BlockTime (numeric) unix time of the attached block|
-|Description|*DEPRECATED, for similar functionality see [filteredblockconnected](#filteredblockconnected)*
Notifies when a block has been added to the main chain. Notification is sent to all connected clients.|
+|Description|*DEPRECATED, for similar functionality see [filteredblockconnected](#filteredblockconnected)*
Notifies when a block has been added to the main chain. Notification is sent to all connected clients.|
|Example|Example blockconnected notification for mainnet block 280330 (newlines added for readability):
`{`
`"jsonrpc": "1.0",`
`"method": "blockconnected",`
`"params":`
`[`
`"000000000000000004cbdfe387f4df44b914e464ca79838a8ab777b3214dbffd",`
`280330,`
`1389636265`
`],`
`"id": null`
`}`|
[Return to Overview](#NotificationOverview)
@@ -925,7 +925,7 @@ The following is an overview of the JSON-RPC notifications used for Websocket co
|Method|blockdisconnected|
|Request|[notifyblocks](#notifyblocks)|
|Parameters|1. BlockHash (string) hex-encoded bytes of the disconnected block hash
2. BlockHeight (numeric) height of the disconnected block
3. BlockTime (numeric) unix time of the disconnected block|
-|Description|*DEPRECATED, for similar functionality see [filteredblockdisconnected](#filteredblockdisconnected)*
Notifies when a block has been removed from the main chain. Notification is sent to all connected clients.|
+|Description|*DEPRECATED, for similar functionality see [filteredblockdisconnected](#filteredblockdisconnected)*
Notifies when a block has been removed from the main chain. Notification is sent to all connected clients.|
|Example|Example blockdisconnected notification for mainnet block 280330 (newlines added for readability):
`{`
`"jsonrpc": "1.0",`
`"method": "blockdisconnected",`
`"params":`
`[`
`"000000000000000004cbdfe387f4df44b914e464ca79838a8ab777b3214dbffd",`
`280330,`
`1389636265`
`],`
`"id": null`
`}`|
[Return to Overview](#NotificationOverview)
@@ -938,7 +938,7 @@ The following is an overview of the JSON-RPC notifications used for Websocket co
|Method|recvtx|
|Request|[rescan](#rescan) or [notifyreceived](#notifyreceived)|
|Parameters|1. Transaction (string) full transaction encoded as a hex string
2. Block details (object, optional) details about a block and the index of the transaction within a block, if the transaction is mined|
-|Description|*DEPRECATED, for similar functionality see [relevanttxaccepted](#relevanttxaccepted) and [filteredblockconnected](#filteredblockconnected)*
Notifies a client when a transaction is processed that contains at least a single output with a pkScript sending to a requested address. If multiple outputs send to requested addresses, a single notification is sent. If a mempool (unmined) transaction is processed, the block details object (second parameter) is excluded.|
+|Description|*DEPRECATED, for similar functionality see [relevanttxaccepted](#relevanttxaccepted) and [filteredblockconnected](#filteredblockconnected)*
Notifies a client when a transaction is processed that contains at least a single output with a pkScript sending to a requested address. If multiple outputs send to requested addresses, a single notification is sent. If a mempool (unmined) transaction is processed, the block details object (second parameter) is excluded.|
|Example|Example recvtx notification for mainnet transaction 61d3696de4c888730cbe06b0ad8ecb6d72d6108e893895aa9bc067bd7eba3fad when processed by mempool (newlines added for readability):
`{`
`"jsonrpc": "1.0",`
`"method": "recvtx",`
`"params":`
`[`
`"010000000114d9ff358894c486b4ae11c2a8cf7851b1df64c53d2e511278eff17c22fb737300000000..."`
`],`
`"id": null`
`}`
The recvtx notification for the same txout, after the transaction was mined into block 276425:
`{`
`"jsonrpc": "1.0",`
`"method": "recvtx",`
`"params":`
`[`
`"010000000114d9ff358894c486b4ae11c2a8cf7851b1df64c53d2e511278eff17c22fb737300000000...",`
`{`
`"height": 276425,`
`"hash": "000000000000000325474bb799b9e591f965ca4461b72cb7012b808db92bb2fc",`
`"index": 684,`
`"time": 1387737310`
`}`
`],`
`"id": null`
`}`|
[Return to Overview](#NotificationOverview)
@@ -1028,7 +1028,7 @@ The following is an overview of the JSON-RPC notifications used for Websocket co
|Method|filteredblockconnected|
|Request|[notifyblocks](#notifyblocks), [loadtxfilter](#loadtxfilter)|
|Parameters|1. BlockHeight (numeric) height of the attached block
2. Header (string) hex-encoded serialized header of the attached block
3. Transactions (JSON array) hex-encoded serialized transactions matching the filter for the client connection loaded with [loadtxfilter](#loadtxfilter)|
-|Description|Notifies when a block has been added to the main chain. Notification is sent to all connected clients.|
+|Description|Notifies when a block has been added to the main chain. Notification is sent to all connected clients.|
|Example|Example filteredblockconnected notification for mainnet block 280330 (newlines added for readability):
`{`
`"jsonrpc": "1.0",`
`"method": "filteredblockconnected",`
`"params":`
`[`
`280330,`
`"0200000052d1e8813f697293e41942aa230e7e4fcc44832d78a1372202000000000000006aa...",`
`[`
`"01000000014221abdcca25c8a3b0c044034875dece048c77d567a806f0c2e7e0f5e25a8f100..."`
`]`
`],`
`"id": null`
`}`|
[Return to Overview](#NotificationOverview)
@@ -1041,7 +1041,7 @@ The following is an overview of the JSON-RPC notifications used for Websocket co
|Method|filteredblockdisconnected|
|Request|[notifyblocks](#notifyblocks), [loadtxfilter](#loadtxfilter)|
|Parameters|1. BlockHeight (numeric) height of the disconnected block
2. Header (string) hex-encoded serialized header of the disconnected block|
-|Description|Notifies when a block has been removed from the main chain. Notification is sent to all connected clients.|
+|Description|Notifies when a block has been removed from the main chain. Notification is sent to all connected clients.|
|Example|Example blockdisconnected notification for mainnet block 280330 (newlines added for readability):
`{`
`"jsonrpc": "1.0",`
`"method": "blockdisconnected",`
`"params":`
`[`
`280330,`
`"0200000052d1e8813f697293e41942aa230e7e4fcc44832d78a1372202000000000000006aa..."`
`],`
`"id": null`
`}`|
[Return to Overview](#NotificationOverview)
@@ -1098,7 +1098,7 @@ func main() {
log.Fatal(err)
}
- // Create a new RPC client using websockets. Since this example is
+ // Create a new RPC client using websockets. Since this example is
// not long-lived, the connection will be closed as soon as the program
// exits.
connCfg := &btcrpcclient.ConnConfig{
@@ -1162,7 +1162,7 @@ func main() {
log.Fatal(err)
}
- // Create a new RPC client using websockets. Since this example is
+ // Create a new RPC client using websockets. Since this example is
// not long-lived, the connection will be closed as soon as the program
// exits.
connCfg := &btcrpcclient.ConnConfig{
@@ -1227,7 +1227,7 @@ The following is an example Go application which uses the
[btcrpcclient](https://github.com/btcsuite/btcrpcclient) package to connect with
a btcd instance via Websockets and registers for
[blockconnected](#blockconnected) and [blockdisconnected](#blockdisconnected)
-notifications with [notifyblocks](#notifyblocks). It also sets up handlers for
+notifications with [notifyblocks](#notifyblocks). It also sets up handlers for
the notifications.
```Go
@@ -1335,7 +1335,7 @@ var user = "yourusername";
var password = "yourpassword";
-// Initiate the websocket connection. The btcd generated certificate acts as
+// Initiate the websocket connection. The btcd generated certificate acts as
// its own certificate authority, so it needs to be specified in the 'ca' array
// for the certificate to properly validate.
var ws = new WebSocket('wss://127.0.0.1:8334/ws', {
diff --git a/docs/using_bootstrap_dat.md b/docs/using_bootstrap_dat.md
index de7e08c0c..1582c34d1 100644
--- a/docs/using_bootstrap_dat.md
+++ b/docs/using_bootstrap_dat.md
@@ -16,7 +16,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. Btcd will download the
block chain from other peers through the Bitcoin protocol with no extra
configuration needed.
@@ -41,7 +41,7 @@ Cons:
### 3. Where do I get bootstrap.dat?
-The bootstrap.dat file is made available via a torrent. See
+The bootstrap.dat file is made available via a torrent. See
[this](https://bitcointalk.org/index.php?topic=145386.0) thread on bitcointalk
for the torrent download details.
@@ -51,8 +51,8 @@ for the torrent download details.
You don't need to trust the file as the `addblock` utility verifies every block
using the same rules that are used when downloading the block chain normally
-through the Bitcoin protocol. Additionally, the chain rules contain hard-coded
-checkpoints for the known-good block chain at periodic intervals. This ensures
+through the Bitcoin protocol. Additionally, the chain rules contain hard-coded
+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.
@@ -61,10 +61,10 @@ is using.
### 5. How do I use bootstrap.dat with btcd?
btcd 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
+`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 btcd if it is already running. This is required since addblock needs to
access the database used by btcd and it will be locked if btcd is using it.
2. Note the path to the downloaded bootstrap.dat file.
3. Run the addblock utility with the `-i` argument pointing to the location of
diff --git a/ecc/README.md b/ecc/README.md
index e47be85dc..fe3cbbaa4 100644
--- a/ecc/README.md
+++ b/ecc/README.md
@@ -1,68 +1,24 @@
-btcec
+ecc
=====
-[](https://travis-ci.org/btcsuite/btcec)
[](http://copyfree.org)
-[](http://godoc.org/github.com/kaspanet/kaspad/btcec)
+[](http://godoc.org/github.com/kaspanet/kaspad/ecc)
-Package btcec implements elliptic curve cryptography needed for working with
-Bitcoin (secp256k1 only for now). It is designed so that it may be used with the
-standard crypto/ecdsa packages provided with go. A comprehensive suite of test
-is provided to ensure proper functionality. Package btcec was originally based
-on work from ThePiachu which is licensed under the same terms as Go, but it has
-signficantly diverged since then. The btcsuite developers original is licensed
-under the liberal ISC license.
-
-Although this package was primarily written for btcd, it has intentionally been
-designed so it can be used as a standalone package for any projects needing to
-use secp256k1 elliptic curve cryptography.
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/btcec
-```
+Package ecc implements elliptic curve cryptography needed for working with
+Kaspa. It is designed so that it may be used with the standard crypto/ecdsa
+packages provided with go. A comprehensive suite of tests is provided to ensure
+proper functionality. Package ecc was originally based on work from ThePiachu
+which is licensed under the same terms as Go, but it has signficantly diverged
+since then. The kaspanet developers original is licensed under the liberal ISC
+license.
## Examples
-* [Sign Message](http://godoc.org/github.com/kaspanet/kaspad/btcec#example-package--SignMessage)
+* [Sign Message](http://godoc.org/github.com/kaspanet/kaspad/ecc#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](http://godoc.org/github.com/kaspanet/kaspad/btcec#example-package--VerifySignature)
+* [Verify Signature](http://godoc.org/github.com/kaspanet/kaspad/ecc#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](http://godoc.org/github.com/kaspanet/kaspad/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](http://godoc.org/github.com/kaspanet/kaspad/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.
+ first parsed from raw bytes. The signature is also parsed from raw bytes.
diff --git a/integration/README.md b/integration/README.md
index 36f34b738..6b62fa3ac 100644
--- a/integration/README.md
+++ b/integration/README.md
@@ -1,13 +1,10 @@
integration
===========
-[](https://travis-ci.org/btcsuite/btcd)
+[](https://travis-ci.org/kaspanet/kaspad)
[](http://copyfree.org)
This contains integration tests which make use of the
[rpctest](https://github.com/kaspanet/kaspad/tree/master/integration/rpctest)
package to programmatically drive nodes via RPC.
-## License
-
-This code is licensed under the [copyfree](http://copyfree.org) ISC License.
diff --git a/integration/rpctest/README.md b/integration/rpctest/README.md
index 781c69937..822ab64c1 100644
--- a/integration/rpctest/README.md
+++ b/integration/rpctest/README.md
@@ -1,30 +1,13 @@
rpctest
=======
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/integration/rpctest)
-Package rpctest provides a btcd-specific RPC testing harness crafting and
-executing integration tests by driving a `btcd` instance via the `RPC`
+Package rpctest provides a kaspad-specific RPC testing harness crafting and
+executing integration tests by driving a `kaspad` instance via the `RPC`
interface. Each instance of an active harness comes equipped with a simple
-in-memory HD wallet capable of properly syncing to the generated chain,
+in-memory HD wallet capable of properly syncing to the generated DAG,
creating new addresses, and crafting fully signed transactions paying to an
arbitrary set of outputs.
-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/kaspanet/kaspad/integration/rpctest
-```
-
-## License
-
-Package rpctest is licensed under the [copyfree](http://copyfree.org) ISC
-License.
-
diff --git a/logger/logger.go b/logger/logger.go
index 302333f67..0f5350b09 100644
--- a/logger/logger.go
+++ b/logger/logger.go
@@ -7,11 +7,12 @@ package logger
import (
"fmt"
- "github.com/pkg/errors"
"os"
"sort"
"strings"
+ "github.com/pkg/errors"
+
"github.com/kaspanet/kaspad/logs"
)
diff --git a/logs/README.md b/logs/README.md
deleted file mode 100644
index 3219060e6..000000000
--- a/logs/README.md
+++ /dev/null
@@ -1,40 +0,0 @@
-btclog
-======
-
-[](https://travis-ci.org/btcsuite/btclog)
-[](http://copyfree.org)
-[](http://godoc.org/github.com/btcsuite/btclog)
-
-Package btclog defines a logger interface and provides a default implementation
-of a subsystem-aware leveled logger implementing the same interface.
-
-## Installation
-
-```bash
-$ go get github.com/btcsuite/btclog
-```
-
-## 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 btclog is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/mempool/README.md b/mempool/README.md
index 9692dc0ef..12c7af03f 100644
--- a/mempool/README.md
+++ b/mempool/README.md
@@ -1,14 +1,13 @@
mempool
=======
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/mempool)
-Package mempool provides a policy-enforced pool of unmined bitcoin transactions.
+Package mempool provides a policy-enforced pool of unmined kaspa transactions.
-A key responsbility of the bitcoin network is mining user-generated transactions
-into blocks. In order to facilitate this, the mining process relies on having a
+A key responsbility of the kaspa network is mining user-generated transactions
+into blocks. In order to facilitate this, the mining process relies on having a
readily-available source of transactions to include in a block that is being
solved.
@@ -17,19 +16,19 @@ in-memory pool of fully validated transactions that can also optionally be
further filtered based upon a configurable policy.
One of the policy configuration options controls whether or not "standard"
-transactions are accepted. In essence, a "standard" transaction is one that
+transactions are accepted. In essence, a "standard" transaction is one that
satisfies a fairly strict set of requirements that are largely intended to help
-provide fair use of the system to all users. It is important to note that what
-is considered a "standard" transaction changes over time. For some insight, at
+provide fair use of the system to all users. It is important to note that what
+is considered a "standard" transaction changes over time. For some insight, at
the time of this writing, an example of _some_ of the criteria that are required
for a transaction to be considered standard are that it is of the most-recently
supported version, finalized, does not exceed a specific size, and only consists
of specific script forms.
-Since this package does not deal with other bitcoin specifics such as network
+Since this package does not deal with other kaspa specifics such as network
communication and transaction relay, it returns a list of transactions that were
accepted which gives the caller a high level of flexibility in how they want to
-proceed. Typically, this will involve things such as relaying the transactions
+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.
@@ -40,13 +39,13 @@ configurable policy.
## Feature Overview
-The following is a quick overview of the major features. It is not intended to
+The following is a quick overview of the major features. It is not intended to
be an exhaustive list.
- Maintain a pool of fully validated transactions
- Reject non-fully-spent duplicate transactions
- Reject coinbase transactions
- - Reject double spends (both from the chain and other transactions in pool)
+ - Reject double spends (both from the DAG and other transactions in pool)
- Reject invalid transactions according to the network consensus rules
- Full script execution and validation with signature cache support
- Individual transaction query support
@@ -71,13 +70,3 @@ be an exhaustive list.
- Manual control of transaction removal
- Recursive removal of all dependent transactions
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/mempool
-```
-
-## License
-
-Package mempool is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/mempool/mempool_test.go b/mempool/mempool_test.go
index 00cb9d395..515dfce34 100644
--- a/mempool/mempool_test.go
+++ b/mempool/mempool_test.go
@@ -7,7 +7,6 @@ package mempool
import (
"bytes"
"fmt"
- "github.com/pkg/errors"
"math"
"reflect"
"runtime"
@@ -15,6 +14,8 @@ import (
"testing"
"time"
+ "github.com/pkg/errors"
+
"github.com/kaspanet/kaspad/util/subnetworkid"
"github.com/kaspanet/kaspad/util/testtools"
diff --git a/mining/README.md b/mining/README.md
deleted file mode 100644
index 01f81752e..000000000
--- a/mining/README.md
+++ /dev/null
@@ -1,21 +0,0 @@
-mining
-======
-
-[](https://travis-ci.org/btcsuite/btcd)
-[](http://copyfree.org)
-[](http://godoc.org/github.com/kaspanet/kaspad/mining)
-
-## Overview
-
-This package is currently a work in progress.
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/mining
-```
-
-## License
-
-Package mining is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/mining/cpuminer/README.md b/mining/cpuminer/README.md
deleted file mode 100644
index 589924c25..000000000
--- a/mining/cpuminer/README.md
+++ /dev/null
@@ -1,25 +0,0 @@
-cpuminer
-========
-
-[](https://travis-ci.org/btcsuite/btcd)
-[](http://copyfree.org)
-[](http://godoc.org/github.com/kaspanet/kaspad/mining/cpuminer)
-=======
-
-## Overview
-
-This package is currently a work in progress. It works without issue since it
-is used in several of the integration tests, but the API is not really ready for
-public consumption as it has simply been refactored out of the main codebase for
-now.
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/mining/cpuminer
-```
-
-## License
-
-Package cpuminer is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/netsync/README.md b/netsync/README.md
index 9be1798ce..21eb24286 100644
--- a/netsync/README.md
+++ b/netsync/README.md
@@ -1,7 +1,6 @@
netsync
=======
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/netsync)
@@ -10,16 +9,7 @@ netsync
This package implements a concurrency safe block syncing protocol. The
SyncManager communicates with connected peers to perform an initial block
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
+new blocks connected to the DAG. 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.
+the peer's selected tip.
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/netsync
-```
-
-## License
-
-Package netsync is licensed under the [copyfree](http://copyfree.org) ISC License.
diff --git a/peer/README.md b/peer/README.md
index 74082c61e..b4864509c 100644
--- a/peer/README.md
+++ b/peer/README.md
@@ -1,29 +1,23 @@
peer
====
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/peer)
-Package peer provides a common base for creating and managing bitcoin network
+Package peer provides a common base for creating and managing kaspa 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
-primitives necessary to speak the bitcoin wire protocol, in order to simplify
-the process of creating fully functional peers. In essence, it provides a
-common base for creating concurrent safe fully validating nodes, Simplified
-Payment Verification (SPV) nodes, proxies, etc.
+primitives necessary to speak the kaspa wire protocol, in order to simplify
+the process of creating fully functional peers.
A quick overview of the major features peer provides are as follows:
- - Provides a basic concurrent safe bitcoin peer for handling bitcoin
+ - Provides a basic concurrent safe kaspa peer for handling kaspa
communications via the peer-to-peer protocol
- - Full duplex reading and writing of bitcoin protocol messages
+ - Full duplex reading and writing of kaspa protocol messages
- Automatic handling of the initial handshake process including protocol
version negotiation
- Asynchronous message queueing of outbound messages with optional channel for
@@ -33,10 +27,8 @@ A quick overview of the major features peer provides are as follows:
incoming connections so they have flexibility to establish connections as
they see fit (proxies, etc)
- User agent name and version
- - Bitcoin network
- - Service support signalling (full nodes, bloom filters, etc)
- Maximum supported protocol version
- - Ability to register callbacks for handling bitcoin protocol messages
+ - Ability to register callbacks for handling kaspa protocol messages
- Inventory message batching and send trickling with known inventory detection
and avoidance
- Automatic periodic keep-alive pinging and pong responses
@@ -55,19 +47,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/kaspanet/kaspad/peer
-```
-
-## Examples
-
-* [New Outbound Peer Example](https://godoc.org/github.com/kaspanet/kaspad/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.
diff --git a/rpcclient/README.md b/rpcclient/README.md
index 0c28659a9..c2dcd5a42 100644
--- a/rpcclient/README.md
+++ b/rpcclient/README.md
@@ -1,41 +1,35 @@
rpcclient
=========
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/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
-Bitcoin JSON-RPC API.
+rpcclient implements a Websocket-enabled Kaspa JSON-RPC client package written
+in [Go](http://golang.org/). It provides a robust and easy to use client for
+interfacing with a Kaspa RPC server that uses a kaspad compatible
+Kaspa JSON-RPC API.
## Status
-This package is currently under active development. It is already stable and
-the infrastructure is complete. However, there are still several RPCs left to
+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](http://godoc.org/github.com/kaspanet/kaspad/rpcclient)
-* [btcd Websockets Example](https://github.com/kaspanet/kaspad/rpcclient/blob/master/examples/btcdwebsockets)
- Connects to a btcd RPC server using TLS-secured websockets, registers for
+* [Websockets Example](https://github.com/kaspanet/kaspad/blob/master/rpcclient/examples/websockets)
+ Connects to a kaspad 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/kaspanet/kaspad/rpcclient/blob/master/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/kaspanet/kaspad/rpcclient/blob/master/examples/bitcoincorehttp)
- Connects to a bitcoin core RPC server using HTTP POST mode with TLS disabled
+* [HTTP POST Example](https://github.com/kaspanet/kaspad/rpcclient/blob/master/examples/httppost)
+ Connects to a kaspad RPC server using HTTP POST mode with TLS disabled
and gets the current block count
## Major Features
-* Supports Websockets (btcd/btcwallet) and HTTP POST mode (bitcoin core)
-* Provides callback and registration functions for btcd/btcwallet notifications
-* Supports btcd extensions
+* Supports Websockets and HTTP POST mode
+* Provides callback and registration functions for kaspad notifications
* 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 +38,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/kaspanet/kaspad/rpcclient
-```
-
-## License
-
-Package rpcclient is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/rpcclient/examples/httppost/README.md b/rpcclient/examples/httppost/README.md
index f04bf4c3f..87765a35e 100644
--- a/rpcclient/examples/httppost/README.md
+++ b/rpcclient/examples/httppost/README.md
@@ -1,19 +1,13 @@
-Bitcoin Core HTTP POST Example
+HTTP POST Example
==============================
-This example shows how to use the rpcclient package to connect to a Bitcoin
-Core RPC server using HTTP POST mode with TLS disabled and gets the current
+This example shows how to use the rpcclient package to connect to a Kaspa
+RPC server using HTTP POST mode with TLS disabled and gets the current
block count.
## Running the Example
-The first step is to use `go get` to download and install the rpcclient package:
-
-```bash
-$ go get github.com/kaspanet/kaspad/rpcclient
-```
-
-Next, modify the `main.go` source to specify the correct RPC username and
+Modify the `main.go` source to specify the correct RPC username and
password for the RPC server:
```Go
@@ -24,10 +18,7 @@ password for the RPC server:
Finally, navigate to the example's directory and run it with:
```bash
-$ cd $GOPATH/src/github.com/kaspanet/kaspad/rpcclient/examples/bitcoincorehttp
+$ cd $GOPATH/src/github.com/kaspanet/kaspad/rpcclient/examples/httppost
$ go run *.go
```
-## License
-
-This example is licensed under the [copyfree](http://copyfree.org) ISC License.
diff --git a/rpcclient/examples/websockets/README.md b/rpcclient/examples/websockets/README.md
index 2d61df1df..253463f95 100644
--- a/rpcclient/examples/websockets/README.md
+++ b/rpcclient/examples/websockets/README.md
@@ -1,22 +1,14 @@
-btcd Websockets Example
+Websockets Example
=======================
-This example shows how to use the rpcclient package to connect to a btcd RPC
+This example shows how to use the rpcclient package to connect to an RPC
server using TLS-secured websockets, register for block connected and block
disconnected notifications, and get the current block count.
This example also sets a timer to shutdown the client after 10 seconds to
demonstrate clean shutdown.
-## Running the Example
-
-The first step is to use `go get` to download and install the rpcclient package:
-
-```bash
-$ go get github.com/kaspanet/kaspad/rpcclient
-```
-
-Next, modify the `main.go` source to specify the correct RPC username and
+Modify the `main.go` source to specify the correct RPC username and
password for the RPC server:
```Go
@@ -27,10 +19,6 @@ password for the RPC server:
Finally, navigate to the example's directory and run it with:
```bash
-$ cd $GOPATH/src/github.com/kaspanet/kaspad/rpcclient/examples/btcdwebsockets
+$ cd $GOPATH/src/github.com/kaspanet/kaspad/rpcclient/examples/websockets
$ go run *.go
```
-
-## License
-
-This example is licensed under the [copyfree](http://copyfree.org) ISC License.
diff --git a/rpcmodel/README.md b/rpcmodel/README.md
index 16fea3d40..dec327733 100644
--- a/rpcmodel/README.md
+++ b/rpcmodel/README.md
@@ -1,70 +1,34 @@
-btcjson
+rpcmodel
=======
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
-[](http://godoc.org/github.com/kaspanet/kaspad/btcjson)
+[](http://godoc.org/github.com/kaspanet/kaspad/rpcmodel)
-Package btcjson implements concrete types for marshalling to and from the
-bitcoin JSON-RPC API. A comprehensive suite of tests is provided to ensure
+Package rpcmodel implements concrete types for marshalling to and from the
+kaspa 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
+package. Instead, RPC clients should use the rpcclient 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/kaspanet/kaspad/btcjson
-```
-
## Examples
-* [Marshal Command](http://godoc.org/github.com/kaspanet/kaspad/btcjson#example-MarshalCmd)
+* [Marshal Command](http://godoc.org/github.com/kaspanet/kaspad/rpcmodel#example-MarshalCmd)
Demonstrates how to create and marshal a command into a JSON-RPC request.
-* [Unmarshal Command](http://godoc.org/github.com/kaspanet/kaspad/btcjson#example-UnmarshalCmd)
+* [Unmarshal Command](http://godoc.org/github.com/kaspanet/kaspad/rpcmodel#example-UnmarshalCmd)
Demonstrates how to unmarshal a JSON-RPC request and then unmarshal the
concrete request into a concrete command.
-* [Marshal Response](http://godoc.org/github.com/kaspanet/kaspad/btcjson#example-MarshalResponse)
+* [Marshal Response](http://godoc.org/github.com/kaspanet/kaspad/rpcmodel#example-MarshalResponse)
Demonstrates how to marshal a JSON-RPC response.
-* [Unmarshal Response](http://godoc.org/github.com/kaspanet/kaspad/btcjson#example-package--UnmarshalResponse)
+* [Unmarshal Response](http://godoc.org/github.com/kaspanet/kaspad/rpcmodel#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.
diff --git a/sample-kaspad.conf b/sample-kaspad.conf
index a585b3a8d..2932dc3a4 100644
--- a/sample-kaspad.conf
+++ b/sample-kaspad.conf
@@ -4,13 +4,13 @@
; Data settings
; ------------------------------------------------------------------------------
-; The directory to store data such as the block chain and peer addresses. The
+; 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 ~/.kaspad/data on POSIX OSes, $LOCALAPPDATA/Kaspad/data on Windows,
; ~/Library/Application Support/Kaspad/data on Mac OS, and $home/kaspad/data on
-; Plan9. Environment variables are expanded so they may be used. NOTE: Windows
+; 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.
+; $VARIABLE here. Also, ~ is expanded to $LOCALAPPDATA on Windows.
; datadir=~/.kaspad/data
@@ -21,7 +21,7 @@
; Use testnet.
; testnet=1
-; Connect via a SOCKS5 proxy. NOTE: Specifying a proxy will disable listening
+; Connect via a SOCKS5 proxy. NOTE: Specifying a proxy will disable listening
; for incoming connections unless listen addresses are provided via the 'listen'
; option.
; proxy=127.0.0.1:9050
@@ -42,17 +42,17 @@
; onionpass=
; Enable Tor stream isolation by randomizing proxy user credentials resulting in
-; Tor creating a new circuit for each connection. This makes it more difficult
+; Tor creating a new circuit for each connection. This makes it more difficult
; to correlate connections.
; torisolation=1
; Use Universal Plug and Play (UPnP) to automatically open the listen port
-; and obtain the external IP address from supported devices. NOTE: This option
+; and obtain the external IP address from supported devices. NOTE: This option
; will have no effect if exernal IP addresses are specified.
; upnp=1
-; Specify the external IP addresses your node is listening on. One address per
-; line. kaspad will not contact 3rd-party sites to obtain external ip addresses.
+; Specify the external IP addresses your node is listening on. One address per
+; line. kaspad 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).
@@ -63,35 +63,35 @@
; Summary of 'addpeer' versus 'connect'.
;
; 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, kaspad will query DNS
+; specified. Both allow you to specify peers that you want to stay connected
+; with, but the behavior is slightly different. By default, kaspad 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.
;
; 'addpeer' does not prevent connections to other peers discovered from
; the peers you are connected to and also lets the remote peers know you are
-; available so they can notify other peers they can to connect to you. This
+; available so they can notify other peers they can to connect to you. This
; option might be useful if you are having problems finding a node for some
; reason (perhaps due to a firewall).
;
; 'connect', on the other hand, will ONLY connect to the specified peers and
-; no others. It also disables listening (unless you explicitly set listen
+; no others. It also disables listening (unless you explicitly set listen
; addresses via the 'listen' option) and DNS seeding, so you will not be
; advertised as an available peer to the peers you connect to and won't accept
-; connections from any other peers. So, the 'connect' option effectively allows
+; connections from any other peers. So, the 'connect' option effectively allows
; you to only connect to "trusted" peers.
; ******************************************************************************
-; Add persistent peers to connect to as desired. One peer per line.
-; You may specify each IP address with or without a port. The default port will
+; Add persistent peers to connect to as desired. One peer per line.
+; 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=fe80::1
; addpeer=[fe80::2]:8333
-; 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
+; 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
; default port will be added automatically if one is not specified here.
; NOTE: Specifying this option has other side effects as described above in
; the 'addpeer' versus 'connect' summary section.
@@ -121,11 +121,11 @@
; whitelist=192.168.0.0/24
; whitelist=fd00::/16
-; Disable DNS seeding for peers. By default, when kaspad starts, it will use
+; Disable DNS seeding for peers. By default, when kaspad starts, it will use
; DNS to query for available peers to connect with.
; nodnsseed=1
-; Specify the interfaces to listen on. One listen address per line.
+; Specify the interfaces to listen on. One listen address per line.
; NOTE: The default port is modified by some options such as 'testnet', so it is
; recommended to not specify a port and allow a proper default to be chosen
; unless you have a specific reason to do otherwise.
@@ -154,10 +154,10 @@
; All ipv6 interfaces on non-standard port 8336:
; listen=[::]:8336
-; Disable listening for incoming connections. This will override all listeners.
+; Disable listening for incoming connections. This will override all listeners.
; nolisten=1
-; Disable peer bloom filtering. See BIP0111.
+; Disable peer bloom filtering. See BIP0111.
; nopeerbloomfilters=1
; Add additional checkpoints. Format: ':'
@@ -175,8 +175,8 @@
; rpclimituser AND rpclimitpass, are not specified.
; ------------------------------------------------------------------------------
-; Secure the RPC API by specifying the username and password. You can also
-; specify a limited username and password. You must specify at least one
+; Secure the RPC API by specifying the username and password. You can also
+; specify a limited username and password. You must specify at least one
; full set of credentials - limited or admin - or the RPC server will
; be disabled.
; rpcuser=whatever_admin_username_you_want
@@ -184,10 +184,10 @@
; rpclimituser=whatever_limited_username_you_want
; rpclimitpass=
-; Specify the interfaces for the RPC server listen on. One listen address per
-; line. NOTE: The default port is modified by some options such as 'testnet',
+; Specify the interfaces for the RPC server listen on. One listen address per
+; line. NOTE: The default port is modified by some options such as 'testnet',
; so it is recommended to not specify a port and allow a proper default to be
-; chosen unless you have a specific reason to do otherwise. By default, the
+; chosen unless you have a specific reason to do otherwise. By default, the
; RPC server will only listen on localhost for IPv4 and IPv6.
; All interfaces on default port:
; rpclisten=
@@ -221,11 +221,11 @@
; rpcmaxwebsockets=25
; Use the following setting to disable the RPC server even if the rpcuser and
-; rpcpass are specified above. This allows one to quickly disable the RPC
+; rpcpass are specified above. This allows one to quickly disable the RPC
; server without having to remove credentials from the config file.
; norpc=1
-; Use the following setting to disable TLS for the RPC server. NOTE: This
+; Use the following setting to disable TLS for the RPC server. NOTE: This
; option only works if the RPC server is bound to localhost interfaces (which is
; the default).
; notls=1
@@ -296,27 +296,27 @@
; generate=false
; Add addresses to pay mined blocks to for CPU mining and potentially in the
-; block templates generated for the getblocktemplate RPC. One address per line.
+; block templates generated for the getblocktemplate RPC. One address per line.
; miningaddr=kaspa:yourkaspaaddress
; miningaddr=kaspa:yourkaspaaddress2
; miningaddr=kaspa:yourkaspaaddress3
-; Specify the minimum block size in bytes to create. By default, only
+; Specify the minimum block size in bytes to create. By default, only
; transactions which have enough fees or a high enough priority will be included
-; in generated block templates. Specifying a minimum block size will instead
+; in generated block templates. Specifying a minimum block size will instead
; attempt to fill generated block templates up with transactions until it is at
; least the specified number of bytes.
; blockminsize=0
-; Specify the maximum block size in bytes to create. This value will be limited
+; Specify the maximum block size in bytes to create. This value will be limited
; to the consensus limit if it is larger than that value.
; blockmaxsize=750000
; Specify the size in bytes of the high-priority/low-fee area when creating a
-; block. Transactions which consist of large amounts, old inputs, and small
-; sizes have the highest priority. One consequence of this is that as low-fee
+; block. Transactions which consist of large amounts, old inputs, and small
+; sizes have the highest priority. One consequence of this is that as low-fee
; or free transactions age, they raise in priority thereby making them more
-; likely to be included in this section of a new block. This value is limited
+; likely to be included in this section of a new block. This value is limited
; by the blackmaxsize option and will be limited as needed.
; blockprioritysize=50000
@@ -328,12 +328,12 @@
; Debug logging level.
; Valid levels are {trace, debug, info, warn, error, critical}
; You may also specify =,=,... to set
-; log level for individual subsystems. Use kaspad --debuglevel=show to list
+; log level for individual subsystems. Use kaspad --debuglevel=show to list
; available subsystems.
; debuglevel=info
-; The port used to listen for HTTP profile requests. The profile server will
-; be disabled if this option is not specified. The profile information can be
+; The port used to listen for HTTP profile requests. The profile server will
+; be disabled if this option is not specified. The profile information can be
; accessed at http://localhost:/debug/pprof once running.
; profile=6061
diff --git a/telegram.sh b/telegram.sh
index 30684dfd0..ca43185e7 100755
--- a/telegram.sh
+++ b/telegram.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-# This file is part of Continuous Integration. When ran by
+# This file is part of Continuous Integration. When ran by
# the CI agent, it sends a some details about the build failure
# to a Telegram group.
diff --git a/txscript/README.md b/txscript/README.md
index a1209bd1a..16f51aa13 100644
--- a/txscript/README.md
+++ b/txscript/README.md
@@ -1,63 +1,24 @@
txscript
========
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/txscript)
-Package txscript implements the bitcoin transaction script language. There is
+Package txscript implements the kaspa transaction script language. There is
a comprehensive test suite.
-This package has intentionally been designed so it can be used as a standalone
-package for any projects needing to use or validate bitcoin transaction scripts.
+## Kaspa Scripts
-## Bitcoin Scripts
-
-Bitcoin provides a stack-based, FORTH-like language for the scripts in
-the bitcoin transactions. This language is not turing complete
-although it is still fairly powerful. A description of the language
-can be found at https://en.bitcoin.it/wiki/Script
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/txscript
-```
+Kaspa provides a stack-based, FORTH-like language for the scripts in
+the kaspa transactions. This language is not turing complete
+although it is still fairly powerful.
## Examples
* [Standard Pay-to-pubkey-hash Script](http://godoc.org/github.com/kaspanet/kaspad/txscript#example-PayToAddrScript)
- Demonstrates creating a script which pays to a bitcoin address. It also
+ Demonstrates creating a script which pays to a kaspa address. It also
prints the created script hex and uses the DisasmString function to display
the disassembled script.
* [Extracting Details from Standard Scripts](http://godoc.org/github.com/kaspanet/kaspad/txscript#example-ExtractPkScriptAddrs)
Demonstrates extracting information from a standard public key script.
-
-* [Manually Signing a Transaction Output](http://godoc.org/github.com/kaspanet/kaspad/txscript#example-SignTxOutput)
- Demonstrates manually creating and signing a redeem transaction.
-
-## 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.
diff --git a/txscript/data/LICENSE b/txscript/data/LICENSE
index 30d808c58..9cb24e231 100644
--- a/txscript/data/LICENSE
+++ b/txscript/data/LICENSE
@@ -1,4 +1,4 @@
-The json files in this directory come from the bitcoind project
+The json files in this directory originate from the bitcoind project
(https://github.com/bitcoin/bitcoin) and is released under the following
license:
diff --git a/util/README.md b/util/README.md
index b5165ba21..cbc833843 100644
--- a/util/README.md
+++ b/util/README.md
@@ -1,50 +1,7 @@
-btcutil
+util
=======
-[](https://travis-ci.org/btcsuite/btcutil)
-[](https://coveralls.io/r/btcsuite/btcutil?branch=master)
[](http://copyfree.org)
-[](http://godoc.org/github.com/daglabs/btcutil)
+[](http://godoc.org/github.com/kaspanet/util)
-Package btcutil provides bitcoin-specific convenience functions and types.
-A comprehensive suite of tests is provided to ensure proper functionality. 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.
-
-This package was developed for btcd, an alternative full-node implementation of
-bitcoin which is under active development by Conformal. Although it was
-primarily written for btcd, this package has intentionally been designed so it
-can be used as a standalone package for any projects needing the functionality
-provided.
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/daglabs/btcutil
-```
-
-## 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 btcutil is licensed under the [copyfree](http://copyfree.org) ISC
-License.
+Package util provides kaspa-specific convenience functions and types.
diff --git a/util/base58/README.md b/util/base58/README.md
index cb52c1fb4..68d9b6b02 100644
--- a/util/base58/README.md
+++ b/util/base58/README.md
@@ -1,34 +1,23 @@
base58
==========
-[](https://travis-ci.org/btcsuite/btcutil)
[](http://copyfree.org)
-[](http://godoc.org/github.com/daglabs/btcutil/base58)
+[](http://godoc.org/github.com/kaspanet/kaspad/util/base58)
Package base58 provides an API for encoding and decoding to and from the
-modified base58 encoding. It also provides an API to do Base58Check encoding,
-as described [here](https://en.bitcoin.it/wiki/Base58Check_encoding).
+modified base58 encoding.
A comprehensive suite of tests is provided to ensure proper functionality.
-## Installation and Updating
-
-```bash
-$ go get -u github.com/daglabs/btcutil/base58
-```
## Examples
-* [Decode Example](http://godoc.org/github.com/daglabs/btcutil/base58#example-Decode)
+* [Decode Example](http://godoc.org/github.com/kaspanet/kaspad/util/base58#example-Decode)
Demonstrates how to decode modified base58 encoded data.
-* [Encode Example](http://godoc.org/github.com/daglabs/btcutil/base58#example-Encode)
+* [Encode Example](http://godoc.org/github.com/kaspanet/kaspad/util/base58#example-Encode)
Demonstrates how to encode data using the modified base58 encoding scheme.
-* [CheckDecode Example](http://godoc.org/github.com/daglabs/btcutil/base58#example-CheckDecode)
+* [CheckDecode Example](http://godoc.org/github.com/kaspanet/kaspad/util/base58#example-CheckDecode)
Demonstrates how to decode Base58Check encoded data.
-* [CheckEncode Example](http://godoc.org/github.com/daglabs/btcutil/base58#example-CheckEncode)
+* [CheckEncode Example](http://godoc.org/github.com/kaspanet/kaspad/util/base58#example-CheckEncode)
Demonstrates how to encode data using the Base58Check encoding scheme.
-## License
-
-Package base58 is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/util/bech32/README.md b/util/bech32/README.md
index 4112b60fc..04c577617 100644
--- a/util/bech32/README.md
+++ b/util/bech32/README.md
@@ -1,29 +1,15 @@
-bech32dag
+bech32
==========
-[](https://travis-ci.org/btcsuite/btcutil)
[](http://copyfree.org)
-[](http://godoc.org/github.com/daglabs/btcutil/bech32)
+[](http://godoc.org/github.com/kaspanet/kaspad/util/bech32)
-Package bech32 provides a Go implementation of the bech32 format specified in
-[the spec](https://github.com/daglabs/spec/blob/master/dagcoin.pdf).
-
-Test vectors from the spec are added to ensure compatibility with the BIP.
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/daglabs/btcutil/bech32dag
-```
+Package bech32 provides a Go implementation of the bech32 format.
## Examples
-* [Bech32 decode Example](http://godoc.org/github.com/daglabs/btcutil/bech32dag#example-Bech32Decode)
+* [Bech32 decode Example](http://godoc.org/github.com/kaspanet/kaspad/util/bech32#example-Bech32Decode)
Demonstrates how to decode a bech32 encoded string.
-* [Bech32 encode Example](http://godoc.org/github.com/daglabs/btcutil/bech32dag#example-BechEncode)
+* [Bech32 encode Example](http://godoc.org/github.com/kaspanet/kaspad/util/bech32#example-BechEncode)
Demonstrates how to encode data into a bech32 string.
-## License
-
-Package bech32 is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/util/bloom/README.md b/util/bloom/README.md
index 14565c8f0..0736ce354 100644
--- a/util/bloom/README.md
+++ b/util/bloom/README.md
@@ -1,30 +1,15 @@
bloom
=====
-[](https://travis-ci.org/btcsuite/btcutil)
[](http://copyfree.org)
-[](http://godoc.org/github.com/daglabs/btcutil/bloom)
+[](http://godoc.org/github.com/kaspanet/kaspad/util/bloom)
-Package bloom provides an API for dealing with bitcoin-specific bloom filters.
+Package bloom provides an API for dealing with kaspa-specific bloom filters.
-A comprehensive suite of tests is provided to ensure proper functionality. 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.
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/daglabs/btcutil/bloom
-```
## Examples
-* [NewFilter Example](http://godoc.org/github.com/daglabs/btcutil/bloom#example-NewFilter)
+* [NewFilter Example](http://godoc.org/github.com/kaspanet/kaspad/util/bloom#example-NewFilter)
Demonstrates how to create a new bloom filter, add a transaction hash to it,
and check if the filter matches the transaction.
-## License
-
-Package bloom is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/util/coinset/README.md b/util/coinset/README.md
deleted file mode 100644
index 594a5ee85..000000000
--- a/util/coinset/README.md
+++ /dev/null
@@ -1,71 +0,0 @@
-coinset
-=======
-
-[](https://travis-ci.org/btcsuite/btcutil)
-[](http://copyfree.org)
-[](http://godoc.org/github.com/daglabs/btcutil/coinset)
-
-Package coinset provides bitcoin-specific convenience functions for selecting
-from and managing sets of unspent transaction outpoints (UTXOs).
-
-A comprehensive suite of tests is provided to ensure proper functionality. 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.
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/daglabs/btcutil/coinset
-```
-
-## Usage
-
-Each unspent transaction outpoint is represented by the Coin interface. An
-example of a concrete type that implements Coin is coinset.SimpleCoin.
-
-The typical use case for this library is for creating raw bitcoin transactions
-given a set of Coins that may be spent by the user, for example as below:
-
-```Go
-var unspentCoins = []coinset.Coin{ ... }
-```
-
-When the user needs to spend a certain amount, they will need to select a
-subset of these coins which contain at least that value. CoinSelector is
-an interface that represents types that implement coin selection algos,
-subject to various criteria. There are a few examples of CoinSelector's:
-
-- MinIndexCoinSelector
-
-- MinNumberCoinSelector
-
-- MaxValueAgeCoinSelector
-
-- MinPriorityCoinSelector
-
-For example, if the user wishes to maximize the probability that their
-transaction is mined quickly, they could use the MaxValueAgeCoinSelector to
-select high priority coins, then also attach a relatively high fee.
-
-```Go
-selector := &coinset.MaxValueAgeCoinSelector{
- MaxInputs: 10,
- MinAmountChange: 10000,
-}
-selectedCoins, err := selector.CoinSelect(targetAmount + bigFee, unspentCoins)
-if err != nil {
- return err
-}
-msgTx := coinset.NewMsgTxWithInputCoins(selectedCoins)
-...
-
-```
-
-The user can then create the msgTx.TxOut's as required, then sign the
-transaction and transmit it to the network.
-
-## License
-
-Package coinset is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/util/coinset/coins.go b/util/coinset/coins.go
deleted file mode 100644
index 085cb81ba..000000000
--- a/util/coinset/coins.go
+++ /dev/null
@@ -1,402 +0,0 @@
-// Copyright (c) 2014-2017 The btcsuite developers
-// Use of this source code is governed by an ISC
-// license that can be found in the LICENSE file.
-
-package coinset
-
-import (
- "container/list"
- "github.com/pkg/errors"
- "sort"
-
- "github.com/kaspanet/kaspad/util"
- "github.com/kaspanet/kaspad/util/daghash"
- "github.com/kaspanet/kaspad/wire"
-)
-
-// Coin represents a spendable transaction outpoint
-type Coin interface {
- Hash() *daghash.Hash
- ID() *daghash.TxID
- Index() uint32
- Value() util.Amount
- ScriptPubKey() []byte
- NumConfs() int64
- ValueAge() int64
-}
-
-// Coins represents a set of Coins
-type Coins interface {
- Coins() []Coin
-}
-
-// CoinSet is a utility struct for the modifications of a set of
-// Coins that implements the Coins interface. To create a CoinSet,
-// you must call NewCoinSet with nil for an empty set or a slice of
-// coins as the initial contents.
-//
-// It is important to note that the all the Coins being added or removed
-// from a CoinSet must have a constant ValueAge() during the use of
-// the CoinSet, otherwise the cached values will be incorrect.
-type CoinSet struct {
- coinList *list.List
- totalValue util.Amount
- totalValueAge int64
-}
-
-// Ensure that CoinSet is a Coins
-var _ Coins = NewCoinSet(nil)
-
-// NewCoinSet creates a CoinSet containing the coins provided.
-// To create an empty CoinSet, you may pass null as the coins input parameter.
-func NewCoinSet(coins []Coin) *CoinSet {
- newCoinSet := &CoinSet{
- coinList: list.New(),
- totalValue: 0,
- totalValueAge: 0,
- }
- for _, coin := range coins {
- newCoinSet.PushCoin(coin)
- }
- return newCoinSet
-}
-
-// Coins returns a new slice of the coins contained in the set.
-func (cs *CoinSet) Coins() []Coin {
- coins := make([]Coin, cs.coinList.Len())
- for i, e := 0, cs.coinList.Front(); e != nil; i, e = i+1, e.Next() {
- coins[i] = e.Value.(Coin)
- }
- return coins
-}
-
-// TotalValue returns the total value of the coins in the set.
-func (cs *CoinSet) TotalValue() (value util.Amount) {
- return cs.totalValue
-}
-
-// TotalValueAge returns the total value * number of confirmations
-// of the coins in the set.
-func (cs *CoinSet) TotalValueAge() (valueAge int64) {
- return cs.totalValueAge
-}
-
-// Num returns the number of coins in the set
-func (cs *CoinSet) Num() int {
- return cs.coinList.Len()
-}
-
-// PushCoin adds a coin to the end of the list and updates
-// the cached value amounts.
-func (cs *CoinSet) PushCoin(c Coin) {
- cs.coinList.PushBack(c)
- cs.totalValue += c.Value()
- cs.totalValueAge += c.ValueAge()
-}
-
-// PopCoin removes the last coin on the list and returns it.
-func (cs *CoinSet) PopCoin() Coin {
- back := cs.coinList.Back()
- if back == nil {
- return nil
- }
- return cs.removeElement(back)
-}
-
-// ShiftCoin removes the first coin on the list and returns it.
-func (cs *CoinSet) ShiftCoin() Coin {
- front := cs.coinList.Front()
- if front == nil {
- return nil
- }
- return cs.removeElement(front)
-}
-
-// removeElement updates the cached value amounts in the CoinSet,
-// removes the element from the list, then returns the Coin that
-// was removed to the caller.
-func (cs *CoinSet) removeElement(e *list.Element) Coin {
- c := e.Value.(Coin)
- cs.coinList.Remove(e)
- cs.totalValue -= c.Value()
- cs.totalValueAge -= c.ValueAge()
- return c
-}
-
-// NewMsgTxWithInputCoins takes the coins in the CoinSet and makes them
-// the inputs to a new wire.MsgTx which is returned.
-func NewMsgTxWithInputCoins(txVersion int32, inputCoins Coins) *wire.MsgTx {
- coins := inputCoins.Coins()
- txIn := make([]*wire.TxIn, len(coins))
- for i, coin := range coins {
- txIn[i] = &wire.TxIn{
- PreviousOutpoint: wire.Outpoint{
- TxID: *coin.ID(),
- Index: coin.Index(),
- },
- SignatureScript: nil,
- Sequence: wire.MaxTxInSequenceNum,
- }
- }
- msgTx := wire.NewNativeMsgTx(txVersion, txIn, nil)
- return msgTx
-}
-
-var (
- // ErrCoinsNoSelectionAvailable is returned when a CoinSelector believes there is no
- // possible combination of coins which can meet the requirements provided to the selector.
- ErrCoinsNoSelectionAvailable = errors.New("no coin selection possible")
-)
-
-// satisfiesTargetValue checks that the totalValue is either exactly the targetValue
-// or is greater than the targetValue by at least the minChange amount.
-func satisfiesTargetValue(targetValue, minChange, totalValue util.Amount) bool {
- return (totalValue == targetValue || totalValue >= targetValue+minChange)
-}
-
-// CoinSelector is an interface that wraps the CoinSelect method.
-//
-// CoinSelect will attempt to select a subset of the coins which has at
-// least the targetValue amount. CoinSelect is not guaranteed to return a
-// selection of coins even if the total value of coins given is greater
-// than the target value.
-//
-// The exact choice of coins in the subset will be implementation specific.
-//
-// It is important to note that the Coins being used as inputs need to have
-// a constant ValueAge() during the execution of CoinSelect.
-type CoinSelector interface {
- CoinSelect(targetValue util.Amount, coins []Coin) (Coins, error)
-}
-
-// MinIndexCoinSelector is a CoinSelector that attempts to construct a
-// selection of coins whose total value is at least targetValue and prefers
-// any number of lower indexes (as in the ordered array) over higher ones.
-type MinIndexCoinSelector struct {
- MaxInputs int
- MinChangeAmount util.Amount
-}
-
-// CoinSelect will attempt to select coins using the algorithm described
-// in the MinIndexCoinSelector struct.
-func (s MinIndexCoinSelector) CoinSelect(targetValue util.Amount, coins []Coin) (Coins, error) {
- cs := NewCoinSet(nil)
- for n := 0; n < len(coins) && n < s.MaxInputs; n++ {
- cs.PushCoin(coins[n])
- if satisfiesTargetValue(targetValue, s.MinChangeAmount, cs.TotalValue()) {
- return cs, nil
- }
- }
- return nil, ErrCoinsNoSelectionAvailable
-}
-
-// MinNumberCoinSelector is a CoinSelector that attempts to construct
-// a selection of coins whose total value is at least targetValue
-// that uses as few of the inputs as possible.
-type MinNumberCoinSelector struct {
- MaxInputs int
- MinChangeAmount util.Amount
-}
-
-// CoinSelect will attempt to select coins using the algorithm described
-// in the MinNumberCoinSelector struct.
-func (s MinNumberCoinSelector) CoinSelect(targetValue util.Amount, coins []Coin) (Coins, error) {
- sortedCoins := make([]Coin, 0, len(coins))
- sortedCoins = append(sortedCoins, coins...)
- sort.Sort(sort.Reverse(byAmount(sortedCoins)))
-
- return MinIndexCoinSelector(s).CoinSelect(targetValue, sortedCoins)
-}
-
-// MaxValueAgeCoinSelector is a CoinSelector that attempts to construct
-// a selection of coins whose total value is at least targetValue
-// that has as much input value-age as possible.
-//
-// This would be useful in the case where you want to maximize
-// likelihood of the inclusion of your transaction in the next mined
-// block.
-type MaxValueAgeCoinSelector struct {
- MaxInputs int
- MinChangeAmount util.Amount
-}
-
-// CoinSelect will attempt to select coins using the algorithm described
-// in the MaxValueAgeCoinSelector struct.
-func (s MaxValueAgeCoinSelector) CoinSelect(targetValue util.Amount, coins []Coin) (Coins, error) {
- sortedCoins := make([]Coin, 0, len(coins))
- sortedCoins = append(sortedCoins, coins...)
- sort.Sort(sort.Reverse(byValueAge(sortedCoins)))
-
- return MinIndexCoinSelector(s).CoinSelect(targetValue, sortedCoins)
-}
-
-// MinPriorityCoinSelector is a CoinSelector that attempts to construct
-// a selection of coins whose total value is at least targetValue and
-// whose average value-age per input is greater than MinAvgValueAgePerInput.
-// If there is change, it must exceed MinChangeAmount to be a valid selection.
-//
-// When possible, MinPriorityCoinSelector will attempt to reduce the average
-// input priority over the threshold, but no guarantees will be made as to
-// minimality of the selection. The selection below is almost certainly
-// suboptimal.
-//
-type MinPriorityCoinSelector struct {
- MaxInputs int
- MinChangeAmount util.Amount
- MinAvgValueAgePerInput int64
-}
-
-// CoinSelect will attempt to select coins using the algorithm described
-// in the MinPriorityCoinSelector struct.
-func (s MinPriorityCoinSelector) CoinSelect(targetValue util.Amount, coins []Coin) (Coins, error) {
- possibleCoins := make([]Coin, 0, len(coins))
- possibleCoins = append(possibleCoins, coins...)
-
- sort.Sort(byValueAge(possibleCoins))
-
- // find the first coin with sufficient valueAge
- cutoffIndex := -1
- for i := 0; i < len(possibleCoins); i++ {
- if possibleCoins[i].ValueAge() >= s.MinAvgValueAgePerInput {
- cutoffIndex = i
- break
- }
- }
- if cutoffIndex < 0 {
- return nil, ErrCoinsNoSelectionAvailable
- }
-
- // create sets of input coins that will obey minimum average valueAge
- for i := cutoffIndex; i < len(possibleCoins); i++ {
- possibleHighCoins := possibleCoins[cutoffIndex : i+1]
-
- // choose a set of high-enough valueAge coins
- highSelect, err := (&MinNumberCoinSelector{
- MaxInputs: s.MaxInputs,
- MinChangeAmount: s.MinChangeAmount,
- }).CoinSelect(targetValue, possibleHighCoins)
-
- if err != nil {
- // attempt to add available low priority to make a solution
-
- for numLow := 1; numLow <= cutoffIndex && numLow+(i-cutoffIndex) <= s.MaxInputs; numLow++ {
- allHigh := NewCoinSet(possibleCoins[cutoffIndex : i+1])
- newTargetValue := targetValue - allHigh.TotalValue()
- newMaxInputs := allHigh.Num() + numLow
- if newMaxInputs > numLow {
- newMaxInputs = numLow
- }
- newMinAvgValueAge := ((s.MinAvgValueAgePerInput * int64(allHigh.Num()+numLow)) - allHigh.TotalValueAge()) / int64(numLow)
-
- // find the minimum priority that can be added to set
- lowSelect, err := (&MinPriorityCoinSelector{
- MaxInputs: newMaxInputs,
- MinChangeAmount: s.MinChangeAmount,
- MinAvgValueAgePerInput: newMinAvgValueAge,
- }).CoinSelect(newTargetValue, possibleCoins[0:cutoffIndex])
-
- if err != nil {
- continue
- }
-
- for _, coin := range lowSelect.Coins() {
- allHigh.PushCoin(coin)
- }
-
- return allHigh, nil
- }
- // oh well, couldn't fix, try to add more high priority to the set.
- } else {
- extendedCoins := NewCoinSet(highSelect.Coins())
-
- // attempt to lower priority towards target with lowest ones first
- for n := 0; n < cutoffIndex; n++ {
- if extendedCoins.Num() >= s.MaxInputs {
- break
- }
- if possibleCoins[n].ValueAge() == 0 {
- continue
- }
-
- extendedCoins.PushCoin(possibleCoins[n])
- if extendedCoins.TotalValueAge()/int64(extendedCoins.Num()) < s.MinAvgValueAgePerInput {
- extendedCoins.PopCoin()
- continue
- }
- }
- return extendedCoins, nil
- }
- }
-
- return nil, ErrCoinsNoSelectionAvailable
-}
-
-type byValueAge []Coin
-
-func (a byValueAge) Len() int { return len(a) }
-func (a byValueAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
-func (a byValueAge) Less(i, j int) bool { return a[i].ValueAge() < a[j].ValueAge() }
-
-type byAmount []Coin
-
-func (a byAmount) Len() int { return len(a) }
-func (a byAmount) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
-func (a byAmount) Less(i, j int) bool { return a[i].Value() < a[j].Value() }
-
-// SimpleCoin defines a concrete instance of Coin that is backed by a
-// util.Tx, a specific outpoint index, and the number of confirmations
-// that transaction has had.
-type SimpleCoin struct {
- Tx *util.Tx
- TxIndex uint32
- TxNumConfs int64
-}
-
-// Ensure that SimpleCoin is a Coin
-var _ Coin = &SimpleCoin{}
-
-// Hash returns the hash value of the transaction on which the Coin is an output
-func (c *SimpleCoin) Hash() *daghash.Hash {
- return c.Tx.Hash()
-}
-
-// ID returns the ID of the transaction on which the Coin is an output
-func (c *SimpleCoin) ID() *daghash.TxID {
- return c.Tx.ID()
-}
-
-// Index returns the index of the output on the transaction which the Coin represents
-func (c *SimpleCoin) Index() uint32 {
- return c.TxIndex
-}
-
-// txOut returns the TxOut of the transaction the Coin represents
-func (c *SimpleCoin) txOut() *wire.TxOut {
- return c.Tx.MsgTx().TxOut[c.TxIndex]
-}
-
-// Value returns the value of the Coin
-func (c *SimpleCoin) Value() util.Amount {
- return util.Amount(c.txOut().Value)
-}
-
-// ScriptPubKey returns the outpoint script of the Coin.
-//
-// This can be used to determine what type of script the Coin uses
-// and extract standard addresses if possible using
-// txscript.ExtractScriptPubKeyAddrs for example.
-func (c *SimpleCoin) ScriptPubKey() []byte {
- return c.txOut().ScriptPubKey
-}
-
-// NumConfs returns the number of confirmations that the transaction the Coin references
-// has had.
-func (c *SimpleCoin) NumConfs() int64 {
- return c.TxNumConfs
-}
-
-// ValueAge returns the product of the value and the number of confirmations. This is
-// used as an input to calculate the priority of the transaction.
-func (c *SimpleCoin) ValueAge() int64 {
- return c.TxNumConfs * int64(c.Value())
-}
diff --git a/util/coinset/coins_test.go b/util/coinset/coins_test.go
deleted file mode 100644
index 490508093..000000000
--- a/util/coinset/coins_test.go
+++ /dev/null
@@ -1,275 +0,0 @@
-// Copyright (c) 2014-2016 The btcsuite developers
-// Use of this source code is governed by an ISC
-// license that can be found in the LICENSE file.
-
-package coinset_test
-
-import (
- "bytes"
- "crypto/sha256"
- "encoding/hex"
- "fmt"
- "testing"
-
- "github.com/kaspanet/kaspad/util"
- "github.com/kaspanet/kaspad/util/coinset"
- "github.com/kaspanet/kaspad/util/daghash"
- "github.com/kaspanet/kaspad/wire"
-)
-
-type TestCoin struct {
- TxHash *daghash.Hash
- TxID *daghash.TxID
- TxIndex uint32
- TxValue util.Amount
- TxNumConfs int64
-}
-
-func (c *TestCoin) Hash() *daghash.Hash { return c.TxHash }
-func (c *TestCoin) ID() *daghash.TxID { return c.TxID }
-func (c *TestCoin) Index() uint32 { return c.TxIndex }
-func (c *TestCoin) Value() util.Amount { return c.TxValue }
-func (c *TestCoin) ScriptPubKey() []byte { return nil }
-func (c *TestCoin) NumConfs() int64 { return c.TxNumConfs }
-func (c *TestCoin) ValueAge() int64 { return int64(c.TxValue) * c.TxNumConfs }
-
-func NewCoin(index int64, value util.Amount, numConfs int64) coinset.Coin {
- h := sha256.New()
- h.Write([]byte(fmt.Sprintf("%d", index)))
- hash, _ := daghash.NewHash(h.Sum(nil))
- id, _ := daghash.NewTxID(h.Sum(nil))
- c := &TestCoin{
- TxHash: hash,
- TxID: id,
- TxIndex: 0,
- TxValue: value,
- TxNumConfs: numConfs,
- }
- return coinset.Coin(c)
-}
-
-type coinSelectTest struct {
- selector coinset.CoinSelector
- inputCoins []coinset.Coin
- targetValue util.Amount
- expectedCoins []coinset.Coin
- expectedError error
-}
-
-func testCoinSelector(tests []coinSelectTest, t *testing.T) {
- for testIndex, test := range tests {
- cs, err := test.selector.CoinSelect(test.targetValue, test.inputCoins)
- if err != test.expectedError {
- t.Errorf("[%d] expected a different error: got=%v, expected=%v", testIndex, err, test.expectedError)
- continue
- }
- if test.expectedCoins != nil {
- if cs == nil {
- t.Errorf("[%d] expected non-nil coinset", testIndex)
- continue
- }
- coins := cs.Coins()
- if len(coins) != len(test.expectedCoins) {
- t.Errorf("[%d] expected different number of coins: got=%d, expected=%d", testIndex, len(coins), len(test.expectedCoins))
- continue
- }
- for n := 0; n < len(test.expectedCoins); n++ {
- if coins[n] != test.expectedCoins[n] {
- t.Errorf("[%d] expected different coins at coin index %d: got=%#v, expected=%#v", testIndex, n, coins[n], test.expectedCoins[n])
- continue
- }
- }
- coinSet := coinset.NewCoinSet(coins)
- if coinSet.TotalValue() < test.targetValue {
- t.Errorf("[%d] targetValue not satistifed", testIndex)
- continue
- }
- }
- }
-}
-
-var coins = []coinset.Coin{
- NewCoin(1, 100000000, 1),
- NewCoin(2, 10000000, 20),
- NewCoin(3, 50000000, 0),
- NewCoin(4, 25000000, 6),
-}
-
-func TestCoinSet(t *testing.T) {
- cs := coinset.NewCoinSet(nil)
- if cs.PopCoin() != nil {
- t.Error("Expected popCoin of empty to be nil")
- }
- if cs.ShiftCoin() != nil {
- t.Error("Expected shiftCoin of empty to be nil")
- }
-
- cs.PushCoin(coins[0])
- cs.PushCoin(coins[1])
- cs.PushCoin(coins[2])
- if cs.PopCoin() != coins[2] {
- t.Error("Expected third coin")
- }
- if cs.ShiftCoin() != coins[0] {
- t.Error("Expected first coin")
- }
-
- mtx := coinset.NewMsgTxWithInputCoins(wire.TxVersion, cs)
- if len(mtx.TxIn) != 1 {
- t.Errorf("Expected only 1 TxIn, got %d", len(mtx.TxIn))
- }
- op := mtx.TxIn[0].PreviousOutpoint
- if !op.TxID.IsEqual(coins[1].ID()) || op.Index != coins[1].Index() {
- t.Errorf("Expected the second coin to be added as input to mtx")
- }
-}
-
-var minIndexSelectors = []coinset.MinIndexCoinSelector{
- {MaxInputs: 10, MinChangeAmount: 10000},
- {MaxInputs: 2, MinChangeAmount: 10000},
-}
-
-var minIndexTests = []coinSelectTest{
- {minIndexSelectors[0], coins, coins[0].Value() - minIndexSelectors[0].MinChangeAmount, []coinset.Coin{coins[0]}, nil},
- {minIndexSelectors[0], coins, coins[0].Value() - minIndexSelectors[0].MinChangeAmount + 1, []coinset.Coin{coins[0], coins[1]}, nil},
- {minIndexSelectors[0], coins, 100000000, []coinset.Coin{coins[0]}, nil},
- {minIndexSelectors[0], coins, 110000000, []coinset.Coin{coins[0], coins[1]}, nil},
- {minIndexSelectors[0], coins, 140000000, []coinset.Coin{coins[0], coins[1], coins[2]}, nil},
- {minIndexSelectors[0], coins, 200000000, nil, coinset.ErrCoinsNoSelectionAvailable},
- {minIndexSelectors[1], coins, 10000000, []coinset.Coin{coins[0]}, nil},
- {minIndexSelectors[1], coins, 110000000, []coinset.Coin{coins[0], coins[1]}, nil},
- {minIndexSelectors[1], coins, 140000000, nil, coinset.ErrCoinsNoSelectionAvailable},
-}
-
-func TestMinIndexSelector(t *testing.T) {
- testCoinSelector(minIndexTests, t)
-}
-
-var minNumberSelectors = []coinset.MinNumberCoinSelector{
- {MaxInputs: 10, MinChangeAmount: 10000},
- {MaxInputs: 2, MinChangeAmount: 10000},
-}
-
-var minNumberTests = []coinSelectTest{
- {minNumberSelectors[0], coins, coins[0].Value() - minNumberSelectors[0].MinChangeAmount, []coinset.Coin{coins[0]}, nil},
- {minNumberSelectors[0], coins, coins[0].Value() - minNumberSelectors[0].MinChangeAmount + 1, []coinset.Coin{coins[0], coins[2]}, nil},
- {minNumberSelectors[0], coins, 100000000, []coinset.Coin{coins[0]}, nil},
- {minNumberSelectors[0], coins, 110000000, []coinset.Coin{coins[0], coins[2]}, nil},
- {minNumberSelectors[0], coins, 160000000, []coinset.Coin{coins[0], coins[2], coins[3]}, nil},
- {minNumberSelectors[0], coins, 184990000, []coinset.Coin{coins[0], coins[2], coins[3], coins[1]}, nil},
- {minNumberSelectors[0], coins, 184990001, nil, coinset.ErrCoinsNoSelectionAvailable},
- {minNumberSelectors[0], coins, 200000000, nil, coinset.ErrCoinsNoSelectionAvailable},
- {minNumberSelectors[1], coins, 10000000, []coinset.Coin{coins[0]}, nil},
- {minNumberSelectors[1], coins, 110000000, []coinset.Coin{coins[0], coins[2]}, nil},
- {minNumberSelectors[1], coins, 140000000, []coinset.Coin{coins[0], coins[2]}, nil},
-}
-
-func TestMinNumberSelector(t *testing.T) {
- testCoinSelector(minNumberTests, t)
-}
-
-var maxValueAgeSelectors = []coinset.MaxValueAgeCoinSelector{
- {MaxInputs: 10, MinChangeAmount: 10000},
- {MaxInputs: 2, MinChangeAmount: 10000},
-}
-
-var maxValueAgeTests = []coinSelectTest{
- {maxValueAgeSelectors[0], coins, 100000, []coinset.Coin{coins[1]}, nil},
- {maxValueAgeSelectors[0], coins, 10000000, []coinset.Coin{coins[1]}, nil},
- {maxValueAgeSelectors[0], coins, 10000001, []coinset.Coin{coins[1], coins[3]}, nil},
- {maxValueAgeSelectors[0], coins, 35000000, []coinset.Coin{coins[1], coins[3]}, nil},
- {maxValueAgeSelectors[0], coins, 135000000, []coinset.Coin{coins[1], coins[3], coins[0]}, nil},
- {maxValueAgeSelectors[0], coins, 185000000, []coinset.Coin{coins[1], coins[3], coins[0], coins[2]}, nil},
- {maxValueAgeSelectors[0], coins, 200000000, nil, coinset.ErrCoinsNoSelectionAvailable},
- {maxValueAgeSelectors[1], coins, 40000000, nil, coinset.ErrCoinsNoSelectionAvailable},
- {maxValueAgeSelectors[1], coins, 35000000, []coinset.Coin{coins[1], coins[3]}, nil},
- {maxValueAgeSelectors[1], coins, 34990001, nil, coinset.ErrCoinsNoSelectionAvailable},
-}
-
-func TestMaxValueAgeSelector(t *testing.T) {
- testCoinSelector(maxValueAgeTests, t)
-}
-
-var minPrioritySelectors = []coinset.MinPriorityCoinSelector{
- {MaxInputs: 10, MinChangeAmount: 10000, MinAvgValueAgePerInput: 100000000},
- {MaxInputs: 02, MinChangeAmount: 10000, MinAvgValueAgePerInput: 200000000},
- {MaxInputs: 02, MinChangeAmount: 10000, MinAvgValueAgePerInput: 150000000},
- {MaxInputs: 03, MinChangeAmount: 10000, MinAvgValueAgePerInput: 150000000},
- {MaxInputs: 10, MinChangeAmount: 10000, MinAvgValueAgePerInput: 1000000000},
- {MaxInputs: 10, MinChangeAmount: 10000, MinAvgValueAgePerInput: 175000000},
- {MaxInputs: 02, MinChangeAmount: 10000, MinAvgValueAgePerInput: 125000000},
-}
-
-var connectedCoins = []coinset.Coin{coins[0], coins[1], coins[3]}
-
-var minPriorityTests = []coinSelectTest{
- {minPrioritySelectors[0], connectedCoins, 100000000, []coinset.Coin{coins[0]}, nil},
- {minPrioritySelectors[0], connectedCoins, 125000000, []coinset.Coin{coins[0], coins[3]}, nil},
- {minPrioritySelectors[0], connectedCoins, 135000000, []coinset.Coin{coins[0], coins[3], coins[1]}, nil},
- {minPrioritySelectors[0], connectedCoins, 140000000, nil, coinset.ErrCoinsNoSelectionAvailable},
- {minPrioritySelectors[1], connectedCoins, 100000000, nil, coinset.ErrCoinsNoSelectionAvailable},
- {minPrioritySelectors[1], connectedCoins, 10000000, []coinset.Coin{coins[1]}, nil},
- {minPrioritySelectors[1], connectedCoins, 100000000, nil, coinset.ErrCoinsNoSelectionAvailable},
- {minPrioritySelectors[2], connectedCoins, 11000000, []coinset.Coin{coins[3]}, nil},
- {minPrioritySelectors[2], connectedCoins, 25000001, []coinset.Coin{coins[3], coins[1]}, nil},
- {minPrioritySelectors[3], connectedCoins, 25000001, []coinset.Coin{coins[3], coins[1], coins[0]}, nil},
- {minPrioritySelectors[3], connectedCoins, 100000000, []coinset.Coin{coins[3], coins[1], coins[0]}, nil},
- {minPrioritySelectors[3], []coinset.Coin{coins[1], coins[2]}, 10000000, []coinset.Coin{coins[1]}, nil},
- {minPrioritySelectors[4], connectedCoins, 1, nil, coinset.ErrCoinsNoSelectionAvailable},
- {minPrioritySelectors[5], connectedCoins, 20000000, []coinset.Coin{coins[1], coins[3]}, nil},
- {minPrioritySelectors[6], connectedCoins, 25000000, []coinset.Coin{coins[3], coins[0]}, nil},
-}
-
-func TestMinPrioritySelector(t *testing.T) {
- testCoinSelector(minPriorityTests, t)
-}
-
-var (
- // should be two outpoints, with 1st one having 0.035KAS value.
- testSimpleCoinNumConfs = int64(1)
- testSimpleCoinTxHash = "c9e1a2b492e1d76872df50ddae62662f7d40f853b6d5aa85522ed915bbd96be7"
- testSimpleCoinTxHex = "0100000001A214A110F79E4ABE073865EA5B3745C6E82C91" +
- "3BAD44BE70652804A5E4003B0A010000008C493046022100" +
- "EDD18A69664EFA57264BE207100C203E6CADE1888CBB88A0" +
- "AD748548256BB2F0022100F1027DC2E6C7F248D78AF1DD90" +
- "027B5B7D8EC563BB62AA85D4E74D6376F3868C0141048F37" +
- "57B65ED301ABD1B0E8942D1AB5B50594D3314CFF0299F300" +
- "C696376A0A9BF72E74710A8AF7A5372D4AF4BB519E2701A0" +
- "94EF48C8E48E3B65B28502452DCEFFFFFFFFFFFFFFFF02E0" +
- "673500000000001976A914686DD149A79B4A559D561FBC39" +
- "6D3E3C6628B98D88ACE86EF102000000001976A914AC3F99" +
- "5655E81B875B38B64351D6F896DDBFC68588AC0000000000" +
- "000000000000000000000000000000000000000000000000"
- testSimpleCoinTxValue0 = util.Amount(3500000)
- testSimpleCoinTxValueAge0 = int64(testSimpleCoinTxValue0) * testSimpleCoinNumConfs
- testSimpleCoinTxScriptPubKey0Hex = "76a914686dd149a79b4a559d561fbc396d3e3c6628b98d88ac"
- testSimpleCoinTxScriptPubKey0Bytes, _ = hex.DecodeString(testSimpleCoinTxScriptPubKey0Hex)
- testSimpleCoinTxBytes, _ = hex.DecodeString(testSimpleCoinTxHex)
- testSimpleCoinTx, _ = util.NewTxFromBytes(testSimpleCoinTxBytes)
- testSimpleCoin = &coinset.SimpleCoin{
- Tx: testSimpleCoinTx,
- TxIndex: 0,
- TxNumConfs: testSimpleCoinNumConfs,
- }
-)
-
-func TestSimpleCoin(t *testing.T) {
- if testSimpleCoin.Hash().String() != testSimpleCoinTxHash {
- t.Errorf("Expected tx hash %v but got %v", testSimpleCoinTxHash, testSimpleCoin.Hash().String())
- }
- if testSimpleCoin.Index() != 0 {
- t.Error("Different value for index of outpoint than expected")
- }
- if testSimpleCoin.Value() != testSimpleCoinTxValue0 {
- t.Error("Different value of coin value than expected")
- }
- if !bytes.Equal(testSimpleCoin.ScriptPubKey(), testSimpleCoinTxScriptPubKey0Bytes) {
- t.Error("Different value of coin scriptPubKey than expected")
- }
- if testSimpleCoin.NumConfs() != 1 {
- t.Error("Differet value of num confs than expected")
- }
- if testSimpleCoin.ValueAge() != testSimpleCoinTxValueAge0 {
- t.Error("Different value of coin value * age than expected")
- }
-}
diff --git a/util/coinset/cov_report.sh b/util/coinset/cov_report.sh
deleted file mode 100644
index 307f05b76..000000000
--- a/util/coinset/cov_report.sh
+++ /dev/null
@@ -1,17 +0,0 @@
-#!/bin/sh
-
-# This script uses gocov to generate a test coverage report.
-# The gocov tool my be obtained with the following command:
-# go get github.com/axw/gocov/gocov
-#
-# It will be installed to $GOPATH/bin, so ensure that location is in your $PATH.
-
-# Check for gocov.
-type gocov >/dev/null 2>&1
-if [ $? -ne 0 ]; then
- echo >&2 "This script requires the gocov tool."
- echo >&2 "You may obtain it with the following command:"
- echo >&2 "go get github.com/axw/gocov/gocov"
- exit 1
-fi
-gocov test | gocov report
diff --git a/util/coinset/test_coverage.txt b/util/coinset/test_coverage.txt
deleted file mode 100644
index 0e3e15d9f..000000000
--- a/util/coinset/test_coverage.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-
-github.com/conformal/btcutil/coinset/coins.go MinPriorityCoinSelector.CoinSelect 100.00% (39/39)
-github.com/conformal/btcutil/coinset/coins.go NewMsgTxWithInputCoins 100.00% (6/6)
-github.com/conformal/btcutil/coinset/coins.go MinIndexCoinSelector.CoinSelect 100.00% (6/6)
-github.com/conformal/btcutil/coinset/coins.go CoinSet.removeElement 100.00% (5/5)
-github.com/conformal/btcutil/coinset/coins.go NewCoinSet 100.00% (4/4)
-github.com/conformal/btcutil/coinset/coins.go CoinSet.Coins 100.00% (4/4)
-github.com/conformal/btcutil/coinset/coins.go CoinSet.PopCoin 100.00% (4/4)
-github.com/conformal/btcutil/coinset/coins.go CoinSet.ShiftCoin 100.00% (4/4)
-github.com/conformal/btcutil/coinset/coins.go MinNumberCoinSelector.CoinSelect 100.00% (4/4)
-github.com/conformal/btcutil/coinset/coins.go MaxValueAgeCoinSelector.CoinSelect 100.00% (4/4)
-github.com/conformal/btcutil/coinset/coins.go CoinSet.PushCoin 100.00% (3/3)
-github.com/conformal/btcutil/coinset/coins.go CoinSet.TotalValueAge 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go SimpleCoin.NumConfs 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go SimpleCoin.ValueAge 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go CoinSet.TotalValue 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go byValueAge.Len 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go byValueAge.Swap 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go byValueAge.Less 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go byAmount.Len 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go byAmount.Swap 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go byAmount.Less 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go SimpleCoin.Hash 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go SimpleCoin.Index 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go SimpleCoin.txOut 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go SimpleCoin.Value 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go SimpleCoin.PkScript 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go CoinSet.Num 100.00% (1/1)
-github.com/conformal/btcutil/coinset/coins.go satisfiesTargetValue 100.00% (1/1)
-github.com/conformal/btcutil/coinset ---------------------------------- 100.00% (100/100)
-
diff --git a/util/daghash/README.md b/util/daghash/README.md
index 0e3ec502d..e9bb52db0 100644
--- a/util/daghash/README.md
+++ b/util/daghash/README.md
@@ -1,41 +1,10 @@
-chainhash
+daghash
=========
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
-[](http://godoc.org/github.com/kaspanet/kaspad/chaincfg/chainhash)
+[](http://godoc.org/github.com/kaspanet/kaspad/util/daghash)
=======
-chainhash provides a generic hash type and associated functions that allows the
+daghash provides a generic hash type and associated functions that allows the
specific hash algorithm to be abstracted.
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/chaincfg/chainhash
-```
-
-## 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 chainhash is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/util/hdkeychain/README.md b/util/hdkeychain/README.md
index 06e9b3018..375a71f4d 100644
--- a/util/hdkeychain/README.md
+++ b/util/hdkeychain/README.md
@@ -1,33 +1,27 @@
hdkeychain
==========
-[](https://travis-ci.org/btcsuite/btcutil)
[](http://copyfree.org)
-[](http://godoc.org/github.com/daglabs/btcutil/hdkeychain)
+[](http://godoc.org/github.com/kaspanet/kaspad/util/hdkeychain)
-Package hdkeychain provides an API for bitcoin hierarchical deterministic
-extended keys (BIP0032).
-
-A comprehensive suite of tests is provided to ensure proper functionality. 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 hdkeychain provides an API for kaspa hierarchical deterministic
+extended keys.
## Feature Overview
-- Full BIP0032 implementation
+- Full BIP0032-compatible implementation
- Single type for private and public extended keys
- Convenient cryptograpically secure seed generation
- Simple creation of master nodes
- Support for multi-layer derivation
- Easy serialization and deserialization for both private and public extended
keys
-- Support for custom networks by registering them with chaincfg
-- Obtaining the underlying EC pubkeys, EC privkeys, and associated bitcoin
- addresses ties in seamlessly with existing btcec and btcutil types which
- provide powerful tools for working with them to do things like sign
- transations and generate payment scripts
-- Uses the btcec package which is highly optimized for secp256k1
+- Support for custom networks by registering them with dagconfig
+- Obtaining the underlying EC pubkeys, EC privkeys, and associated kaspa
+ addresses ties in seamlessly with existing `ecc` and `util` types which provide
+ powerful tools for working with them to do things like sign transations and
+ generate payment scripts
+- Uses the `ecc` package which is highly optimized for secp256k1
- Code examples including:
- Generating a cryptographically secure random seed and deriving a
master node from it
@@ -36,24 +30,14 @@ report.
- Comprehensive test coverage including the BIP0032 test vectors
- Benchmarks
-## Installation and Updating
-
-```bash
-$ go get -u github.com/daglabs/btcutil/hdkeychain
-```
-
## Examples
-* [NewMaster Example](http://godoc.org/github.com/daglabs/btcutil/hdkeychain#example-NewMaster)
+* [NewMaster Example](http://godoc.org/github.com/kaspanet/kaspad/util/hdkeychain#example-NewMaster)
Demonstrates how to generate a cryptographically random seed then use it to
create a new master node (extended key).
-* [Default Wallet Layout Example](http://godoc.org/github.com/daglabs/btcutil/hdkeychain#example-package--DefaultWalletLayout)
+* [Default Wallet Layout Example](http://godoc.org/github.com/kaspanet/kaspad/util/hdkeychain#example-package--DefaultWalletLayout)
Demonstrates the default hierarchical deterministic wallet layout as described
in BIP0032.
-* [Audits Use Case Example](http://godoc.org/github.com/daglabs/btcutil/hdkeychain#example-package--Audits)
+* [Audits Use Case Example](http://godoc.org/github.com/kaspanet/kaspad/util/hdkeychain#example-package--Audits)
Demonstrates the audits use case in BIP0032.
-## License
-
-Package hdkeychain is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/util/txsort/README.md b/util/txsort/README.md
index 1c80408c2..d64cc621b 100644
--- a/util/txsort/README.md
+++ b/util/txsort/README.md
@@ -1,31 +1,18 @@
txsort
======
-[](https://travis-ci.org/btcsuite/btcutil)
[](http://copyfree.org)
-[](http://godoc.org/github.com/daglabs/btcutil/txsort)
+[](http://godoc.org/github.com/kaspanet/kaspad/util/txsort)
-Package txsort provides the transaction sorting according to [BIP 69](https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki).
+Package txsort provides the transaction sorting compatible with to [BIP 69](https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki).
BIP 69 defines a standard lexicographical sort order of transaction inputs and
-outputs. This is useful to standardize transactions for faster multi-party
+outputs. This is useful to standardize transactions for faster multi-party
agreement as well as preventing information leaks in a single-party use case.
The BIP goes into more detail, but for a quick and simplistic overview, the
order for inputs is defined as first sorting on the previous output hash and
-then on the index as a tie breaker. The order for outputs is defined as first
+then on the index as a tie breaker. The order for outputs is defined as first
sorting on the amount and then on the raw public key script bytes as a tie
breaker.
-A comprehensive suite of tests is provided to ensure proper functionality.
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/daglabs/btcutil/txsort
-```
-
-## License
-
-Package txsort is licensed under the [copyfree](http://copyfree.org) ISC
-License.
diff --git a/wire/README.md b/wire/README.md
index db4ef3409..465001f6f 100644
--- a/wire/README.md
+++ b/wire/README.md
@@ -1,60 +1,44 @@
wire
====
-[](https://travis-ci.org/btcsuite/btcd)
[](http://copyfree.org)
[](http://godoc.org/github.com/kaspanet/kaspad/wire)
=======
-Package wire implements the bitcoin wire protocol. A comprehensive suite of
-tests with 100% test coverage is provided to ensure proper functionality.
+Package wire implements the kaspa wire protocol.
-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/).
+## Kaspa Message Overview
-This package has intentionally been designed so it can be used as a standalone
-package for any projects needing to interface with bitcoin peers at the wire
-protocol level.
-
-## Installation and Updating
-
-```bash
-$ go get -u github.com/kaspanet/kaspad/wire
-```
-
-## Bitcoin Message Overview
-
-The bitcoin protocol consists of exchanging messages between peers. Each message
+The kaspa protocol consists of exchanging messages between peers. Each message
is preceded by a header which identifies information about it such as which
-bitcoin network it is a part of, its type, how big it is, and a checksum to
+kaspa network it is a part of, its type, how big it is, and a checksum to
verify validity. All encoding and decoding of message headers is handled by this
package.
-To accomplish this, there is a generic interface for bitcoin messages named
+To accomplish this, there is a generic interface for kaspa messages named
`Message` which allows messages of any type to be read, written, or passed
around through channels, functions, etc. In addition, concrete implementations
-of most of the currently supported bitcoin messages are provided. For these
-supported messages, all of the details of marshalling and unmarshalling to and
-from the wire using bitcoin encoding are handled so the caller doesn't have to
-concern themselves with the specifics.
+of most all kaspa messages are provided. All of the details of marshalling and
+unmarshalling to and from the wire using kaspa encoding are handled so the
+caller doesn't have to concern themselves with the specifics.
## Reading Messages Example
-In order to unmarshal bitcoin messages from the wire, use the `ReadMessage`
+In order to unmarshal kaspa messages from the wire, use the `ReadMessage`
function. It accepts any `io.Reader`, but typically this will be a `net.Conn`
-to a remote node running a bitcoin peer. Example syntax is:
+to a remote node running a kaspa peer. Example syntax is:
```Go
// Use the most recent protocol version supported by the package and the
- // main bitcoin network.
+ // main kaspa network.
pver := wire.ProtocolVersion
- btcnet := wire.MainNet
+ kaspanet := wire.MainNet
- // Reads and validates the next bitcoin message from conn using the
- // protocol version pver and the bitcoin network btcnet. The returns
+ // Reads and validates the next kaspa message from conn using the
+ // protocol version pver and the kaspa network kaspanet. The returns
// are a wire.Message, a []byte which contains the unmarshalled
// raw payload, and a possible error.
- msg, rawPayload, err := wire.ReadMessage(conn, pver, btcnet)
+ msg, rawPayload, err := wire.ReadMessage(conn, pver, kaspanet)
if err != nil {
// Log and handle the error
}
@@ -64,50 +48,25 @@ See the package documentation for details on determining the message type.
## Writing Messages Example
-In order to marshal bitcoin messages to the wire, use the `WriteMessage`
+In order to marshal kaspa messages to the wire, use the `WriteMessage`
function. It accepts any `io.Writer`, but typically this will be a `net.Conn`
-to a remote node running a bitcoin peer. Example syntax to request addresses
+to a remote node running a kaspa peer. Example syntax to request addresses
from a remote peer is:
```Go
// Use the most recent protocol version supported by the package and the
// main bitcoin network.
pver := wire.ProtocolVersion
- btcnet := wire.MainNet
+ kaspanet := wire.MainNet
- // Create a new getaddr bitcoin message.
+ // Create a new getaddr kaspa message.
msg := wire.NewMsgGetAddr()
- // Writes a bitcoin message msg to conn using the protocol version
- // pver, and the bitcoin network btcnet. The return is a possible
+ // Writes a kaspa message msg to conn using the protocol version
+ // pver, and the kaspa network kaspanet. The return is a possible
// error.
- err := wire.WriteMessage(conn, msg, pver, btcnet)
+ err := wire.WriteMessage(conn, msg, pver, kaspanet)
if err != nil {
// Log and handle the error
}
```
-
-## GPG Verification Key
-
-All official release tags are signed by Conformal so users can ensure the code
-has not been tampered with and is coming from the btcsuite developers. To
-verify the signature perform the following:
-
-- Download the public key from the Conformal website at
- https://opensource.conformal.com/GIT-GPG-KEY-conformal.txt
-
-- Import the public key into your GPG keyring:
- ```bash
- gpg --import GIT-GPG-KEY-conformal.txt
- ```
-
-- Verify the release tag with the following command where `TAG_NAME` is a
- placeholder for the specific tag:
- ```bash
- git tag -v TAG_NAME
- ```
-
-## License
-
-Package wire is licensed under the [copyfree](http://copyfree.org) ISC
-License.