spo

module
v0.0.0-...-9802667 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: May 27, 2018 License: Apache-2.0

README

Spo

Build Status GoDoc Go Report Card

Spo is a next-generation cryptocurrency.

Spo improves on Bitcoin in too many ways to be addressed here.

Spo is a small part of OP Redecentralize and OP Darknet Plan.

Table of Contents

Changelog

CHANGELOG.md

Installation

Spo supports go1.9+. The preferred version is go1.10.

Go 1.9+ Installation and Setup

Golang 1.9+ Installation/Setup

Go get spo
go get github.com/spo-next/spo/...

This will download github.com/spo-next/spo to $GOPATH/src/github.com/spo-next/spo.

You can also clone the repo directly with git clone https://github.com/spo-next/spo, but it must be cloned to this path: $GOPATH/src/github.com/spo-next/spo.

Run Spo from the command line
cd $GOPATH/src/github.com/spo-next/spo
make run
Show Spo node options
cd $GOPATH/src/github.com/spo-next/spo
make run-help
Run Spo with options

Example:

cd $GOPATH/src/github.com/spo-next/spo
make ARGS="--launch-browser=false -data-dir=/custom/path" run
Docker image

This is the quickest way to start using Spo using Docker.

$ docker volume create spo-data
$ docker volume create spo-wallet
$ docker run -ti --rm \
    -v spo-data:/data \
    -v spo-wallet:/wallet \
    -p 8858:8858\
    -p 8620:8620 \
    -p 8630:8630 \
    spo/spo

This image has a spo user for the spo daemon to run, with UID and GID 10000. When you mount the volumes, the container will change their owner, so you must be aware that if you are mounting an existing host folder any content you have there will be own by 10000.

The container will run with some default options, but you can change them by just appending flags at the end of the docker run command. The following example will show you the available options.

docker run --rm spo/spo -help

Access the dashboard: http://localhost:8640.

Access the API: http://localhost:8640/version.

Building your own images

There is a Dockerfile in docker/images/mainnet that you can use to build your own image. By default it will build your working copy, but if you pass the SPO_VERSION build argument to the docker build command, it will checkout to the branch, a tag or a commit you specify on that variable.

Example

$ git clone https://github.com/spo-next/spo
$ cd spo
$ SPO_VERSION=v0.23.0
$ docker build -f docker/images/mainnet/Dockerfile \
  --build-arg=SPO_VERSION=$SPO_VERSION \
  -t spo:$SPO_VERSION .

or just

$ docker build -f docker/images/mainnet/Dockerfile \
  --build-arg=SPO_VERSION=v0.23.0 \
  -t spo:v0.23.0 .

API Documentation

REST API

REST API.

JSON-RPC 2.0 API

Deprecated, avoid using this

JSON-RPC 2.0 README.

Spo command line interface

CLI command API.

Integrating Spo with your application

Spo Integration Documentation

Contributing a node to the network

Add your node's ip:port to the peers.txt file. This file will be periodically uploaded to https://downloads.spo.network/blockchain/peers.txt and used to seed client with peers.

Note: Do not add Skywire nodes to peers.txt. Only add Spo nodes with high uptime and a static IP address (such as a Spo node hosted on a VPS).

URI Specification

Spo URIs obey the same rules as specified in Bitcoin's BIP21. They use the same fields, except with the addition of an optional hours parameter, specifying the coin hours.

Example Spo URIs:

  • spo:2hYbwYudg34AjkJJCRVRcMeqSWHUixjkfwY
  • spo:2hYbwYudg34AjkJJCRVRcMeqSWHUixjkfwY?amount=123.456&hours=70
  • spo:2hYbwYudg34AjkJJCRVRcMeqSWHUixjkfwY?amount=123.456&hours=70&label=friend&message=Birthday%20Gift

Development

We have two branches: master and develop.

develop is the default branch and will have the latest code.

master will always be equal to the current stable release on the website, and should correspond with the latest release tag.

Modules
  • /src/cipher - cryptography library
  • /src/coin - the blockchain
  • /src/daemon - networking and wire protocol
  • /src/visor - the top level, client
  • /src/gui - the web wallet and json client interface
  • /src/wallet - the private key storage library
  • /src/api/webrpc - JSON-RPC 2.0 API
  • /src/api/cli - CLI library
Client libraries

Spo implements client libraries which export core functionality for usage from other programming languages. Read the corresponding README file for further details.

  • lib/cgo/ - libspo C client library ( read more )
