Guardnode daemon¶
Guardnode daemon responding to client chain coordinator challenges and generating alerts for misbehavior on the chain.
Running¶
Find instructions for running the guardnode daemon in the Guardnode repo.
Viewing and Spending locked outputs¶
When a successful bid is made your guardnode will lock up your CBT for the duration of the service period. These outputs are not recognised by some RPCs such as getBalance. To include your locked funds in a call to getBalance include all addresses and watch only addresses with the following arguments:
getbalance "*" 0 true
These funds can be respent but only using RPCs that allow watch only addresses in their coin selection, therefore RPCs such as sendanytoaddress will not recognise the previously locked funds. Using createanytoaddress with the allowwatchonly argument will include previously locked outputs in its inputs, e.g:
createanytoaddress "$ADDR" $AMOUNT true true 1 true
Then sign and send the transaction using signrawtransaction and sendrawtransaction.
Demo¶
The following is a demo of the Guardnode in action responding to a challenge. First run the demo script which generates a request and two bids for that request on a mock service chain.
Next, in a separate terminal window execute the following script and watch the guardnode recognise the request and submit a bid.
./run_guardnode --rpcuser user1 --rpcpass password1 --rpchost 127.0.0.1:5555 --servicerpcuser user1 --servicerpcpass password1 --servicerpchost 127.0.0.1:5555 --nodelogfile $HOME/co-client-dir/ocean_test/debug.log --challengehost 127.0.0.1:5555 --bidlimit 50 --serviceblocktime 5
We can now mine some blocks to bring our request into its service period. Then we can send a CHALLENGE asset transaction and watch the guardnode react. In the first terminal window execute:
alias ocn='/$HOME/ocean/src/ocean-cli -datadir=$HOME/co-client-dir'
ocn generate 5
ocn sendtoaddress $(ocn getnewaddress) 1 "" "" false "CHALLENGE"
ocn generate 1
As there is no connection to a coordinator we get an error message but the would-be response message is displayed. Guardnode sends their bid txid to identify themselves, the challenge tx hash and a signature to coordinator as a response to the challenge and thus prove their active watching of the client chain. The coordinator uses this to determine whether to send payment to each guardnode at the end of the service period depending on whether they responded correctly to each challenge or not.
Further guardnode functionality such as invalid block and consensus anomaly detection will be implemented soon.
Demo with coordinator¶
We can repeat the same demo with connection to a coordinator and observe the process of coordinator generating challenges, guardnodes sending responses and coordinator verifying them.
Run a coordinator daemon and execute the following:
./run_guardnode --rpcuser user1 --rpcpass password1 --rpchost 127.0.0.1:5555 --servicerpcuser user1 --servicerpcpass password1 --servicerpchost 127.0.0.1:5555 --nodelogfile $HOME/co-client-dir/ocean_test/debug.log --challengehost 127.0.0.1:5555 --bidlimit 50 --serviceblocktime 5
Configuration¶
The full list of arguments are given below:
| Argument | Decription |
|---|---|
| –rpchost | Client chain RPC host address |
| –rpcuser | Client chain RPC username |
| –rpcpass | Client chain RPC password |
| –servicerpchost | Service chain RPC host address |
| –servicerpcuser | Service chain RPC username |
| –servicerpcpass | Service chain RPC password |
| –serviceblocktime | Service chain block time |
| –nodelogfile | Client chain log file destination |
| –bidpubkey | (Optional) Pre-made bid public key |
| –bidlimit | Upper limit in bid size |
| –challengehost | Challenger host address |
| –uniquebidpubkeys | Flag to indicate new bid pubkey generation for each bid |