Signer Service
The signer-service is a version of the signer that runs as a JRPC HTTP Service, exposing the functionality of the signer as a collection of API endpoints
Running the Signer Service
The first thing to do is to start the signer service. This can be done by getting the signer-service binary from the release package of the latest version of full service.
All available parameters can be set as Environment Variables. Parameters names are converted to SCREAMING_SNAKE_CASE and are prefixed with MC_SIGNER. See signer-service --help for the full list. CLI arguments take precedence over Environment Variables.
| Parameter Name | Default |
|---|---|
| 127.0.0.1 |
| 9092 |
The four API endpoints can be reached at listen_host:listen_port/api
Creating an Account
The first thing you will most likely want to do is to create an account and store the resulting account secrets somewhere safe!
To create an account call the create account endpoint and store the resulting mnemonic safely. The account info can be used to import this account into full service as a view only account using the import view only account
Getting an existing accounts info
If you already have an account you would like to use, you can call the get account endpoint
Create and Sign an Unsigned Transaction
(online machine) Start by calling the build_unsigned_transaction endpoint for the view only account in Full Service. This will generate a result which will need to be saved and transferred to the machine that has the signer-service.
(offline machine) From the offline machine, call the sign transaction endpoint of the signer service, which takes in the mnemonic and the unsigned tx proposal. The result of this will be a signed transaction proposal
(offline --> online machine) Copy the resulting transaction proposal back to your online machine.
(online machine) Submit the transaction proposal with the submit_transaction endpoint. This will submit a transaction to the MobileCoin network and update the relevant TXOs for the view only account that was used to sign the transaction.build_unsigned_transaction
A few things to note:
If you do not include a tombstone block with the request to build the unsigned transaction, it will default to 10 blocks in the future of where the current network height is. This may or may not give you enough time to successfully sign the transaction and submit it, depending on how long it takes to transfer the signing material and how fast the network is moving. Any future tombstone block may be selected for a transaction, but consensus only accepts ones that are AT MAX 100 blocks from the current block index.
If you include recipients that are FOG enabled addresses, the tombstone block height will be locked at 10 blocks in the future because of requirements from FOG. There is currently no workaround for this, but the limit may be increased to allow more time to sign transactions.
Syncing an Account
Syncing an account is not typically necessary, but will be required in a few different situations
You have re-imported an already existing account that has MOB on it
You submit a transaction through a different service or instance of Full Service
To start a sync, you must first start from Full Service with the command create_view_only_account_sync_request
The result in the response from this call will need to be saved to a json file and sent to the offline machine.
From the offline machine, call the sync txos endpoint of the signer-serice, which takes in the mnemonic and the list of unsynced txos.
The result of this will be a list of synced txos. This will add any missing KeyImages for txos and Subaddresses required to decode them to the view only account.
You must take the synced txos back to the online machine and call the sync view only account endpoint from full service
Last updated