Running Tests
make test
Running Integration Tests

There are integration tests for the CLI and HTTP API interfaces. They have two run modes, "stable" and "live.

The stable integration tests will use a spo daemon whose blockchain is synced to a specific point and has networking disabled so that the internal state does not change.

The live integration tests should be run against a synced or syncing node with networking enabled.

Stable Integration Tests
make integration-test-stable

or

./ci-scripts/integration-test-stable.sh -v -w

The -w option, run wallet integrations tests.

The -v option, show verbose logs.

Live Integration Tests

The live integration tests run against a live runnning spo node, so before running the test, we need to start a spo node.

After the spo node is up, run the following command to start the live tests:

./ci-scripts/integration-test.live.sh -v

The above command will run all tests except the wallet related tests. To run wallet tests, we need to manually specify a wallet file, and it must have at least 2 coins and 256 coinhours, it also must have been loaded by the node.

We can specify the wallet by setting two environment variables: WALLET_DIR and WALLET_NAME. The WALLET_DIR represents the absolute path of the wallet directory, and WALLET_NAME represents the wallet file name.

Note: WALLET_DIR is only used by the CLI integration tests. The GUI integration tests use the node's configured wallet directory, which can be controlled with -wallet-dir when running the node.

If the wallet is encrypted, also set WALLET_PASSWORD.

export WALLET_DIR="$HOME/.spo/wallets"
export WALLET_NAME="$valid_wallet_filename"
export WALLET_PASSWORD="$wallet_password"

Then run the tests with the following command:

make integration-test-live

or

./ci-scripts/integration-test-live.sh -v -w
Debugging Integration Tests

Run specific test case:

It's annoying and a waste of time to run all tests to see if the test we real care is working correctly. There's an option: -r, which can be used to run specific test case. For exampe: if we only want to test TestStableAddressBalance and see the result, we can run:

./ci-scripts/integration-test-stable.sh -v -r TestStableAddressBalance
Update golden files in integration test-fixtures

Golden files are expected data responses from the CLI or HTTP API saved to disk. When the tests are run, their output is compared to the golden files.

To update golden files, use the -u option:

./ci-scripts/integration-test-live.sh -v -u
./ci-scripts/integration-test-stable.sh -v -u

We can also update a specific test case's golden file with the -r option.

Formatting

All .go source files should be formatted goimports. You can do this with:

make format
Code Linting

Install prerequisites:

make install-linters

Run linters:

make lint
Dependency Management

Dependencies are managed with dep.

To install dep:

go get -u github.com/golang/dep

dep vendors all dependencies into the repo.

If you change the dependencies, you should update them as needed with dep ensure.

Use dep help for instructions on vendoring a specific version of a dependency, or updating them.

When updating or initializing, dep will find the latest version of a dependency that will compile.

Examples:

Initialize all dependencies:

dep init

Update all dependencies:

dep ensure -update -v

Add a single dependency (latest version):

dep ensure github.com/foo/bar

Add a single dependency (more specific version), or downgrade an existing dependency:

dep ensure github.com/foo/bar@tag
Wallet GUI Development

The compiled wallet source should be checked in to the repo, so that others do not need to install node to run the software.

Instructions for doing this:

Wallet GUI Development README

Releases
  1. If the master branch has commits that are not in develop (e.g. due to a hotfix applied to master), merge master into develop
  2. Compile the src/gui/dist/ to make sure that it is up to date (see Wallet GUI Development README)
  3. Update all version strings in the repo (grep for them) to the new version
  4. Update CHANGELOG.md: move the "unreleased" changes to the version and add the date
  5. Merge these changes to develop
  6. Follow the steps in pre-release testing
  7. Make a PR merging develop into master
  8. Review the PR and merge it
  9. Tag the master branch with the version number. Version tags start with v, e.g. v0.20.0. Sign the tag. Example: git tag -as v0.20.0 $COMMIT_ID.
  10. Make sure that the client runs properly from the master branch
  11. Create the release builds from the master branch (see Create Release builds)

If there are problems discovered after merging to master, start over, and increment the 3rd version number. For example, v0.20.0 becomes v0.20.1, for minor fixes.

Pre-release testing

Performs these actions before releasing:

  • make check
  • make integration-test-live (see live integration tests) both with an unencrypted and encrypted wallet.
  • go run cmd/cli/cli.go checkdb against a synced node
  • On all OSes, make sure that the client runs properly from the command line (./run.sh)
  • Build the releases and make sure that the Electron client runs properly on Windows, Linux and macOS.
    • Use a clean data directory with no wallets or database to sync from scratch and verify the wallet setup wizard.
    • Load a test wallet with nonzero balance from seed to confirm wallet loading works
    • Send coins to another wallet to confirm spending works
    • Restart the client, confirm that it reloads properly
