22

The peer discovery algorithm is based on the kademlia protocol. A standalone implementation can be found here. Edit: A simplified model of how the p2p algorithm works is the following: you have nodes that are assumed to be always available/online (in Ethereum they are called bootstrap nodes) bootstrap nodes maintain a list of all nodes that connected to ...


7

Ethereum requires UDP port 30301 for node discovery, and Tor only supports TCP-based transport. It's likely that your blockchain sync hasn't started because your client can't find any peers.


6

Bootnodes are the nodes which provide information about other peers, txns, blocks. Once that information is received, bootnode does not need to be online. But bootnodes are always kept online, because new nodes keep coming up and require some of this information. Information of bootnodes can be provided by: genesis file list of reserved peers at startup If ...


5

yes there is some built-in bootstrap nodes you could check the code in github : Geth : https://github.com/ethereum/go-ethereum/blob/ff2c966e7f0550f4c0cb2b482d1af3064e6db0fe/params/bootnodes.go // MainnetBootnodes are the enode URLs of the P2P bootstrap nodes running on // the main Ethereum network. var MainnetBootnodes = []string{ // Ethereum ...


4

As i know there is not built in option to do so, however you could do it using a script : i am trying here to give you some response elements. the following snippet to output all the connected peers admin.peers.forEach(function(value){console.log(value.id+"@"+value.network.remoteAddress)}) you need to write a script which read the outputs and use them as ...


4

Well, apparently the reason why the connection is being refused is that "'Connection refused' is ok for the Go bootnode. [as i]t does not accept TCP connections", as suggested by fjl in the go-ethereum issue 380 Discovery uses UDP as protocol. If you want to test if it's working properly, use netcat -u -z -v <PUB-IP> 30301 instead.


4

These are stored in the the ~/.ethereum/nodes/ directory as a LevelDB database (in .ldb files). The reading and writing of these files is handeled by database.go. To read them you'd need a tool which understood the schema on which the database is based, which is described here. I don't know of any existing tool for the node data, but block explorers work in ...


3

Unfortunately there is no way to differentiate between ETH & ETC peers at the P2P layer due to the fact that most client implement eth/63, which would defines STATUS 0x00 as [protocolVersion: P, networkId: P, td: P, bestHash: B_32, genesisHash: B_32] As ETC / ETH have identical genesis hashes and network IDs, it would be impossible to tell them ...


3

You can use implementations of existing clients: Besu - Java implementation Geth - Go implementation Parity1 - Rust implementation 1 At this point, I would be careful to use Parity's implementation because Parity has officially stated it won't maintain the codebase any longer and judging by the commit activity, its starting to show already.


3

