What is the importance of the "confirmation" field in a block?

How many confirmations are required to accept a block in a blockchain?

3 Answers 3


Blocks in Bitcoin, as they exist in the blockchain, don't actually contain a confirmation field. When you query for a block in bitcoin-rpc or similar, additional information is added to the block based on your client's knowledge of the current state of the blockchain.

A pure block contains only five fields (some of which have sub-fields):

  1. Magic number (to identify that the following info is a block)

  2. Blocksize (how many bytes to read until the end of the block)

  3. Block header (important for block ordering/verification)

    • Version (the "rules" that this block adheres to)
    • Previous Block Hash (a fingerprint of the block this block builds on)
    • Transaction Merkle Root (a fingerprint of all of the block transactions)
    • Timestamp (UNIX epoch)
    • "nBits" or a compact expression of the block's PoW target
    • Nonce (a number the block miner used to find a valid PoW solution)
  4. Transaction count (number of transactions in block)

  5. Transaction list

Back to your question, the "block confirmation" count of a block is simply how many other blocks build on top of that block. Take for example the following three-block-long blockchain:

Three-block-long blockchain

The blue block (which starts the blockchain, so it's also called the genesis block) has three confirmations (it confirms itself, plus the two blocks that build on it further reinforce it as legitimate). The green block has two confirmations (it confirms itself, plus the one block that builds on it further reinforces it as legitimate). The orange block only confirms itself, giving it one confirmation.

If another block were added to the blockchain:

Four-block-long blockchain

All of the blocks from the previous image (blue, green, orange) would receive one additional confirmation, since they've been further "buried" in the blockchain.

As soon as a block exists (so it confirms itself automatically, giving it one confirmation) it can be included into the blockchain. In the event of a network fork, however, this isn't always the case. The number of confirmations of a block indicates how difficult that block would be to overwrite.

In the length-4 blockchain shown immediately above, attempting to overwrite the red block would only require introducing a block which competes with red as a child of orange:

enter image description here

Note that introducing the black block into the blockchain wouldn't necessarily overwrite the red block. If miners choose to mine on top of the black block instead of the red block, making the blockchain [blue-green-orange-black-...] the "longest" (really "heaviest," see bottom of post) chain, then the black block will replace the red block. If miners instead choose to mine on top of the red block, making the blockchain [blue-green-orange-red-...] the longest chain, then the red block won't be replaced. To ensure (assuming network miners don't explicitly favor the red block for some reason, and mine on top of it even when it isn't the latest block in the blockchain) that the red block gets forked, an attacker would need to introduce two blocks which fork off of orange:

Nearly-guaranteed fork of red block

To fork the green block off of the network, however, an attacker would need to introduce at least three blocks which build an alternative blockchain off of the blue block:

Potential fork of green, orange, and red blocks

And for a much higher chance of a successful attack, would need to introduce four blocks which build an alternative blockchain off of the blue block:

Very likely fork of the green block, orange block, and red block

Note that this attack would have (possibly-intended) side-effect of also removing the orange and red blocks from the blockchain.

Earlier, I used the term "longer" when referring to competing blockchain forks. While in reality the chain with the longest length measured in blocks is almost always the best blockchain, it isn't necessarily. Rather than count the number of blocks on the blockchain, bitcoin nodes choose the blockchain which is the "heaviest" or has the highest cumulative difficulty. Bitcoin mining involves "brute-forcing" a solution to a problem by repeatedly performing double-SHA256 calculations on a potential block header (described briefly above) searching for a resultant hash with certain properties (which can be incorrectly but essentially summarized as "a lot of leading zeroes"). A higher difficulty means that, on average, miners will have to perform more work for each valid PoW solution. The "best" or "heaviest" chain is the chain which has the highest total difficulty (which is calculated by adding up the difficulty of each block).

To summarize, a block can be accepted to the blockchain as soon as it exists, and it has one confirmation by simply existing. However, blocks of arbitrary depth can be removed from the blockchain by a blockchain fork.


The concept of confirmation in Bitcoin is a measure for how deeply buried a block or transaction is in the blockchain. It measures how many blocks on top there are. More means the block or transaction is harder to revert, as an attacker would need to at least do as much work as was needed to build those confirming blocks.

By definition, 1 confirmation equates being included in the blockchain.

If this question happens to be about the output of getblock RPC or similar APIs: it simply counts how many blocks there are on top. If the tip of the chain has height 426396, and the block you're querying for has height 426391, the result will state there are 6 confirmations (426396 - 426391 + 1 = 6).


What is the importance of the "confirmation" field in a block?

A confirmation is the act of a transaction being included in a single block within the Bitcoin blockchain.

A confirmation represents a certain degree of permanence within the Bitcoin blockchain.

The 'miners' are the entities that create blocks and decide what transactions to include in the blocks.

While a transaction included in a single block could be reversed by a miner, this would require that miner to generate both a replacement block for the block the transaction was in and an entirely new block, all before the rest of the miners can find any new blocks.

This is usually unfeasible, but it does occasionally happen and the block that gets replaced is known as an orphaned block. This also becomes exponentially less feasible when trying to replace greater numbers of blocks.

Once a transaction is included in a block, it will automatically be a part of all future blocks (via one-way cryptographic hashing of the prior block in each new block), so the total confirmations represent the number of blocks that have been generated since the transaction was initially confirmed.

Please note that when an end-user initially makes a transaction, the transaction is broadcast to the network nearly instantly, but it can often take 10 minutes or more for the transaction to actually get confirmed in a block.

How many confirmations are required to accept a block in a blockchain?

A confirmation is the act of the network/miners accepting a transaction in the blockchain.

However, from an end-user practical perspective, it is useful to consider how many confirmations would make the end-user feel confident that a transaction will not be reversed.

For small amounts, 0 or 1 confirmations could be considered secure.

For larger amounts, 2 or 3 or even more confirmations may be desired before a transaction is considered permanent/secure.

6 confirmations has generally been the standard for 'absolutely no way this will be reversed', but there have been a couple occasions where several dozen blocks were orphaned due to software bugs.

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.