2

Consensus Logic with an example

  1. Person A generates a transaction to pass some ether to person B
  2. The transaction is submitted on the node
  3. Node then passes that unconfirmed transaction to the whole connected network
  4. The miners pickup the unconfirmed transaction
  5. They start trying to randomly generate the nonce to find the correct hash
  6. So one of the miners finds the correct nonce to generate the block
  7. Now this miner sends this block to peer who then further send to the next peers and gradually everyone receives the block
  8. Everyone verifies the work whether it is meeting the criteria
  9. Once satisfied they include that block in their ledger
  10. Miner gets rewarded
  11. B's balance gets updated
  12. Thus A's payment is now confirmed

Questions:

  1. Do you find any gap in the above listed flow? if yes please highlight
  2. Is the block introduced in the blockchain when the miner has solved it or when it was confirmed by the peers?
  3. If by peers then minimum how many needs to confirm?
2

Question 1: The "confirmation" in step 12 is a function that the end client undertakes, and depending on how sensitive the transaction is the client typically waits for a number of further blocks to be chained to the block that includes the transaction of interest.

Other than that, your sequence of steps is fine for a "sunny day" scenario (i.e. when things go well). There are of course other scenarios that need to be considered for the "rainy day" scenarios (e.g. corner cases, or when you add hostile elements in the sequence).

Question 2: as the blockchain is a distributed entity, the introduction of a new block on the chain is a collective action that each participating node has to carry out. The successful miner can only advertise their success together with the associated proof. In other words, the successful miner triggers the action, but the actual action of growing the chain is carried out collectively.

Question 3: this is answered in the two answers above.

  • Thanks for your reply Zanzu! Are you saying if the block generation was done correctly then all the clients will gradually accept it and make it part of the blockchain. Also there is nothing like only when 51% nodes have accepted it the newly generated block it will be a confirmed one in the whole chain? How does the way the client decide the level of sensitivity of the newly generated block to take the decision whether to wait or not? – Susmit Apr 13 '17 at 10:01
  • Q1: "Are you saying..." - A: yes. Q2: "Also there is nothing like..." - A: The 51% principle comes into play to address one of the rainy day scenarios I hinted at in my response. Specifically, if more than one chain of blocks exists (e.g. due to an attack on the blockchain), then only the longest chain prevails. By definition, the longest chain corresponds to the set of miners that collectively have a majority of hash power (when measured over a long enough period). Q3: "How does the way..." - A: this depends on the wallet, its configuration, or ultimately the end-user. – zanzu Apr 13 '17 at 10:52
  • If the end user is engaged in a transaction worth 1 USD worth (i.e. can write off the money if things go wrong), and time is of the essence, then s/he may want to take the risk and not wait for more blocks to confirm the transaction. The situation will be different if the transaction is worth 100,000 USD. Not many people can afford to write off that amount of money so the norm for such a transaction would be to trade off confirmation speed for added security. – zanzu Apr 13 '17 at 11:07
  • Thanks a lot! This really makes few things pretty clear. I have created a second part of the similar scenario with more queries, if you could share your thoughts in that one as well will be great. – Susmit Apr 13 '17 at 11:28

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.