GithubHelp home page GithubHelp logo

libskycoin's Introduction

skycoin logo

Skycoin

Go GoDoc Go Report Card

Skycoin is a next-generation cryptocurrency.

Skycoin was written from scratch and designed over four years to realize the ideal of Bitcoin and represents the apex of cryptocurrency design. Skycoin is not designed to add features to Bitcoin, but rather improves Bitcoin by increasing simplicity, security and stripping out everything non-essential.

Some people have hyped the Skycoin Project as leading into "Bitcoin 3.0". The coin itself is not "Bitcoin 3.0", but is rather "Bitcoin 1.0". Bitcoin is a prototype crypto-coin. Skycoin was designed to be what Bitcoin would look like if it were built from scratch, to remedy the rough edges in the Bitcoin design.

  • no duplicate coin-base outputs
  • enforced checks for hash collisions
  • simple deterministic wallets
  • no transaction malleability
  • no signature malleability
  • removal of the scripting language
  • CoinJoin and normal transactions are indistinguishable
  • elimination of edge-cases that prevent independent node implementations
  • <=10 second transaction times
  • elimination of the need for mining to achieve blockchain consensus

Links

Table of Contents

Changelog

CHANGELOG.md

Installation

Skycoin supports go1.14+.

Go 1.14+ Installation and Setup

Golang 1.14+ Installation/Setup

Go get skycoin

$ go get github.com/skycoin/skycoin/cmd/...

This will download github.com/skycoin/skycoin to $GOPATH/src/github.com/skycoin/skycoin.

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

Run Skycoin from the command line

$ cd $GOPATH/src/github.com/skycoin/skycoin
$ make run-client

Show Skycoin node options

$ cd $GOPATH/src/github.com/skycoin/skycoin
$ make run-help

Run Skycoin with options

Example:

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

Docker image

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

$ docker volume create skycoin-data
$ docker volume create skycoin-wallet
$ docker run -ti --rm \
    -v skycoin-data:/data/.skycoin \
    -v skycoin-wallet:/wallet \
    -p 6000:6000 \
    -p 6420:6420 \
    skycoin/skycoin

This image has a skycoin user for the skycoin 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 skycoin/skycoin -help

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

Building your own images

Building your own images.

Development image

The skycoin/skycoindev-cli docker image is provided in order to make easy to start developing Skycoin. It comes with the compiler, linters, debugger and the vim editor among other tools.

The skycoin/skycoindev-dind docker image comes with docker installed and all tools available on skycoin/skycoindev-cli:develop docker image.

Also, the skycoin/skycoindev-vscode docker image is provided to facilitate the setup of the development process with Visual Studio Code and useful tools included in skycoin/skycoindev-cli.

API Documentation

REST API

REST API.

Skycoin command line interface

CLI command API.

Integrating Skycoin with your application

Skycoin 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.skycoin.com/blockchain/peers.txt and used to seed client with peers.

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

Creating a new coin

See the newcoin tool README

Daemon CLI Options

See the Skycoin Daemon CLI options

URI Specification

Skycoin 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 Skycoin URIs:

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

Additonally, if no skycoin: prefix is present when parsing, the string may be treated as an address:

  • 2hYbwYudg34AjkJJCRVRcMeqSWHUixjkfwY

However, do not use this URI in QR codes displayed to the user, because the address can't be disambiguated from other Skyfiber coins.

Wire protocol user agent

Wire protocol user agent description

Offline transaction signing

Before doing the offline transaction signing, we need to have the unsigned transaction created. Using the skycoin-cli tool to create an unsigned transaction in hot wallet, and copy the hex encoded transaction to the computer where the cold wallet is installed. Then use the skycoin-cli tool to sign it offline.

Create an unsigned transaction

The skycoin-cli tool replys on the APIs of the skycoin node, hence we have to start the node before running the tool.

Go to the project root and run:

$ ./run-client.sh -launch-browser=false

Once the node is started, we could use the following command to create an unsigned transaction.

$ skycoin-cli createRawTransactionV2 $WALLET_NAME $RECIPIENT_ADDRESS $AMOUNT --unsign

Note: Don't forget the --unsign flag, otherwise it would try to sign the transaction.

View Output
b700000000e6b869f570e2bfebff1b4d7e7c9e86885dbc34d6de988da6ff998e7acd7e6e14010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000007531184ad0afeebbff2049b855e0921329cb1cb74d769ac57c057c9c8bd2b6810100000000ed5ea2ca4fe9b4560409b50c5bf7cb39b6c5ff6e50690f00000000000000000000000000

Copy and save the generated transaction string. We will sign it with a cold wallet offline in the next section.

Sign the transaction

The skycoin node needs to have the most recently DB so that the user would not lose much coin hours when signing the transaction. We could copy the full synchronized data.db from the hot wallet to the computer where the cold wallet is installed. And place it in $HOME/.skycoin/data.db. Then start the node with the network disabled.

$ ./run-client.sh -launch-browser=false -disable-networking

Run the following command to sign the transaction:

$ skycoin-cli signTransaction $RAW_TRANSACTION

The $RAW_TRANSACTION is the transaction string that we generated in the hot wallet.

