1

I have a private network running with three Parity nodes. Each one of these uses the same chain spec file and I invoke parity with a unique network id.

With geth, I know to use the --networkid flag but it doesn't seem to be connecting to the other nodes. And why should it? It doesn't have the chain spec file.

How do I give geth the information in the chain spec file, such as the enode info, etc.?

EDIT I see that this has been marked as duplicate. Unless I really did hit "submit" twice or something, I think the user is thinking of this thread: Parity Chain Spec file in Geth?

It's quite obvious that these are significantly different questions, so I'm sure no further explanation is necessary.

stone.212
  • 1,994
  • 1
  • 19
  • 38
  • Please don't ask this question twice. – q9f May 23 '17 at 13:04
  • I didn't. The two are similar but the other is asking a specific fix whereas this one is more general because it's possible that I have tunnel vision in assuming the first question is the right approach. – stone.212 May 23 '17 at 20:47
  • Here is the one you seem to think is a duplicate: https://ethereum.stackexchange.com/questions/16435/parity-chain-spec-file-in-geth?noredirect=1#comment17401_16435 (Unless I really did hit "submit" twice and I'm not seeing the duplicate?) – stone.212 May 30 '17 at 05:55
  • @5chdn Please release the lock on this. The question is not a duplicate and after doing a lot of research I can finally answer for posterity. – stone.212 Nov 01 '17 at 01:13
  • I can't, I'm not a moderator :) Raise this on meta or use the re-open vote mechanism. – q9f Nov 02 '17 at 13:38
  • The question is a duplicate of https://ethereum.stackexchange.com/questions/2708/peer-discovery-not-working-on-private-network – Ismael Nov 03 '17 at 15:58
  • @Ismael Both the setup and the problem are different in that question than in mine. The most important factor is that I was trying to get Geth to connect to a Parity-based private blockchain and that other question is about a Geth-only network. There are other differences but that is enough by itself to make it obvious that the two are not the same. – stone.212 Nov 06 '17 at 08:22
  • @stone212 You have to read the answer to understand. An "enode" is the id of a ethereum client in the network. To connect two nodes, you have to add one client the enode of the other. If you have the enode of your parity client you can add it to the geth client, typing in geth's console admin.addPeer("enode://<id>@ip:port"), or pass in the geth command line --bootnodes enode://<id>@ip:port, or through the configuration file indicated in the answer. – Ismael Nov 06 '17 at 15:04
  • @Ismael Two things: (1) your most recent comment is aimed at answering the original question, rather than countering the argument that this question differs almost entirely from the one that you said is a duplicate. (2) Your answer is not actually correct. But if we get the lock off of this question then I will answer my own question as I have since learned the answer. – stone.212 Nov 06 '17 at 23:12
  • @stone212 Since I'm not a moderator nor administrator I can't open a closed question, but if you think your answer is useful you can ask a new question and answer there. It should be faster than trying to unlock this question. – Ismael Nov 07 '17 at 00:57
  • Faster maybe. But this is the "correct" way to use the system. This was erroneously marked as duplicate by @5chdn May 23 at 13:04 and it is correct to try to get it unlocked. Ironically, the reason I know the answer is because the same user that marked this as a duplicate educated me as to the correct answer. – stone.212 Nov 07 '17 at 04:55

0 Answers0