I assume that with "address" you mean IP address? IP addresses are exposed when running a node (Node's IP exposed). You can of course get some information based on an IP (geolocation for example) but that information is not directly related to the Ethereum network. Even if your node's IP is known, it doesn't give any attacker much information. The only ...


3

I've had the same issue. It appears that --nodiscover is just disabling your node from running node-discovering algorithm to find peers to connect, but it doesn't prevent others from discovering and attempting to connect to your node. If you'd like to limit the inbound connection attempts, you could specify --netrestrict. e.g. --netrestrict="127.0.0.1/8"


3

Have a look in bootnodes.go. It's still 3 for the Geth clients: // ETH/DEV Go Bootnodes discover.MustParseNode("enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303"), // IE discover.MustParseNode("enode://...


2

I'd consider using a distributed key-value store such as ETCD (https://coreos.com/etcd/docs/latest/getting-started-with-etcd.html). You could set up an ETCD alongside ethereum and share arbitrary data between each node. While this works well for your specific use case, it may be worth it to consider piggybacking on the Bit Torrent DHT -- a publicly ...


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 ...


2

I have met the same problem and now I have solved it trough delete the director "datadir" which in your case is ".". Then I reinit with the json document again.Going down the steps, maybe it will solve your problem. if you run the command "addPeer()" with flag "--verbosity 6" maybe you will get a error like "Ethereum handshake failed" and "genesis block ...


2

The accepted answer is not correct. The bootnodes are unreliable. A node can get blacklisted from the bootnodes and the bootnodes are sometimes unavailable without any apparent reason. The Ethereum network carries forward on its own inertia because peers maintain a history of seed candidates based on past experience. Completely new nodes must join the ...


2

Correct. Ethereum node discovery works by nodes gossiping enode addresses between each other, so you have to connect to at least one node manually. The mainnet/testnets get around this inconvenience by having bootstrap nodes hardcoded into clients that lets nodes connect and discover more nodes quickly.


2

Generally speaking, the answer is yes, there needs to be some sort of trust in the Ethereum network as a whole, i.e. there are more good people than bad. Yuval Marcus, Ethan Heilman and Sharon Goldberg co-authored a paper on "eclipse attacks": a scenario whereby a set of nefarious nodes corner a well-intended node, giving them the impression that they are ...


2

Yes geth --nodkey=key.txt will (re)generate the same enode url repeatedly as the cli options would suggest. It wasn't working for me due to the unfortunate combination of a typo in my sh script and a bad nodekey file.


2

There is also a rust enr-cli library to assist with decoding ENR strings. You can install it via cargo install enr-cli --version 0.1.0-alpha An example of its use is: $ enr-cli -e -Iu4QGuiaVXBEoi4kcLbsoPYX7GTK9ExOODTuqYBp9CyHN_PSDtnLMCIL91ydxUDRPZ-jem-...


1

You're missing the blockchain concept. Transactions are processed on all nodes. Mining determines the order of the transactions all nodes eventually agree on. This is not the same thing as a node running transactions and the rest of the network accepting its findings. My answer over here may shed some more light on this. how blockchain can handle the ...


1

Bootnodes is a cheap and effective solution to aid the network self-discovery, but they need to catch up with a proper genesis file to isolate your network. When you run geth, the genesis block is recreated from scratch and then it begin to sync with peers at block 1. For you private blockchain, you need to provide this file to all of your nodes so they ...


1

Full nodes are constantly syncing. When a miner mines a block, it transmits it to the network. When you call web3.eth.getBlockNumber() to a full node, it already knows what the latest block it knows about it, so it can tell you instantly. Light nodes aren't any different here. The difference between light nodes and full nodes is that light nodes only care ...


1

It performs this lookup with its own address as target address only when the table is empty.


1

You must understand that the distant it can be simple interpret as the different of bit. Let's say n1 = 0x80 which in bit is 1000 0000. So the distant for each ith is this routing table: 0th 1000 0000 1th 1000 000x 2th 1000 00xx 3th 1000 0xxx ... With each row ith contain k peers which contain information about said peer such as their peer address, network ...


1

Geth attempts to connect to 25 peers by default, as stated on the CLI commands page. This can be changed with: --maxpeers value Maximum number of network peers (network disabled if set to 0) (default: 25)


1

At least one difference between the two is that the --bootnodes argument sets explicitly the boot node addresses, whereas the static-nodes.json file sets the addresses of static full nodes (peers).


1

You could give your node a nodekey (see --nodekey) and set it as bootnode (see --bootnodes). See also the bootnode executable for how to easily create a nodekey and the associated enode URL. With this, you remove it completely from the public Ethereum network. As it is, your geth connects to the public Ethereum bootnodes. That's how it gets discovered by ...


1

Yes, you enable tracing on the node for the sync module, like that: parity -l sync=trace This will produce a lot of noise, but you will be able to see why nodes are talking to each other, or why not... :p


1

The default port used by geth to intercommunicate between nodes is 30303. One you have stablished the tunnel using ssh between the nodes, you have to let the nodes know about each other. See the documentation at http://ethdocs.org/en/latest/network/connecting-to-the-network.html, on how to connect nodes.


Only top voted, non community-wiki answers of a minimum length are eligible