Skip to content
Standalone work server for nano-pow (work in progress, currently returns mock data)
C++ JavaScript Shell HTML CMake CSS
Branch: master
Clone or download
argakiig Merge pull request #11 from nanocurrency/fix_ci
enable standalone to allow package target
Latest commit 32e7826 Oct 9, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
ci update README.md Oct 9, 2019
deps Removed nano_pow submodule Oct 7, 2019
public Print server version on startup, make it available via REST Sep 28, 2019
src Remove unused type aliases Oct 9, 2019
util add generated sample config Oct 9, 2019
.clang-format.base
.gitignore add generated sample config Oct 9, 2019
.gitmodules Removed nano_pow submodule Oct 7, 2019
.travis.yml enable standalone to allow package target Oct 9, 2019
CMakeLists.txt if you are installing you will want the sample either way. Oct 9, 2019
LICENSE Nano PoW Server Sep 22, 2019
README.md

README.md

Nano PoW Server

Build Status

This project is a standalone work server for nano-pow, the proof-of-work algorithm used by Nano.

Installation

CMake is used for building. C++14 and Boost 1.67 or later is required. Other dependencies are managed with git submodules:

git clone --recursive https://github.com/nanocurrency/nano-pow-server.git
cmake .
make

On Windows, some flags may need to be passed to cmake:

-Dgtest_force_shared_crt=on when building tests

-A "x64" to pick the correct Boost libraries

Validate installation

./nano_pow_server --config server.log_to_stderr=true
curl localhost:8076/api/v1/ping
{"success": "true"}

Configuration

Defaults can be overriden by using a TOML config file, or by passing options through the --config command line option.

Note: One or more CPU or GPU work devices must be configured.

Configuration file

To override defaults using a config file, create a file called nano-pow-server.toml and add the required keys and values under their respective TOML table. The file name can optionally be specified with the --config_path option (if not specified, the working directory is searched)

A documented configuration file can be created with the --generate_config command

A documented configuration file is created in the build root when the nano_pow_server target is created

A documented configuration file is created with the package target

While configuring devices is more convenient in the TOML file, a single device can be configured via the command line using something like --config device.type=\"cpu\" --config device.threads=4

Multiple devices can be added by placing several [[device]] entries in the config file.

API

The API is available as REST requests, and all the POST requests are available as through WebSockets as well, in which case clients must provide a correlation id to match up the response. The WebSocket path is ws://localhost:8076/websocket.

Error responses

All requests may fail with a response containing an "error" attribute. Example:

{
    "error": "Hash not found in work queue"
}

Generate work

Generates proof of work given a hash and difficulty/multiplier.

URL : /api/v1/work or / (deprecated)

Method : POST

Request

Note: The id is only required for WebSocket requests. This can be any string.

{
	"action": "work_generate",
	"hash": "718CC2121C3E641059BC1C2CFC45666C99E8AE922F7A807B7D07B62C995D79E2",
	"difficulty": "2000000000000000",
	"multiplier": "1.0",
	"id": "73018"
}

An optional "priority" attribute can be set to move the work request ahead in the queue. By default, all requests have priority 0. Note that server.allow_prioritization must be set to true for the priority attribute to be considered.

Response
{
	"work": "2BF29EF00786A6BC",
	"difficulty": "201CD58F11000000",
	"multiplier": "1.394647",
	"id": "73018"
}

Validate work

Validates work given a hash and difficulty/multiplier.

URL : /api/v1/work or / (deprecated)

Method : POST

Request

Note: The id is only required for WebSocket requests. This can be any string.

{
	"action": "work_validate",
	"hash": "718CC2121C3E641059BC1C2CFC45666C99E8AE922F7A807B7D07B62C995D79E2",
	"work": "2BF29EF00786A6BC",
	"difficulty": "2000000000000000",
	"multiplier": "1.0",
	"id": "73019"
}
Response
{
	"work": "2BF29EF00786A6BC",
	"difficulty": "201CD58F11000000",
	"multiplier": "1.394647",
	"id": "73019"
}

Cancel work request

URL : /api/v1/work or / (deprecated)

Method : POST

Request

Note: The id is only required for WebSocket requests. This can be any string.

{
	"action": "work_cancel",
	"hash": "718CC2121C3E641059BC1C2CFC45666C99E8AE922F7A807B7D07B62C995D79E2",
	"id": "73020"
}
Response
{
	"status": "cancelled",
	"id": "73020"
}

An informational error response is sent if the hash is not found.

Ping

This can be used by clients and tools to check if the work server is available.

URL : /api/v1/ping

Method : GET

Response
{
  "success": "true",
}

Version

This can be used by clients and tools to receive the server version number.

URL : /api/v1/version

Method : GET

Response
{
  "version": "1.0.0",
}

Queue

Experimental: This endpoint may change or be removed in future versions without further notice

This can be used by clients and tools to display the current work queue (pending, in progress and completed)

URL : /api/v1/work/queue

Method : GET

Response

The response contains information about pending, in progress and completed work requests in json format. The detailed structure is currently not specified.

Queue clear

Experimental: This endpoint may change or be removed in future versions without further notice

By sending a DELETE request to the queue endpoint, the pending queue is cleared. This does not affect work requests already being processed.

This request requires server.allow_control to be set to true in the config.

URL : /api/v1/work/queue

Method : DELETE

Response
{
  "success": "true",
}

An error is returned if control requests are not allowed.

Stop

This can be used by clients and tools to stop the work server process.

This request requires server.allow_control to be set to true in the config.

URL : /api/v1/stop

Method : GET

Response
{
  "success": "true",
}

An error is returned if control requests are not allowed.

Web UI

Any administrative UI using the above REST/WebSocket features can be added by placing HTML, Javascript and other files in a subdirectory called public (this can be changed with the admin.path config setting.) By default, only loopback requests are allowed; remote access can be granted by setting the admin.allow_remote config option to true.

A sample UI is included in the distribution, available at http://localhost:8076

Security

Authentication and access control is beyond the scope of the Nano PoW Server. To expose functionality, consider using a reverse proxy; this can be used to control access to the REST, WebSocket and admin interfaces.

A setup with certificates (enabling https:// and wss://) can be done fairly easy with Let's Encrypt and nginx. Here are some sample resources:

https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-18-04

https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-with-ssl-as-a-reverse-proxy-for-jenkins

A sample reverse proxy setup is available here:

https://gist.github.com/cryptocode/c7d63216902615a06fea6e5c948960d2

You can’t perform that action at this time.