<p>Without knowing the parent, the node will hold onto the block and only do validation that can be done without context (i.e. the parent). It will also ask its peers for the parent block, and once it receives it, it will connect both blocks to its blockchain if they have more cumulative work than the node's current blockchain.</p>

<p>Otherwise the node ignores that block.</p>

<hr>

<p>Keep in mind that this scenario is extremely unlikely, and not because a miner is unlikely to find two conflicting blocks nearly simultaneously. Rather nodes will relay blocks once they verify them, there is no such thing as "send to a peer but not the network". Sending a block to a peer sends it to the network as that peer will relay it to its peers and so on. So when Ma receives the block, unless it has been sybil attacked by the Adversary, it will relay that block to the network.</p>

<p>When Ma's peers receive S1 and B4, they will relay it to Ma and Ma will update its blockchain accordingly.</p>

CC BY-SA 4.0
2018-08-13T04:52:12.073Z
Since headers-first synchronization (implemented in Bitcoin Core v0.10.0 and after), this is not the case anymore. Nodes don't ask for a block *unless* they know its headers and that of its ancestors, so this situation simply doesn't arise anymore. If a node were to send an unsolicited block, it just gets ignored.
Pieter Wuille
CC BY-SA 4.0
2018-06-08T03:46:59.983Z
2018-06-08T03:46:59.983Z
Ava Chow
<p>A miner also relays blocks it receives. So if you send a block to another miner who is well connected, the entire network will see it.</p>

<p>Every miner has a strong incentive to ensure that they are always mining on top of the longest available chain and there is infrastructure in place to ensure this. <a href="http://bitcoinfibre.org/public-network.html" rel="nofollow noreferrer">FIBRE</a> is one such system.</p>

CC BY-SA 3.0
2018-03-09T21:09:05.470Z
2018-03-09T21:09:05.470Z
David Schwartz
<p>This particular question has been bugging my mind for sometime now. Suppose there an adversary miner who mines a Block with one of his transactions. The miner would only send the updated Block to a known peer minor (Ma). And right after sending out the first Block to a known peer(Not to the whole network), the miner hits the jackpot and was able to generate another Block with the same transaction. It is highly unlike that the adversary could mine another block immediately after mining the previous block but it is doable. </p>

<p>Network --> [B1]->[B2]->[B3]->[S1]->[B4]  Ma --> [B1]->[B2]->[B3]->[S2],</p>

<p>Adversary -->[B1]->[B2]->[B3]->[S1]</p>

<p>As I've shown above, once Ma receives B4, it has no way of knowing what the predecessor Block (S1) of B4 is.</p>

<p>Could someone please explain how Bitcoin handles these sort of issues ? </p>

<bitcoin-core><blockchain><mining-theory><consensus>
What happens when a node cannot find the base Block of a newly received Block
psaw.mora
# What happens when a node cannot find the base Block of a newly received Block

(Asked by: username_0 on 2018-03-09)

This particular question has been bugging my mind for sometime now. Suppose there an adversary miner who mines a Block with one of his transactions. The miner would only send the updated Block to a known peer minor (Ma). And right after sending out the first Block to a known peer(Not to the whole network), the miner hits the jackpot and was able to generate another Block with the same transaction. It is highly unlike that the adversary could mine another block immediately after mining the previous block but it is doable.

Network --> [B1]->[B2]->[B3]->[S1]->[B4] Ma --> [B1]->[B2]->[B3]->[S2],

Adversary -->[B1]->[B2]->[B3]->[S1]

As I've shown above, once Ma receives B4, it has no way of knowing what the predecessor Block (S1) of B4 is.

Could someone please explain how Bitcoin handles these sort of issues ?

**Tags:** bitcoin-core, blockchain, mining-theory, consensus


---

## 2 answers

### Answer by username_1 on 2018-06-08. Score: 1

Without knowing the parent, the node will hold onto the block and only do validation that can be done without context (i.e. the parent). It will also ask its peers for the parent block, and once it receives it, it will connect both blocks to its blockchain if they have more cumulative work than the node's current blockchain.

Otherwise the node ignores that block.

---

Keep in mind that this scenario is extremely unlikely, and not because a miner is unlikely to find two conflicting blocks nearly simultaneously. Rather nodes will relay blocks once they verify them, there is no such thing as "send to a peer but not the network". Sending a block to a peer sends it to the network as that peer will relay it to its peers and so on. So when Ma receives the block, unless it has been sybil attacked by the Adversary, it will relay that block to the network.

When Ma's peers receive S1 and B4, they will relay it to Ma and Ma will update its blockchain accordingly.

> **Comments:**
> **username_2**: Since headers-first synchronization (implemented in Bitcoin Core v0.10.0 and after), this is not the case anymore. Nodes don't ask for a block *unless* they know its headers and that of its ancestors, so this situation simply doesn't arise anymore. If a node were to send an unsolicited block, it just gets ignored.  

---

### Answer by username_3 on 2018-03-09. Score: 0

A miner also relays blocks it receives. So if you send a block to another miner who is well connected, the entire network will see it.

Every miner has a strong incentive to ensure that they are always mining on top of the longest available chain and there is infrastructure in place to ensure this. [FIBRE](http://bitcoinfibre.org/public-network.html) is one such system.


---

