Correct Permissions Setup for Nodes

Question

Hi

I'm in the process of locking down a set of multichain nodes.  The approach I'm taking is to set anyone-can-connect to false and then on the fist node that comes up to grant connect permissions to a set of private keys that I know.

I then start each peer using one of these private keys as below.  All this works well and everything is connecting.

multichaind test-chain@multichain-main:9579 -datadir=/var/lib/multichain/ -initprivkey={ASSIGNED-PRIVATE-KEY} -rpcthreads=16Hi -debug=mcapi -daemon
| Retrieving blockchain parameters from the seed node multichain-main:9579 ...
....
....
....
2017-09-17 18:28:46 mchn: Sending minimal parameter set to 172.22.0.2:9579
2017-09-17 18:28:46 mchn: Cannot find address having connect permission, trying default key
2017-09-17 18:28:46 receive version message: /MultiChain:0.1.0.9/: version 70002, blocks=3, us=172.22.0.3:45028, peer=3
2017-09-17 18:28:46 Added time data, samples 2, offset +0 (+0 minutes)
2017-09-17 18:28:46 mchn: Connection from 1LUTwbje67P8h2oENVDFs7kchCpUvuytTy received on peer=3 in verack
2017-09-17 18:28:46 mchn: Cannot find address having connect permission, trying default key
2017-09-17 18:28:46 mchn: Connection from 1LUTwbje67P8h2oENVDFs7kchCpUvuytTy received on peer=3 in verackack (172.22.0.2:9579)
2017-09-17 18:28:46 mchn: Parameter set from peer=3 verified

If you notice in the logs the joining node seems to look for an address with connect permissions first before falling back to use the private key.  This doesn't appear to be an issue, but is this expected behaviour and should I be using addresses rather than keys to manage my permissions.

One other question, I was going to also assign mining as a permission to a number of these keys but I remember an issue in an earlier version of multichain whereby new nodes started mining before they had fully caught up and where creating forks in the chain and constantly rolling back until they were finally in sync.  Is this still an issue in the latest versions.....I'm not seeing it but wanted to check in case the correct process is to start with connect, wait until the nodes have caught up and then assign mining?

Cheers

Marty

Answer 1

First, it's the expected behavior to look for a key with connect permissions first – when a node first joins it does not know which addresses have connect permissions, so it just uses its default (first) key.

We'll answer the second question separately.

Comments

Mining issue has been resolved. You can grant mining permission before node is in sync.

Node will start mining several seconds after initial download is completed.

---

Thanks

One other part to this I mean't to ask previously.  It appears I can't start the first node in the chain using -initprvkey.  I get an error reporting an invalid genesis block so I end up with a random admin key on the first node.  

Is this expected behaviour for -initprvkey?

---

Currently it is impossible to specify -initprivkey for the first node.

The error you get is "Cannot set initial private key: Invalid private key encoding", because you have to specify private key encoded for this specific blockchain and
blockchain is not created at this moment.

As workaround, you can launch chain with random admin key, import new private key, grant all permissions to new address and revoke all permissions from automatic address. This will have the same effect.

---

Thanks Michael.....

That was my plan B.  Just wanted to check incase I was just being stupid :)