Question about stale block

Continuing the discussion from Bitcoin Basics - Discussion:

Hi Ivan and everybody,

I’m a bit confused about Question 4 in the homework on stale blocks.
The question says, " Why is it important to wait for more than one block to be confirmed when sending or receiving a transaction?"
My confusion is that any transaction will first sit in the mempool before being picked up by a miner. I will not know when my transaction will be included in a block and whether the block holding my transaction would become a stale block. It seems to me that waiting for more blocks be confirmed before sending or receiving a transaction may not be relevant to minimizing my transaction being sent back to the mempool in case of a stale block situation …
Did I misunderstand anything?

Thank you.


1 Like

Hi Erick,

Your transaction will first be sent to the mempool and it will have 0 block confirmations. Once your transaction gets confirmed in a block (1 block confirmation), that’s where you would want to wait for more block confirmations. If you transaction was in a block number 100, and the chain moved to the latest block of 105, you would have 6 block confirmations. The odds that your block was in a stale block after 6 confirmations is so low, that we considered it to be the safe thing to accept. Hope this helped you out.

It seems to me that your confusion came from the question itself. There is no point in waiting for blocks, if you transaction hasn’t been yet included in block. Maybe we could reword the question a bit. Thanks. :smiley:

Hi Mauro,

Thanks so much for your explanation. It all became clear to me now.



1 Like

No problem Eric.I am glad I could help you understand it. Keep up the great work. :smiley:

1 Like

Not sure if right place to ask but can someone tell me what happens to the transactions on the stale block that are also accepted in the confirmed block when blocks have duplicate transactions in them?
I presume the network somehow invalidates those as they are now spent transactions? Does that happen before they go back into the mempool or the next time a miner trys to add them to a block and the block gets invalidated?

It is possible that transactions exist in both blocks, in fact it is safe to assume most of them will since miners will pick transactions in a similar fashion.
At the time blocks were constructed and eventually mined there is no way of knowing what transactions two independent miners put into their blocks.
But since both of these blocks have the same height its not an issue, only the transactions that are in the block that gets dropped return to the mempool, other transactions remain confirmed.

1 Like

Thanks alko I understand that much its probably in a lesson down the track I guess but I’m looking for specifics on how the network reviews what transactions go back into the mem pool i guess as it can’t just put all the transactions back into the mem pool from the orphaned block as some of them would of been confirmed in the accepted block as you say.
Does it compare transactions in both blocks and only put the unconfirmed ones back in? If so how as its encrypted?
Otherwise it must put all transactions back into the mem pool and somewhere else they get analyzed and dropped?

Transactions are not encrypted, you can view them publicly on a block explorer for example. Transactions are hashed which is used as their id.
When nodes reach consensus on the winning chain they can compare these hashes and know which transactions were part of both blocks so they can only put back in the mempool the ones that were not also part of the wining block. :slight_smile:

Thanks Alko that makes sense I was getting confused thinking that once they we put into the block and that was hashed it was encrypting the whole block but its the links that are hashed not the block container itself isn’t it?, thanks for your help :slight_smile:

Both are actually hashed, the previous block hash is used and the merkle tree of transactions, but there hashes are only part of the block header, the block data is still visible. :slight_smile:

1 Like