3

I am trying to create a non-local private network with go-ethereum running on docker containers hosted in different Virtual Machines. I am having a hard time trying to make the nodes recognize each other. I wonder which is the best strategy to add peers now that bootnode is not working properly (Open Issue #3703). I have followed many aspects of the Vertigobr project.

Knowing that --nodiscover should be enabled to avoid connecting with nodes external to the private network, these are my questions:

  1. Is --nat extip:<VM_EXT_IP> the most convenient nat configuration?
  2. Is only one node (a main one) in possession of the static-nodes.json file and it automatically links itself to the nodes in the file?
  3. According to "Connecting to the network" in the Ethereum's documentation admin.addPeer("enodeURL") only adds nodes temporarily. Does that mean that I have to keep track of my list of nodes in a database, for example, regenerate the static-nodes.json when a new node is created, and restart my "main" node to reload this file? Is there an easier way?
Improve this question

1 Answer 1

Reset to default
2

Prepare your nodekey for each node in advance. It is just a 512-bit random number. Then store them somewhere, along with the public ECDSA keys derived from there.

The public keys are the components of the enode you need to establish connections using the --bootnode command option, as well as the admin.addPeer() function in console.

Forming the enode is as easy as getting public keys, IPs and port, for example

enode://844c9c9e926a96e67fae7124bf6fcb6ecf37d121e2d3031db4b7d7bdd1388d9fc33c96c70535c65fcf34d8a4258fd40a9a7e2c24ac92bb152bd0261464b845d1@192.168.1.1:9915

Here is a (non-safe as it doesn't use /dev/random) one-liner to get your nodekey

perl -e '@c=("a".."f",0..9);$p.=$c[rand(scalar @c)] for 1..64; print "$p\n"'

And Here is a quick utility in go using the geth library to get your public key

https://gist.github.com/hermanjunge/8d0998f1fb2fd87870b57c63fe1f46c8

Improve this answer
3
  • 1
    Hi Herman, thank you for your quick reply! I guess the key file is only for those nodes intended as bootnodes and I could have only some that are being referenced by all other nodes on the blockchain. Well I was able to run your code and I get two keys: 246592eacb950b1a61805dddbd1faa92161befa98d04de52b45f78a8b4f6c0db and 311feee911639c757c305e07675793eb2d5cb3c6011764ad50d1e9c9b5a07ff9e6f4a594f3938552314434be45560a8a3e36850224c288fd8c8a6201103df05c the long one is the enode public key, right? is the short one the nodekey (ECDSA key) ?
    – Betty Sanchez
    Feb 23, 2017 at 22:11
  • 1
    Yes @betty, so by starting your node with the flag --nodekeyhex 246592eacb950b1a61805dddbd1faa92161befa98d04de52b45f78a8b4f6‌ , you ensure that you always have the same enode value.
    – Herman Junge
    Feb 24, 2017 at 1:24
  • 1
    Thanks :) I also managed to run the bootnode code with go get github.com/ethereum/go-ethereum/cmd/bootnode and then running go run main.go --genkey "/some/dir/bootnode.key" where main.go is the main go file of the downloaded bootnode folder.
    – Betty Sanchez
    Feb 24, 2017 at 10:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.