If the cold wallet is encrypted, you will be prompted to enter the password to sign the transaction.

View Output
b700000000e6b869f570e2bfebff1b4d7e7c9e86885dbc34d6de988da6ff998e7acd7e6e14010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000007531184ad0afeebbff2049b855e0921329cb1cb74d769ac57c057c9c8bd2b6810100000000ed5ea2ca4fe9b4560409b50c5bf7cb39b6c5ff6e50690f00000000000000000000000000

Once the transaction is signed, we could copy and save the signed transaction string and broadcast it in the hot wallet.

$ skycoin-cli broadcastTransaction $SIGNED_RAW_TRANSACTION

A transaction id would be returned and you can check it in the explorer.

Deploy a public Skycoin API node with HTTPS

We recommend using caddy server to deploy a public Skycoin API node on a Linux server. The public API node should have the HTTPS support, which could be handled automatically by the caddy server. But we need to have a domain and create a DNS record to bind the server ip address to it.

Suppose we're going to deploy a Skycoin API node on apitest.skycoin.com, and we have already bound the server's IP to it. Follow the steps below to complete the deployment.

Install and run a skycoin api node

# Create a skycoin folder so that the files could be isolated
$ mkdir $HOME/skycoin && cd $HOME/skycoin
# Download the skycoin binary file
$ wget https://downloads.skycoin.com/wallet/skycoin-0.26.0-gui-standalone-linux-x64.tar.gz
$ tar -zxvf skycoin-0.26.0-gui-standalone-linux-x64.tar.gz
$ cd skycoin-0.26.0-gui-standalone-linux-x64
$ ./skycoin -web-interface-port=6420 -host-whitelist=$DOMAIN_NAME -enable-api-sets="READ,TXN"

Note: we should running the skycoin node with -host-whitelist flag, otherwise it would throw 403 Forbidden error.

Install the caddy server

# Create a caddy folder
$ mkdir $HOME/caddy && cd $HOME/caddy
# Download the caddy server binary file
$ wget https://github.com/caddyserver/caddy/releases/download/v1.0.4/caddy_v1.0.4_linux_amd64.tar.gz
$ tar -zxvf caddy_v1.0.4_linux_amd64.tar.gz
$ cd caddy_v1.0.4_linux_amd64

The caddy tool would be exist in the folder, let's create a Caddyfile to define the reverse proxy rules now.

cat <<EOF >Caddyfile
apitest.skycoin.com {
   proxy / localhost:6420 {
      transparent
   }
}
EOF

Then run the caddy server

$ ./caddy

You will be prompted to enter an email address to receive the notifications from let's Encrypt. That's all about the deployment, check the https://apitest.skycoin.com/api/v1/version to see if the Skycoin API node is working correctly.

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

  • api - REST API interface
  • cipher - cryptographic library (key generation, addresses, hashes)
  • cipher/base58 - Base58 encoding
  • cipher/encoder - reflect-based deterministic runtime binary encoder
  • cipher/encrypt - at-rest data encryption (chacha20poly1305+scrypt)
  • cipher/go-bip39 - BIP-39 seed generation
  • cli - CLI library
  • coin - blockchain data structures (blocks, transactions, unspent outputs)
  • daemon - top-level application manager, combining all components (networking, database, wallets)
  • daemon/gnet - networking library
  • daemon/pex - peer management
  • params - configurable transaction verification parameters
  • readable - JSON-encodable representations of internal structures
  • skycoin - core application initialization and configuration
  • testutil - testing utility methods
  • transaction - methods for creating transactions
  • util - miscellaneous utilities
  • visor - top-level blockchain database layer
  • visor/blockdb - low-level blockchain database layer
  • visor/historydb - low-level blockchain database layer for historical blockchain metadata
  • wallet - wallet file management

Client libraries

Skycoin implements client libraries which export core functionality for usage from other programming languages.

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 skycoin 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 skycoin node, so before running the test, we need to start a skycoin node:

$ ./run-daemon.sh

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

$ make integration-test-live

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:

  • API_WALLET_ID, which is the filename (without path), that is loaded by the daemon to test against. This is the "id" field in API requests. It is used by the API integration tests. The wallet directory that the daemon uses can be controlled with the -wallet-dir option.
  • CLI_WALLET_FILE, which is the filename (with path), to be used by the CLI integration tests

If the wallet is encrypted, also set WALLET_PASSWORD.

Example of running the daemon with settings for integration tests:

$ export API_WALLET_ID="$valid_wallet_filename"
$ export CLI_WALLET_FILE="$HOME/.skycoin/wallets/$valid_wallet_filename"
$ export WALLET_PASSWORD="$wallet_password"
$ make run-integration-test-live

Then run the tests with the following command:

$ make integration-test-live-wallet

There are two other live integration test modes for CSRF disabled and networking disabled.

To run the CSRF disabled tests:

$ export API_WALLET_ID="$valid_wallet_filename"
$ export CLI_WALLET_FILE="$HOME/.skycoin/wallets/$valid_wallet_filename"
$ export WALLET_PASSWORD="$wallet_password"
$ make run-integration-test-live-disable-csrf
$ make integration-test-live-disable-csrf

To run the networking disabled tests, which require a live wallet:

$ export API_WALLET_ID="$valid_wallet_filename"
$ export CLI_WALLET_FILE="$HOME/.skycoin/wallets/$valid_wallet_filename"
$ export WALLET_PASSWORD="$wallet_password"
$ make run-integration-test-live-disable-networking

Then run the tests with the following command:

$ make integration-test-live-wallet

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 example: 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 testdata

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 provided make command:

$ make update-golden-files

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

$ ./ci-scripts/integration-test-stable.sh -v -u -r TestStableAddressBalance

Test coverage

Coverage is automatically generated for make test and integration tests run against a stable node. This includes integration test coverage. The coverage output files are placed in coverage/.

To merge coverage from all tests into a single HTML file for viewing:

$ make check
$ make merge-coverage

Then open coverage/all-coverage.html in the browser.

Test coverage for the live node

Some tests can only be run with a live node, for example wallet spending tests. To generate coverage for this, build and run the skycoin node in test mode before running the live integration tests.

In one shell:

$ make run-integration-test-live-cover

In another shell:

$ make integration-test-live

After the tests have run, CTRL-C to exit the process from the first shell. A coverage file will be generated at coverage/skycoin-live.coverage.out.

Merge the coverage with make merge-coverage then open the coverage/all-coverage.html file to view it, or generate the HTML coverage in isolation with go tool cover -html

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

Profiling

A full CPU profile of the program from start to finish can be obtained by running the node with the -profile-cpu flag. Once the node terminates, a profile file is written to -profile-cpu-file (defaults to cpu.prof). This profile can be analyzed with

$ go tool pprof cpu.prof

The HTTP interface for obtaining more profiling data or obtaining data while running can be enabled with -http-prof. The HTTP profiling interface can be controlled with -http-prof-host and listens on localhost:6060 by default.

See https://golang.org/pkg/net/http/pprof/ for guidance on using the HTTP profiler.

Some useful examples include:

$ go tool pprof http://localhost:6060/debug/pprof/profile?seconds=10
$ go tool pprof http://localhost:6060/debug/pprof/heap

A web page interface is provided by http/pprof at http://localhost:6060/debug/pprof/.

Fuzzing

Fuzz tests are run with go-fuzz. Follow the instructions on the go-fuzz page to install it.

Fuzz tests are written for the following packages:

base58

To fuzz the cipher/base58 package,

$ make fuzz-base58

encoder

To fuzz the cipher/encoder package,

$ make fuzz-encoder

Dependencies

Rules

Dependencies must not require cgo. This means dependencies cannot be wrappers around C libraries. Requiring cgo breaks cross compilation and interferes with repeatable (deterministic) builds.

Critical cryptographic dependencies used by code in package cipher are archived inside the cipher folder, rather than in the vendor folder. This prevents a user of the cipher package from accidentally using a different version of the cipher dependencies than were developed, which could have catastrophic but hidden problems.

Management

Dependencies are managed with go modules.

We still use the vendor folder to store our dependencies in case any of the them are removed from the internet in the future.

When the main module contains a top-level vendor directory and its go.mod file specifies go 1.14 or higher, the go command now defaults to -mod=vendor for operations that accept that flag.

Configuration Modes

There are 4 configuration modes in which you can run a skycoin node:

  • Development Desktop Daemon
  • Server Daemon
  • Electron Desktop Client
  • Standalone Desktop Client

Development Desktop Client Mode

This mode is configured via run-client.sh

$ ./run-client.sh

Server Daemon Mode

The default settings for a skycoin node are chosen for Server Daemon, which is typically run from source. This mode is usually preferred to be run with security options, though -disable-csrf is normal for server daemon mode, it is left enabled by default.

$ ./run-daemon.sh

To disable CSRF:

$ ./run-daemon.sh -disable-csrf

Electron Desktop Client Mode

This mode configures itself via electron-main.js

Standalone Desktop Client Mode

This mode is configured by compiling with STANDALONE_CLIENT build tag. The configuration is handled in cmd/skycoin/skycoin.go

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

Translations

You can find information about how to work with translation files in the Translations README.

Releases

Update the version

  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. Make sure the translations are up to date. See the i18n README for instructions on how to update translations and how to check if they are up to date.
  3. Compile the src/gui/static/dist/ to make sure that it is up to date (see Wallet GUI Development README)
  4. Update version strings to the new version in the following files: electron/package-lock.json, electron/package.json, electron/skycoin/current-skycoin.json, src/cli/cli.go, src/gui/static/src/current-skycoin.json, src/cli/integration/testdata/status*.golden, template/coin.template, README.md files .
  5. If changes require a new database verification on the next upgrade, update src/skycoin/skycoin.go's DBVerifyCheckpointVersion value
  6. Update CHANGELOG.md: move the "unreleased" changes to the version and add the date
  7. Update the files in https://github.com/skycoin/repo-info by following the metadata update procedure,
  8. Merge these changes to develop
  9. Follow the steps in pre-release testing
  10. Make a PR merging develop into master
  11. Review the PR and merge it
  12. Tag the master branch with the version number. Version tags start with v, e.g. v0.20.0. Sign the tag. If you have your GPG key in github, creating a release on the Github website will automatically tag the release. It can be tagged from the command line with git tag -as v0.20.0 $COMMIT_ID, but Github will not recognize it as a "release".
  13. Make sure that the client runs properly from the master branch
  14. Release builds are created and uploaded by travis. To do it manually, checkout the master branch and follow the create release builds instructions.

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.

Check the translations

Run make check-lang to check if the translation files of the UI are updated. If there is any error running that command, one or more translation files may need to be updated. For more information, check the translations section.

Pre-release testing

Performs these actions before releasing:

  • make check
  • make integration-test-live
  • make integration-test-live-disable-networking (requires node run with -disable-networking)
  • make integration-test-live-disable-csrf (requires node run with -disable-csrf)
  • make intergration-test-live-wallet (see live integration tests) 6 times: with an unencrypted and encrypted wallet for each wallet type: deterministic, bip44 and collection
  • go run cmd/skycoin-cli/skycoin-cli.go checkdb against a fully synced database
  • go run cmd/skycoin-cli/skycoin-cli.go checkDBDecoding against a fully synced database
  • On all OSes, make sure that the client runs properly from the command line (./run-client.sh and ./run-daemon.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
  • For both the Android and iOS mobile wallets, configure the node url to be https://staging.node.skycoin.com and test all operations to ensure it will work with the new node version.

Creating release builds

Create Release builds.

Release signing

Releases are signed with this PGP key:

0x913BBD5206B19620

The fingerprint for this key is:

pub   ed25519 2019-09-17 [SC] [expires: 2023-09-16]
      98F934F04F9334B81DFA3398913BBD5206B19620
uid           [ultimate] iketheadore skycoin <[email protected]>
sub   cv25519 2019-09-17 [E] [expires: 2023-09-16]

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

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: iketheadore.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/iketheadore/6485585ce2d22231c2cb3cbc77e1d7b7

Responsible Disclosure

Security flaws in skycoin source or infrastructure can be sent to [email protected]. Bounties are available for accepted critical bug reports.

PGP Key for signing:

-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEXYCYPxYJKwYBBAHaRw8BAQdAeDPi3n9xLv5xGsxbcbwZjfV4h772W+GPZ3Mz
RS17STm0L2lrZXRoZWFkb3JlIHNreWNvaW4gPGx1eGFpcmxha2VAcHJvdG9ubWFp
bC5jb20+iJYEExYIAD4WIQSY+TTwT5M0uB36M5iRO71SBrGWIAUCXYCYPwIbAwUJ
B4TOAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCRO71SBrGWID0NAP0VRiNA
2Kq2uakPMqV29HY39DVhc9QgxJfMIwXWtFxKAwEAn0NqGRV/iKXNf+qxqAtMWa5X
F2S36hkEfDHO5W44DwC4OARdgJg/EgorBgEEAZdVAQUBAQdAeiEz/tUmCgOA67Rq
ANmHmX2vrdZp/SfJ9KOI2ANCCm8DAQgHiH4EGBYIACYWIQSY+TTwT5M0uB36M5iR
O71SBrGWIAUCXYCYPwIbDAUJB4TOAAAKCRCRO71SBrGWIJOJAQDTaqxpcLtAw5kH
Hp2jWvUnLudIONeqeUTCmkLJhcNv1wD+PFJZWMKD1btIG4pkXRW9YoA7M7t5by5O
x5I+LywZNww=
=p6Gq
-----END PGP PUBLIC KEY BLOCK-----

Key ID: 0x913BBD5206B19620

The fingerprint for this key is:

pub   ed25519 2019-09-17 [SC] [expires: 2023-09-16]
      98F934F04F9334B81DFA3398913BBD5206B19620
uid           [ultimate] iketheadore skycoin <[email protected]>
sub   cv25519 2019-09-17 [E] [expires: 2023-09-16]

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

libskycoin's People

Contributors

bigookie avatar gz-c avatar hanyh2004 avatar iketheadore avatar karlob avatar ljesparis avatar mahansky avatar montycrypto avatar morphium avatar nakulpandey avatar olemis avatar polarislee1984 avatar samuelvisscher avatar senyoret1 avatar skycoin-main avatar spurserh avatar stdevalden avatar stdevedu avatar stdevmac avatar stdevmauricio avatar stdevnorge avatar stdevpavelmc avatar stdevstark avatar stdevyuniers avatar stgleb avatar therealssj avatar vavilen avatar zgordan-vv avatar zhiyuan2007 avatar zsm5j avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

libskycoin's Issues

C bindings for Skycoin hardware wallet .

Feature description

C bindings for Skycoin hardware wallet .

Describe the solution you'd like
Add methods to invoke in-process the commands defined in skycoin/hardware-wallet-go .

Describe alternatives you've considered
Maybe there is a similar C library for Trezor but using it leads to duplicated maintenance efforts

Additional context
This belongs in separate library

Possible implementation

  • skycoin/hardware-wallet submodule
  • cgo wrappers
  • Makefile targets
  • SWIG typemaps and interfaces
  • C test code

Ensure that all functions in Skycoin=0.26.0 exported in libskycoin=0.26.0

Describe the bug
libskycoin=0.26.0 API completeness

Environment information:

All platforms

Actual behavior

Some Skycoin core functions defined nowhere

$ grep -nr VerifyInputSignatures lib/

Expected behavior
All functions in cipher, coin, and other namespaces have to be included in libskycoin=0.26.0 public API .

Additional context
Discovered after #80 , see a391478 .

Possible implementation
Ensure that all functions in Skycoin=0.26.0 have a corresponding wrapper in libskycoin=0.26.0.

  • Add coin.Transaction.VerifyInputSignatures()
  • Document all new functions in CHANGELOG

Changes in SWIG for multiple return languages

Describe the bug
In the case of multiple return languages, Handle and uint64 cause byte losses in their conversion.

Environment information:

  • Platform: ARM and 32 bits
  • Go environment:
# Output of goenv e.g.
$ go env
GOARCH="386"
GOBIN="/go/bin"
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_386"
GCCGO="gccgo"
GO386="sse2"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build027231592=/tmp/go-build -gno-record-gcc-switches"

Reduce the number of builds in a travis build

The travis config is doing too many builds, which take a very long time (over 30 minutes) and block all other builds for our github organization (since travis limits us to 5 or 6 concurrent builds for the entire org).

Update libc for changes introduced in Skycoin==0.26.0

Feature description

Prepare libc for 0.26.0 release

Is your feature request related to a problem? Please describe.
Skycoin cipher API changed from 0.25.1 to 0.26.0

Additional context

Additional changes in SWIG interfaces might be needed.

Possible implementation

  • Review diff from Skycoin 0.25.1 to Skycoin 0.26.0
  • Take note of functions that were added, changed, or removed
  • Implement changes in lib/cgo
  • Take note of test cases that were added, changed, or removed
  • Implement changes in lib/cgo/tests

Support compilation of libskycoin for ARM 32 bit architectures

On Raspberry Pi 3B+ the following command

$ go get github.com/skycoin/skycoin/...

... fails at this statetemnt in skytypes.h

typedef char _check_for_64_bit_pointer_matchingGoInt[sizeof(void*)==64/8 ? 1:-1];

Further details can be found in the Telegram thread started with this message .
Refs:

  • t.me/skycoinsupport/14629
  • t.me/skycoinsupport/14634
  • t.me/skycoinsupport/14697
  • t.me/skycoinsupport/14739
  • t.me/skycoinsupport/14740

Project README

Feature description

Missing project README

Describe the solution you'd like
Project README including:

  • Build status
  • Library sub projects

Implement Circle CI

Feature description

Continuous integration on Circle CI

Is your feature request related to a problem? Please describe.
Running a complex matrix build blocks other projects

Describe the solution you'd like
Run matrix builds on Circle CI . Focus on release since Travis will stil be used for day to day development .

Describe alternatives you've considered
Travis is not an option . There are all sorts of Github Apps for CI .

Additional context
Related to #44 .

Possible implementation

  • Translate .travis.yml rules into CircleCI script format
  • Enable deployment (needs build matrix)

SkyApi make targets

Add new targets:

  • install-deps-skyapi to install cmake, libcurl, ...
  • Remove install-lib-curl after merging rules into install-deps-skyapi
  • install-deps to install deps for both libc and skyapi
  • build-skyapi to build Swagger-based library (depends on install-skyapi-deps)
  • build to trigger both build-libc as well as build-skyapi
  • platform-specific targets that might be needed for all of the above
  • use Travis apt addon to install modern cmake for CI
  • Document make targets in README.md

Enforce code styles with linters

Feature description

Normalize code style for clean PR diffs

Is your feature request related to a problem? Please describe.
After analyzing some PR's the corresponding patches sometimes differ on whitespace only.

Describe the solution you'd like
Diffs could have been smaller if code would have been normalized and rules enforced by a linter

Possible implementation

  • Choose code style = Bitcoin's
  • Find linters able to enforce that style = clang-format
  • Explain in README
  • Implement clang-format in make lint target
  • Run make lint in Travis

Add openapi spec for Skycoin REST API v0.26.0

Feature description
Add openapi spec for Skycoin REST API in version 0.26.0

  • Add in lib/swagger openapi spec
  • Generate client C wrapper for skycoin REST API
  • Mention in CHANGELOG
  • Run basic Swagger tests in Travis

Release Libskycoin 0.25.1

  • Sync 0.25.dev and master branches
  • Create release branch release-0.25.1
  • Update release process docs
  • Skycoin submodule checkout at v0.25.1
  • Update CHANGELOG.md
  • Ensure libc and skyapi docs are up-to-date
  • PR from release-0.25.1 to master
  • Review release PR
  • Tag master with v0.25.1 . This will deploy binaries for different architectures to Github releases .
  • Add docs sync in release procedure (if missing)
  • Move docker/images/circle/ => docker/images/deploy-arm

README should document `make docs`

Feature description

Document make docs

Is your feature request related to a problem? Please describe.
No mention to make docs target in project README .

Describe the solution you'd like

  • List all make targets
  • Add a section about Doxygen comment syntax , per the style guidelines
  • Mention devdocs generation in development section
  • Implement make docs-skyapi and integrate it with make docs

CHANGELOG for v0.25.1

Filter out CHANGELOG entries that do not belong in libskycoin releases . Add blank issue template .

Add some tests to the harware-wallet suite.

Feature description

Make the following tests working for hardware-wallet crypto API

  • TestPubKeyToAddress2
  • TestAddressRoundtrip
  • TestAddressString
  • TestAddressBulk
  • TestDecodeBase58Address
  • TestAddressFromSecKey
  • TestSumSHA256

Describe the solution you'd like
These tests should run from hardware wallet project too.

Additional context
Related to this https://github.com/skycoin/hardware-wallet/issues/84

Possible implementation
Just move them to the *common files and make sure that they are working from hw.

Implement client for the hardware wallet daemon REST API

Feature description

Implement client for the hardware wallet daemon REST API

Is your feature request related to a problem? Please describe.
skycoin/hardware-wallet-daemon#8 adds a swagger.yml spec defining HTTP REST API for interacting with hardware wallets .

Describe the solution you'd like
Generate C client powered by libcurl

Describe alternatives you've considered
There might be other choices but Skycoin nodes REST API is generated with libcurl already.

Possible implementation

  • Grab the YAML OpenAPI spec from github project in make configure
  • Move Skycoin node REST API client to lib/curl/skycoin
  • Generate library at lib/curl/skywallet
  • Remove intermediate output files in make clean

Getting a lot of warnings from the compiler

Describe the bug
There are a lot of warnings from the compiler

Environment information:

  • Platform: Linux 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
  • Go environment: go version go1.11.6 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myuser/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/usr/share/gocode"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build305345991=/tmp/go-build -gno-record-gcc-switches"
  • Compiler info: gcc (Debian 8.3.0-6) 8.3.0

Steps to Reproduce
Steps to reproduce the behavior:

  1. Go to the source project root dir
  2. Run make test-libc

Actual behavior

Getting a lot of warnings:

lib/cgo/tests/check_cipher.crypto.c: In function ‘TestSecKeyFromHex’:
lib/cgo/tests/check_cipher.crypto.c:269:27: warning: passing argument 2 of ‘SKY_cipher_RandByte’ from incompatible pointer type [-Wincompatible-pointer-types]
   SKY_cipher_RandByte(32, &b);
                           ^~
In file included from lib/cgo/tests/check_cipher.crypto.c:5:
cgo-gcc-export-header-prolog:330:62: note: expected ‘coin__UxArray *’ {aka ‘struct <anonymous> *’} but argument is of type ‘GoSlice *’ {aka ‘struct <anonymous> *’}
In file included from lib/cgo/tests/check_cipher.hash.c:4:
lib/cgo/tests/check_cipher.hash.c: In function ‘TestSHA256Hex’:
lib/cgo/tests/check_cipher.hash.c:137:15: warning: implicit declaration of function ‘isGoStringEq’; did you mean ‘isGoSliceEq’? [-Wimplicit-function-declaration]
     ck_assert(isGoStringEq(s, s2));
               ^~~~~~~~~~~~
lib/cgo/tests/check_params.distribution.c: In function ‘TestDistributionAddressArrays’:
lib/cgo/tests/check_params.distribution.c:33:22: warning: assignment to ‘GoString *’ {aka ‘struct <anonymous> *’} from incompatible pointer type ‘GoString_ *’ {aka ‘struct <anonymous> *’} [-Wincompatible-pointer-types]
     for (i = 0, iStr = (GoString_ *)all.data; i < all.len; ++i, ++iStr)
                      ^
lib/cgo/tests/check_params.distribution.c:42:22: warning: assignment to ‘GoString *’ {aka ‘struct <anonymous> *’} from incompatible pointer type ‘GoString_ *’ {aka ‘struct <anonymous> *’} [-Wincompatible-pointer-types]
     for (i = 0, iStr = (GoString_ *)unlocked.data; i < unlocked.len; ++i, ++iStr)
                      ^
lib/cgo/tests/check_params.distribution.c:51:40: warning: assignment to ‘GoString *’ {aka ‘struct <anonymous> *’} from incompatible pointer type ‘GoString_ *’ {aka ‘struct <anonymous> *’} [-Wincompatible-pointer-types]
         for (k = 0, notfound = 1, kStr = (GoString_ *)all.data; notfound && (k < all.len); ++k, ++kStr)
                                        ^
lib/cgo/tests/check_params.distribution.c:58:22: warning: assignment to ‘GoString *’ {aka ‘struct <anonymous> *’} from incompatible pointer type ‘GoString_ *’ {aka ‘struct <anonymous> *’} [-Wincompatible-pointer-types]
     for (i = 0, iStr = (GoString_ *)locked.data; i < locked.len; ++i, ++iStr)
                      ^
lib/cgo/tests/check_params.distribution.c:67:40: warning: assignment to ‘GoString *’ {aka ‘struct <anonymous> *’} from incompatible pointer type ‘GoString_ *’ {aka ‘struct <anonymous> *’} [-Wincompatible-pointer-types]
         for (k = 0, notfound = 1, kStr = (GoString_ *)all.data; notfound && k < all.len; ++k, ++kStr)
                                        ^
lib/cgo/tests/check_params.distribution.c:75:40: warning: assignment to ‘GoString *’ {aka ‘struct <anonymous> *’} from incompatible pointer type ‘GoString_ *’ {aka ‘struct <anonymous> *’} [-Wincompatible-pointer-types]
         for (k = 0, notfound = 1, kStr = (GoString_ *)unlocked.data; notfound && k < unlocked.len; ++k, ++kStr)
.
.
.

Expected behavior
No warning at all

Track all the required changes for autogenerated files

Feature description

After generating some files it required to make some changes, improve/fix.

Is your feature request related to a problem? Please describe.
The generator is not perfect, if you want to customize or fix some this, this changes could be lose after a regeneration.

Describe the solution you'd like
A check list in the README to track the required changes after regenerating files.

Additional context
This is an example of a required change:

Possible implementation
A new section in README and reference it from the "release instructions" section.

Relevant changes so far now:

Document release procedure

Feature description

Release procedure

Describe the solution you'd like
The steps should mention deliverable artifacts. Process should be similar to PySkycoin's .

Bug in TestDecodeBase58Address.

Describe the bug
Invalid use of SKY_base58_Hex2Base58 for binary data.

Environment information:

  • Platform: Any

  • Go environment: Any

  • Compiler info: Any

Steps to Reproduce
Steps to reproduce the behavior: Look at the following lines of code.

1.
2.
3.

Actual behavior
SKY_base58_Hex2Base58 is receiving binary data.

Expected behavior
SKY_base58_Hex2Base58 should receive a hex buffer.

The curl library should be build in release mode for release versions

Describe the bug
The build type is hard coded.

Environment information:

  • Any

Steps to Reproduce
Just look at the code https://github.com/simelo/libskycoin/blob/3cb637dbd49eb3073d18b25205cc58e2519a28c7/lib/curl/CMakeLists.txt#L9

Actual behavior
The curl library is build in debug as unique option.

Expected behavior
Be able to set a predefined value via command line.

Additional context
It's very important to move on this if you regenerate the CMakeLists.txt file.

C API wrapper for the Skycoin node API

Expected Behavior

Access to the Skycoin node REST API implemented in C code .

Actual Behavior

Right now this is only possible using code generated by SWIG , which requires memory handles

Specifications

  • Version: 0.25.0
  • Platform: all
  • Subsystem: all exported API sets

Possible Solution

Generate it from Swagger specs . Beware of CSRF .

  • Use Skycoin node Swagger spec to generate initial C REST API client
  • Add make target to automate generation in ./build
  • Aforementioned target should copy / merge relevant files into source code tree
  • README explaining the process
  • Mention in CHANGELOG
  • Patch the result Swagger-gen REST client to support specifying node address
  • Update package metadata
  • Run basic Swagger tests in Travis
  • Unify test code in case multiple test suites are used after generation
  • Beware of CSRF auth

Add openapi spec for Skycoin REST API v0.27.0

Feature description
Add openapi spec for Skycoin REST API in version 0.27.0

  • Add in lib/swagger openapi spec for this version
  • Generate client C wrapper for skycoin REST API
  • Mention in CHANGELOG
  • Run basic Swagger tests in Travis

Update libc for changes introduced in Skycoin==0.27.0

Feature description

Prepare libc for 0.27.0 release

Is your feature request related to a problem? Please describe.
Skycoin cipher API changed from 0.26.0 to 0.27.0

Additional context
Additional changes in SWIG interfaces might be needed.

Possible implementation

  • Review diff from Skycoin 0.26.0 to Skycoin 0.27.0
  • Take note of functions that were added, changed, or removed
  • Implement changes in lib/cgo
  • Take note of test cases that were added, changed, or removed
  • Implement changes in lib/cgo/tests

Do not initialize GoString's memory in tests

Describe the bug
The functions that receive a GoString as an output parameter initialize the string memory internally

Environment information:

  • Platform: Any

  • Go environment: Any

  • Compiler info: Any

Steps to Reproduce
Steps to reproduce the behavior:

  1. Go to TestAddressString

Actual behavior
Initializing the string's memory in the test.

Expected behavior
The memory will be initialized in SKY_cipher_Address_String, and is required to register this memory in the cleanUp register.

Additional context

  • This change will affect the hardware-wallet tests, please notify the team about the change.
  • Find all the instances of this problem across the project, this is a single example.

C library for STM32 with emgo

Feature description

C library for STM32 MCU

Is your feature request related to a problem? Please describe.
It is not possible to run the library in lib/cgo on MCU .

Describe the solution you'd like

Use emgo to transpile skycoin/skycoin library code to C , then link binaries for STM32 platform

Describe alternatives you've considered
All other alternatives for compiling with go for MCU in the end rely on Firmata, which does not fit in our use case scenario.

Additional context
Ideally this could be used to upgrade the cipher library used in skycoin/hardware-wallet. Priority consists in support for STM32F4 series.

Possible implementation

  • Transpile skycoin/skycoin library code to C using emgo .
  • Link against library for STM32
  • Parameterize the test suite (if needed) so as to test multiple implementations
  • Execute the current test suite by calling the binaries obtained in aforementioned steps

Run tests against hardware-wallet/skycoin-api

Feature description
Refactor tests

Describe the feature

It's desired to run this tests battery against hardware-wallet/skycoin-api, as hardware-wallet/skycoin-api have a subset of the libskycoin features it's required to refactor the tests to run all against libskycoin as it' currently and a test subset against hardware-wallet/skycoin-api.

Describe the solution you'd like
Just refactor tests without changing them.

Describe alternatives you've considered
Modifing the library it's not al alternative as this code is auto generated.

Additional context
https://github.com/skycoin/hardware-wallet/issues/84

Possible implementation
This is just about a refactorization, please do not change any thing

Windows test in travis-ci

Feature description
Test libskycoin against travis-ci for windows

Describe the solution you'd like
Set in travis-ci matrix a build for windows

Possible implementation

  • set travis.yml matrix to use windows

Device build matrix

Feature description

Travis builds for supported Skywire devices .

Describe the solution you'd like

  • hardware : orangepi-plus2, raspberry-pi2, raspberrypi3, beaglebone-black, Tinkerboard, bananapi-m1-plus, odroid-xu4, stem-x86-32
  • distro : debian , fedora , alpine , ubuntu

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Possible implementation
Run tests on Travis with Docker

Modify structure of Swagger specs

Feature description

Add models definitions sections in Swagger spec.

Is your feature request related to a problem? Please describe.
Swagger spec for Skycoin node only defines inline responses. This leads to generation errors , e.g. in qt ( simelo/libskycoin-cpp#1 ) and tizen ( simelo/libskycoin-cpp#2 ) client libraries.

Describe the solution you'd like
All models in models definitions section. Add type field for operation items . Use $ref for array types links for type definition.

Describe alternatives you've considered
The inline response body does not work quite well for generators relying on some language / framework combinations .

Additional context
The structure is inspired on Pet app Swagger spec's models section . This layout works fine with many generators.

Travis doesn't work for check_coin.transactions in some cases

Describe the bug
In some cases, when a run in travis-ci is made, the build fail, you rerun the test and everything is ok.

Steps to Reproduce
Is impossible to reproduce this bug, because sometimes work and other not work.

Actual behavior
Explain the failure modes and effects, everything indicating the existence of the bug.
If applicable, add screenshots to help explain your problem.

This is the test that is failing:

lib/cgo/tests/check_coin.transactions.c:284:F:coin.transaction:TestTransactionUpdateHeader:0: Assertion '!isU8Eq(ptx->InnerHash, nullHash, sizeof(cipher__SHA256))' failed

Distribute a version of the curl library for developers

Feature description
Distribute a version of the curl library for developers

Is your feature request related to a problem? Please describe.
May be desired for some develover be able to get a ready to use libcurl-dev.

Describe the solution you'd like
Create instructions to install the required files like:

Additional context
Do not miss to create a uninstall instruction.

Describe alternatives you've considered
Just use a install rule from command line or make part of the release some installers.

Possible implementation
As libcurl is using cmake you can consider using cpack, with this tool you can create script based installers, debian, windows, osx...

Bug in test sort transactions.

Describe the bug
Bug in tests after fixing isSHA256Eq

Environment information:

  • Platform: Linux 4.19.0-1-amd64 x86_64
  • Go environment:
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/adacosta/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/usr/share/gocode"
GOPROXY=""
GORACE=""
GOROOT="/opt/go"
GOTMPDIR=""
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build114971256=/tmp/go-build -gno-record-gcc-switches"
  • Compiler info:
gcc (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Steps to Reproduce
Steps to reproduce the behavior:

  1. Fix this error.
  2. make test-libc
  3. See error

Actual behavior
Tests fail

lib/cgo/tests/check_coin.transactions.c:983:F:coin.transaction:TestSortTransactions:0: Failed SortTransactions test "invalid fee multiplication is capped"

Expected behavior
Tests should pass

Additional context
#34

Possible implementation:

PD: The "Possible implementation:" just try to make you follow some possible relevant paths than can be relevant in order to find the bug.

Include certain missing skycoin cipher lib test vectors

Feature description

Describe the feature
The tests are possibly missing some important test vectors for the cipher libs

This is the test case that must be imported:
https://github.com/skycoin/skycoin/blob/develop/src/cipher/secp256k1-go/secp256_test.go#L654-L738

Is your feature request related to a problem? Please describe.
Testing/sanity checking

Describe the solution you'd like
Add the test vectors to the test suite

Describe alternatives you've considered
No alternatives

Additional context
I've discovered some historically important test vectors in underlying secp256k1 libraries that may not have been included in the libskycoin test suite because it is in a deeper library than top-level cipher. The initial discussion of them is here piotrnar/gocoin#15

Possible implementation
Preliminary ideas to get this done.
If you have all details in mind then provide a checklist

  • Translate the test case
  • Confirm that they pass. If they don't pass, then there is a problem with the libskycoin cipher library

Tests for the C REST API wrappers

Expected Behavior

Same tests run for SKY_api_* functions shall be used for C API wrappers .

Actual Behavior

... see #3

Specifications

  • Version: 0.25.0
  • Platform: all
  • Subsystem: all exported API sets

Possible Solution

Reuse existing API test code and parameterize the invocation .

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.