Creating release builds

Create Release builds.

Release signing

Releases are signed with this PGP key:

0x5801631BD27C7874

The fingerprint for this key is:

pub   ed25519 2017-09-01 [SC] [expires: 2023-03-18]
      10A7 22B7 6F2F FE7B D238  0222 5801 631B D27C 7874
uid                      GZ-C SPO <token@protonmail.com>
sub   cv25519 2017-09-01 [E] [expires: 2023-03-18]

Keybase.io account: https://keybase.io/gzc

Follow the Tor Project's instructions for verifying signatures.

If you can't or don't want to import the keys from a keyserver, the signing key is available in the repo: gz-c.asc.

Releases and their signatures can be found on the releases page.

Instructions for generating a PGP key, publishing it, signing the tags and binaries: https://gist.github.com/gz-c/de3f9c43343b2f1a27c640fe529b067c

Directories

Path Synopsis
cmd
address_gen command
address_gen2 command
address_stats command
cli command
encry command
spo command
lib
cgo command
src
api/cli
Package cli implements an interface for creating a CLI application.
Package cli implements an interface for creating a CLI application.
cipher/chacha20poly1305
Package chacha20poly1305 implements the ChaCha20-Poly1305 AEAD as specified in RFC 7539.
Package chacha20poly1305 implements the ChaCha20-Poly1305 AEAD as specified in RFC 7539.
cipher/chacha20poly1305/internal/chacha20
Package chacha20 implements the core ChaCha20 function as specified in https://tools.ietf.org/html/rfc7539#section-2.3.
Package chacha20 implements the core ChaCha20 function as specified in https://tools.ietf.org/html/rfc7539#section-2.3.
cipher/encoder
Package encoder binary implements translation between numbers and byte sequences and encoding and decoding of varints.
Package encoder binary implements translation between numbers and byte sequences and encoding and decoding of varints.
cipher/pbkdf2
Package pbkdf2 implements the key derivation function PBKDF2 as defined in RFC 2898 / PKCS #5 v2.0.
Package pbkdf2 implements the key derivation function PBKDF2 as defined in RFC 2898 / PKCS #5 v2.0.
cipher/poly1305
Package poly1305 implements Poly1305 one-time message authentication code as specified in http://cr.yp.to/mac/poly1305-20050329.pdf.
Package poly1305 implements Poly1305 one-time message authentication code as specified in http://cr.yp.to/mac/poly1305-20050329.pdf.
cipher/ripemd160
Package ripemd160 implements the RIPEMD-160 hash algorithm.
Package ripemd160 implements the RIPEMD-160 hash algorithm.
cipher/scrypt
Package scrypt implements the scrypt key derivation function as defined in Colin Percival's paper "Stronger Key Derivation via Sequential Memory-Hard Functions" (http://www.tarsnap.com/scrypt/scrypt.pdf).
Package scrypt implements the scrypt key derivation function as defined in Colin Percival's paper "Stronger Key Derivation via Sequential Memory-Hard Functions" (http://www.tarsnap.com/scrypt/scrypt.pdf).
cipher/secp256k1-go
nolint: golint
nolint: golint
consensus
nolint 20160901 - Initial version by user johnstuartmill, public key 02fb4acf944c84d48341e3c1cb14d707034a68b7f931d6be6d732bec03597d6ff6 20161025 - Code revision by user johnstuartmill.
nolint 20160901 - Initial version by user johnstuartmill, public key 02fb4acf944c84d48341e3c1cb14d707034a68b7f931d6be6d732bec03597d6ff6 20161025 - Code revision by user johnstuartmill.
nolint
daemon/pex
Package pex is a toolkit for implementing a peer exchange system
Package pex is a toolkit for implementing a peer exchange system
gui
util/file
Package file Filesystem related utilities
Package file Filesystem related utilities
util/http
Package httphelper HTTP Error Response Helpers
Package httphelper HTTP Error Response Helpers
util/utc
Package utc provides helper function to get UTC time
Package utc provides helper function to get UTC time
visor/historydb
Package historydb is in charge of parsing the consuses blokchain, and providing apis for blockchain explorer.
Package historydb is in charge of parsing the consuses blokchain, and providing apis for blockchain explorer.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL