5

Suppose the following:

  1. A miner has stored the current blockchain A-B-C.
  2. It stops listening for blocks during some time.
  3. During that time, blocks D and E are mined and broadcasted.
  4. The miner reconnects and immediately listens to the block E, before even knowing about D.

Will the miner simply ignore that block? And, how will the miner update to A-B-C-D-E (step by step)?

Improve this question
5

Will the miner simply ignore that block?

Yes, the block will be just ignored by the miner.

how will the miner update to A-B-C-D-E (step by step)?

When the miner's node gets online and start connecting to peers, it will start a “handshake” by transmitting a version message, which contains all basic identifying information, including BestHeight (the blockchain height of the node). Since v0.10, the nodes sync with 'headers-first'. This means that the nodes when restarted first ask peers for block headers and validate those. The getheaders message requests a headers message that provides block headers starting from a particular point in the blockchain. The connected peers will respond with a headers message that sends block headers to the node which requested certain headers with a getheaders message. The disconnected miner's node will then verify the difficulty until the tip. This allows a peer which has been disconnected to get the headers it hasn’t seen yet.

In a second stage, when the headers have been discovered, the node can then download the blocks. However, as the node already know about the whole chain in advance due to the block headers it has received, the blocks can be downloaded in parallel from all available peers. These blocks are received through getdata requests.

The above process describes the syncing of node when it was disconnected for some time. To make the answer more complete, I'll expand a bit further as to how new transactions and blocks are broadcasted. Nodes unsolicitedly transmits inv message (inventory message) containing one or more inventories of objects known to the transmitting peer. It can be sent to announce new transactions or blocks. The receiving peer can then compare the inventories from an inv message against the inventories it has already seen, and then use a follow-up getdata message to request unseen objects.

Improve this answer
5
  • Good answer, but there is one amendment I'd like to propose: I believe that the synchronizing node will first get all the blockheaders leading up to the best chain-tip to verify its total difficulty, then retrieve the remaining block data. Ever since header-first propagation, orphan blocks as mentioned by the asker are essentially not occurring anymore. – Murch♦ May 8 '19 at 1:41
  • @Murch I think I have the same process. Get block headers through inv and then retrieve data through getdata command. I think I only need to add about verifying total difficulty. Does that sound fair or I'm missing something? – Ugam Kamat May 8 '19 at 6:47
  • 1
    Right, but your text currently says it gets the only the hashes. It gets the complete headers, though. The headers are enough to check the links in the chain of blocks and the difficulty. That means that some attacks (like long low difficulty chaintips that end up not being the best chaintip) can be identified early, before the heavy lifting of actually validating the full block content is done. – Murch♦ May 8 '19 at 16:02
  • @Murch Ah right! That was my bad. Read it before having my morning coffee. I'll incorporate it in my answer. – Ugam Kamat May 8 '19 at 16:12
  • 1
    @Murch Looks like things had changed pretty dramatically since v0.10. I had read a previous version of sync process. It seems getblocks request is rarely used. I have revamped my answer. Feel free to edit if you notice a goof-up on my part. – Ugam Kamat May 9 '19 at 9:08
-2

Blockchain is built to have each block linked to the previous, as a result of; the hash in C has every information from B to duplicate that of C to D and D to E. To update the blockchain, care fully compare the time stamp and the information recorded in the Block E. Any discrepancies in Timestamp or recorded transaction would mean a tamper. The system won’t recognize such transaction.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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