Hardware Wallet Daemon
The hardware walllet daemon provides an HTTP API to interface with the wallets supported by skycoin. It uses the go bindings provided by the hardware wallet go library.
Table of contents
- API Documentation
- Development guidelines
- Responsible Disclosure
Hardware Daemon supports go1.10+.
Go 1.10+ Installation and Setup
Run Daemon from the command line
The API has two modes:
- USB: Communicate with the hardware wallet.
- EMULATOR: Communicate with the emulator.
You can use the
-daemon-mode flag to enable the required mode or use the
$ cd $GOPATH/src/github.com/skycoin/hardware-wallet-daemon $ make run-usb
$ cd $GOPATH/src/github.com/skycoin/hardware-wallet-daemon $ make run-emulator
Show Daemon options
$ cd $GOPATH/src/github.com/skycoin/hardware-wallet-daemon $ make run-help
Code added in this repository should comply to development guidelines documented in Skycoin wiki.
The project has two branches:
developis the default branch and will always have the latest code.
masterwill always be equal to the current stable release on the website, and should correspond with the latest release tag.
Hardware wallet daemon uses swagger for the API specification. It follows OpenAPI 2.0.
The go client has been automatically generated using go-swagger and the swagger specification.
Note: The go client uses a slightly modified response template.
The swagger specification can be used to generate more libraries in the required language.
Library test suite can be run by running the following command
$ make test
Running Integration Tests
There are integration tests for the HTTP API interfaces. They have two run modes, "wallet" and "emulator".
emulator integration tests are run only when an emulator is running.
wallet integration tests are run only when a physical skycoin hardware wallet is connected.
Emulator Integration Tests
$ make integration-test-emulator
$ ./ci-scripts/integration-test.sh -m emulator -v
-m emulator option, runs emulator integration tests.
-v option, shows verbose logs.
Wallet Integration Tests
$ make integration-test-wallet
$ ./ci-scripts/integration-test.sh -m wallet -v
-m wallet option, runs wallet integration tests.
-v option, shows verbose logs.
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
TestEmulatorFeatures and see the result, we can run:
$ ./ci-scripts/integration-test.sh -m emulator -v -r TestEmulatorFeatures
Update golden files in integration testdata
Golden files are expected data responses from the HTTP API saved to disk. When some of the tests are run, their output is compared to the golden files.
To update golden files, use the provided
$ make update-golden-files
We can also update a specific test case's golden file with the
$ ./ci-scripts/integration-test.sh -m emulator -v -u -r TestEmulatorFeatures
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
To merge coverage from all tests into a single HTML file for viewing:
$ make check $ make merge-coverage
coverage/all-coverage.html in the browser.
.go source files should be formatted
goimports. You can do this with:
$ make format
$ make install-linters
$ make lint
A full CPU profile of the program from start to finish can be obtained by running the node with the
Once the node terminates, a profile file is written to
-profile-cpu-file (defaults to
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
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/.
Dependencies are managed with dep.
go get -u github.com/golang/dep/cmd/dep
dep vendors all dependencies into the repo.
If you change the dependencies, you should update them as needed with
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.
Initialize all dependencies:
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
Update the version
- If the
masterbranch has commits that are not in
develop(e.g. due to a hotfix applied to
develop(and fix any build or test failures)
- Switch to a new release branch named
release-X.Y.Zfor preparing the release.
make buildto make sure that the code base is up to date
CHANGELOG.md: move the "unreleased" changes to the version and add the date.
- Follow the steps in pre-release testing
- Make a PR merging the release branch into
- Review the PR and merge it
- Tag the
masterbranch with the version number. Version tags start with
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".
- Tag the changeset of the
protobsubmodule checkout with the same version number as above.
- Release builds are created and uploaded by travis. To do it manually, checkout the master branch and follow the create release builds instructions.
developbranch and bump
Performs these actions before releasing:
make check(make sure that all the integration tests are passing)
Security flaws in the source of any software provided by skycoin or infrastructure can be sent to firstname.lastname@example.org. Bounties are available for accepted critical bug reports.
PGP Key for signing:
-----BEGIN PGP PUBLIC KEY BLOCK----- mDMEWaj46RYJKwYBBAHaRw8BAQdApB44Kgde4Kiax3M9Ta+QbzKQQPoUHYP51fhN 1XTSbRi0I0daLUMgU0tZQ09JTiA8dG9rZW5AcHJvdG9ubWFpbC5jb20+iJYEExYK AD4CGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AWIQQQpyK3by/+e9I4AiJYAWMb 0nx4dAUCWq/TNwUJCmzbzgAKCRBYAWMb0nx4dKzqAP4tKJIk1vV2bO60nYdEuFB8 FAgb5ITlkj9PyoXcunETVAEAhigo4miyE/nmE9JT3Q/ZAB40YXS6w3hWSl3YOF1P VQq4OARZqPjpEgorBgEEAZdVAQUBAQdAa8NkEMxo0dr2x9PlNjTZ6/gGwhaf5OEG t2sLnPtYxlcDAQgHiH4EGBYKACYCGwwWIQQQpyK3by/+e9I4AiJYAWMb0nx4dAUC Wq/TTQUJCmzb5AAKCRBYAWMb0nx4dFPAAQD7otGsKbV70UopH+Xdq0CDTzWRbaGw FAoZLIZRcFv8zwD/Z3i9NjKJ8+LS5oc8rn8yNx8xRS+8iXKQq55bDmz7Igw= =5fwW -----END PGP PUBLIC KEY BLOCK-----
Key ID: 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 SKYCOIN <email@example.com> sub cv25519 2017-09-01 [E] [expires: 2023-03-18]
Keybase.io account: https://keybase.io/gzc