4

This question already has an answer here:

My app connects and mine the same blokchain on every instance, it uses the same genesis.json and network ids.

Genesis: https://github.com/AugustoL/OpenContent/blob/master/genesis.json

Web3 service that connects using the same network id: https://github.com/AugustoL/OpenContent/blob/master/js/services/web3.js

When I run it on two different computers the existent blockchain isnt recognized. SO it starts mining two different blockchains with the same genesis and network id :S

What is the error? What im missing? I have been reading a lot and its supposed to work.

marked as duplicate by niksmac, Community Apr 17 '16 at 16:50

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4

The Reason

The reason why your two geth instances on the two different computers cannot find each other is that they do not know where to start searching for each other.

Note: I've shortened the node public key for easier reading in this answer. For example,
"a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c" has been shortened to "a979....163c". You will have to use the full public keys when setting up your network.

In the mainnet public blockchain, each peer upon starting up will try to connect to the "bootnodes" to obtain an initial list of peers it can connect to. The address of these bootnodes are hardcoded into eth/backend.go lines 71-78 as shown below:

defaultBootNodes = []*discover.Node{
    // ETH/DEV Go Bootnodes
    discover.MustParseNode("enode://a979....163c@52.16.188.185:30303"), // IE
    discover.MustParseNode("enode://de47....c786@54.94.239.50:30303"),  // BR
    discover.MustParseNode("enode://1118....5082@52.74.57.123:30303"),  // SG
    // ETH/DEV cpp-ethereum (poc-9.ethdev.com)
    discover.MustParseNode("enode://979b....37f9@5.1.83.226:30303"),
}

Once a node connects to the bootnode, it will get a list of addresses for potential peers to connect to, and it will try to connect to these peers.

There is no such starting point in your private network.



The Solution

On your private network, your geth instances will not know where to start searching for each other and you will have to give it some hints. There are three ways you can do this - using the --bootnodes command line parameter, adding a static-nodes.json to your data directory, or adding a trusted-nodes.json to your data directory.

Run geth on each of your computers, and type admin.nodeInfo into the command line:

> admin.nodeInfo
{
  enode: "enode://d9d9....30d9@[::]:30301?discport=0",
  id: "d9d9....30d9",
  ip: "::",
  listenAddr: "[::]:30301",
  name: "Geth/v1.3.6/linux/go1.5.1",
  ports: {
    discovery: 0,
    listener: 30301
  },
  ...
}

What you will have to do is to get the enode information for both your computers. Replace the [::] in the enode information with the IP address of your two computers and remove the ?discport=0 if it is present. Your enode information for each computer should then look like:

  • Computer 1 enode: enode://d9d9....30d9@192.168.1.152:30303
  • Computer 2 enode: enode://1212....3434@192.168.1.253:30303


Solution 1 - The --bootnodes Solution

This first --bootnodes solution will require you to specify the bootnode of one computer's geth instance to the other computer's geth instance. So on Computer 1, you start up geth adding the following parameter:

--bootnodes "enode://1212....3434@192.168.1.253:30303"


Solution 2 - The static-nodes.json Solution

This second solution is to create the file static-nodes.json in your --datadir, so in your case, the file name and path should be ./blockchain/static-nodes.json. On computer #1, this file should contain the enode information of computer #2, and vice versa. Alternatively, just create one static-nodes.json with the enode information of both computers #1 and #2, and copy this static-nodes.json to the --datadir of both computers. The contents of this file should look like:

[
  "enode://d9d9....30d9@192.168.1.152:30303",
  "enode://1212....3434@192.168.1.253:30303"
]


Solution 3 - The trusted-nodes.json Solution

Same as solution #2, but use the file name trusted-nodes.json instead of static-nodes.json. The difference here is that trusted nodes don't add to count of peer nodes when the --maxpeers limit is reached.



Use --maxpeers And Don't Use --nodiscover

You may have to specify a non-zero --maxpeers to get this working, for example, use the parameter:

geth ... --maxpeers 2 ...

And don't use --nodiscover in your geth command line, as this will turn off peer discovery.



Related Questions

Here are some related questions that may help you resolve your connection issues:

  • Nicely explained – niksmac Apr 17 '16 at 13:29
  • You should consider closing the question as duplicate when you find similarity, there is no point in answering a question which is already answered. And the other question is answered by you as well +1 for that. – niksmac Apr 17 '16 at 14:59
  • 1
    This answer is clearer as I now understand the issues a bit better than when I answered the previous question. Should I mark the previous two questions as duplicates of this one? – The Officious BokkyPooBah Apr 17 '16 at 15:08
  • Not necessary, i have marked this as duplicate, it will get closed soon. Btw, you're doing a great job here mate. 2K+ reps in 2 week; impressive. – niksmac Apr 17 '16 at 15:10
  • 1
    Thanks. I'm doing my research on the Ethereum blockchain and smart contracts, and the questions that gets asked here helps me to explore the ecosystem. I'm documenting some of these issues so I can reference it in the future. And this blockchain is like Lego Mindstorm to me, compared to regular programming being regular Lego. Lots of pieces to explore and see how they fit together. – The Officious BokkyPooBah Apr 17 '16 at 15:14

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