Q: I know that when a new geth instance runs it connects to the bootstrap nodes. What I want to know that do other nodes download blockchain from the bootstrap nodes or nor?

A: No. Regular nodes do not download the blockchain from bootnodes. The only role for the bootnodes is to allow regular nodes to connect to and get the connection information on other regular nodes. The regular nodes will then use this information to connect to other regular nodes.

Q: Bootstrap nodes are highly available so why just simply connect to bootstrap nodes instead of connecting to some other node in the network.

A: The bootnode's only role is to provide the connection information for regular nodes to connect to each other. The connection information for several bootnodes are hard-coded into the regular node source code - see bootnodes.go

As the bootnodes only serve very little information to each regular node, the bootnode server resources can be focussed on providing this information and not get bogged down transferring the blockchain data.

Q What if bootstrap nodes provide wrong information. The whole network is compromised right?

A Not necessarily. You are able to specify new bootnodes on the command line parameters of the regular node client:

geth help | grep bootnode
--bootnodes value   Comma separated enode URLs for P2P discovery bootstrap

You are also able to manually enter a list of other regular nodes on the network using the admin.addPeer(...) command.

Recently many users reported that their regular nodes was not able to find peers. There were some problems with the bootnodes. See geth does not sync out of the box.

The temporary workaround was to get a list of regular node connection information from peers that were already connected to peers, and pasting this connection information into the regular node that was experiencing the peer discovery problem. See How can I create a list of peers from my syncing geth node to manually paste into my non-syncing geth node using the admin.addPeer() command?.

Q: How is a regular node different than a bootstrap node?

A The regular node has the peer discovery mechanism of the bootstrap node. Additionally, the regular node will download and synchronise the blockchain with other regular nodes. The bootstrap node cannot be used directly to synchronise the blockchain.

Q: And also How does peer discovery actually works?

A: See Node discovery protocol and What are the peer discovery mechanisms involved in Ethereum?

Q: What if nodes only download and not upload?

A: There are sufficient nodes (~6,000) on the network that your node should find other nodes to download from.

Q: What if I execute a denial of service attack which connect to many nodes in the network and downloads blockchain?

A: You will need a lot of computing and networking resources to try to execute a denial of service attack on ~6,000 nodes.

Finally it worked. I still don't really know what did it but I will list here some of the changes that got it to work. When I figure out what exactly did it I will update my answer.

• Use the --v5disc flag for node discovery.
• The bootnode took ages to start with the --v5 flag so instead of using a bootnode I chose a random node as bootnode. I started my node with the --bootnodes referring to this regular node but didn't seem to work until I manually added it. Probably using static-nodes.json would have worked as well.
• Use a small networkId. I think I was too optimistic on the size of this value. Once I ran geth and realized that it was using a different NetworkID from the one I entered. This was not a good sign but instead of choosing a smaller value I chose as the value that geth was suggesting. I only realized there was something wrong going on when I got this error Protocol eth/63 failed id=X conn=inbound err="NetworkId mismatch - 3853220132 (!= 1245324517197969700)". I am now using a 10-digit networkId and this is what seems to have done the trick.
• [Possibly not necessary] Run a node in miner mode (personal.newAccount("pw"), miner.setEtherbase(eth.accounts[0]) & miner.start())

I am more inclined to think it was the networkId that was causing some sort of problem. At least switching to v5 made it more easy to detect.