From What is the Difference Between 127.0.0.1 and 0.0.0.0?:
What is the Difference Between 127.0.0.1 and 0.0.0.0?
- 127.0.0.1 is the loopback address (also known as localhost).
- 0.0.0.0 is a non-routable meta-address used to designate an invalid, unknown, or non-applicable target (a ‘no particular address’ place holder).
In the context of a route entry, it usually means the default route.
In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.
What you want to do is to find the IP address of the machines that is non-127.0.0.1 which will look like on OS/X (and Linux):
Iota:~ bok$ ifconfig -a
...
inet 127.0.0.1 netmask 0xff000000
...
inet 192.168.0.11 netmask 0xffffff00 broadcast 192.168.0.255
On Windows, the equivalent command is ipconfig /all.
The 192.168.0.11 address is the one you want to use in your enode string as this is the IP address of the machine that is contactable by your the other computers on your network.
You will then need to add your peer using a command like:
> admin.addPeer("enode://5d272e8bee6d29dfff6313999a4a2c3d8109ae6f3eb103480f4536c0542549b9fa12a8d8ae5ebee9c4db55cab553693b04eedbc9b29f35bbc0af1956231b42b4@192.168.0.11:30303")
Worked Example
Here's a step-by-step example of running 2 miners on the same computer under OS/X, with the miners communicating with each other. You should be able to replicate this in Windows and Linux. You should also be able to replicate this on more than 2 nodes, and on separate computers.
Update Oct 31 2016 00:00:56 UTC You may encounter a problem with the DAG generation as both miners will try to create the DAG at the same time in the same file. On OS/X (and Linux), the DAG file is stored in $HOME/.ethash. This is the same problem as described in Private chain, two geth miner on the same machine, second miner throws "panic: ethash_full_new IO or memory error" . The workaround is to start the second miner after the first miner has completed creating the DAG - when the initial DAG needs to be created. A new DAG will need to be created periodically and this may cause one of your miners to crash.
The details:
geth version reports 1.4.18-stable-c72f5459- This example was created in the directory
/tmp/Test2Miners, with miner #1's data directory being /tmp/Test2Miners/miner1data and miner #2's data directory being /tmp/Test2Miners/miner2data.
I created the file /tmp/Test2Miners/genesis.json with the following contents:
{
"config": {
"homesteadBlock": 10
},
"nonce": "0",
"difficulty": "0x400",
"mixhash": "0x00000000000000000000000000000000000000647572616c65787365646c6578",
"coinbase": "0x0000000000000000000000000000000000000000",
"timestamp": "0x00",
"parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"extraData": "0x",
"gasLimit": "0x3B4A1B44",
"alloc": {}
}
I created /tmp/Test2Miners/testpassword with the following contents:
aaaargh
I created /tmp/Test2Miners/initMiner1 with the following contents, then set the executable bit using the command chmod 700 /tmp/Test2Miners/initMiner1:
#!/bin/sh
geth --datadir /tmp/Test2Miners/miner1data init /tmp/Test2Miners/genesis.json
geth --datadir /tmp/Test2Miners/miner1data --password /tmp/Test2Miners/testpassword account new
I created /tmp/Test2Miners/initMiner2 with the following contents, then set the executable bit using the command chmod 700 /tmp/Test2Miners/initMiner2:
#!/bin/sh
geth --datadir /tmp/Test2Miners/miner2data init /tmp/Test2Miners/genesis.json
geth --datadir /tmp/Test2Miners/miner2data --password /tmp/Test2Miners/testpassword account new
I created /tmp/Test2Miners/runMiner1 with the following contents, then set the executable bit using the command chmod 700 /tmp/Test2Miners/runMiner1:
#!/bin/sh
geth --datadir /tmp/Test2Miners/miner1data --unlock 0 --password /tmp/Test2Miners/testpassword --mine --minerthreads 1 --port 30301 console
I created /tmp/Test2Miners/runMiner2 with the following contents, then set the executable bit using the command chmod 700 /tmp/Test2Miners/runMiner2:
#!/bin/sh
geth --datadir /tmp/Test2Miners/miner2data --unlock 0 --password /tmp/Test2Miners/testpassword --mine --minerthreads 1 --port 30302 console
I initialised the data directories and created the first account (coinbase) for both miners using the command:
/tmp/Test2Miners/initMiner1
/tmp/Test2Miners/initMiner2
In terminal window #1, I started miner #1 using the following command. I've included the enode information printed on the console, which can also be determined by using the admin.nodeInfo command:
/tmp/Test2Miners/runMiner1
...
enode://dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d@[::]:30301
In terminal window #2, I started miner #2 using the command:
/tmp/Test2Miners/runMiner2
...
enode://b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436@[::]:30302
I've replaced the [::] in the enode strings with the local IP address, so my admin.addPeer(...) commands would look like:
admin.addPeer("enode://dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d@192.168.1.11:30301")
and
admin.addPeer("enode://b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436@192.168.1.11:30302")
I pasted the admin.addPeer(...) with the enode string from the miner #1 into the miner#2 console.
In the miner #1 console:
> admin.peers
[{
caps: ["eth/62", "eth/63"],
id: "b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436",
name: "Geth/v1.4.18-stable-c72f5459/darwin/go1.7.1",
network: {
localAddress: "192.168.1.11:30301",
remoteAddress: "192.168.1.11:62922"
},
protocols: {
eth: {
difficulty: 152346260,
head: "0x8296dbd46fe12cef1415c27cb21f2ad6d70b6ee174977529eaf266c3488e6e2e",
version: 63
}
}
}]
Success!
And in the miner #2 console:
> admin.peers
[{
caps: ["eth/62", "eth/63"],
id: "dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d",
name: "Geth/v1.4.18-stable-c72f5459/darwin/go1.7.1",
network: {
localAddress: "192.168.1.11:62922",
remoteAddress: "192.168.1.11:30301"
},
protocols: {
eth: {
difficulty: 157293798,
head: "0xd9b044d4e996407ff94b075c36b845db219078c64e7898e628983496d46067bf",
version: 63
}
}
}]
Confirm success!
Here is the console log from one of the miners:
I1031 00:53:27.604563 miner/worker.go:435] 🔨 🔗 Mined 5 blocks back: block #1447
I1031 00:53:27.605050 miner/worker.go:539] commit new work on block 1453 with 0 txs & 0 uncles. Took 460.253µs
I1031 00:53:29.682117 core/blockchain.go:1001] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 12.081834ms. #1453 [3a94659b / 3a94659b]
I1031 00:53:29.683526 miner/worker.go:539] commit new work on block 1454 with 0 txs & 0 uncles. Took 1.167337ms
I1031 00:53:29.683565 miner/worker.go:435] 🔨 🔗 Mined 5 blocks back: block #1448
The 3rd line shows that the other miner has mined a block, and this miner is importing the block. The other lines show that this miner is mining the blocks.
To automate the peer-to-peer discovery, I create /tmp/Test2Miners/miner1data/static-nodes.json with the following information (reference
Static nodes):
[
"enode://dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d@192.168.1.11:30301",
"enode://b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436@192.168.1.11:30302"
]
and I copy this file to /tmp/Test2Miners/miner2data/static-nodes.json.
I restart both miners using the /tmp/Test2Miners/runMiner1 and /tmp/Test2Miners/runMiner2 commands in separate terminal windows and check that they are connected to each other using the admin.peers and they are. Success++.
