<blockquote>
<p>I understand that in selfish mining a malicious node can &quot;send its entire hidden chain&quot;. Exactly how is this done? I know that usually a single block is broadcast-ed right after it is mined, but how does it relay an entire chain?</p>
</blockquote>
<p>Forks appear naturally, when two miners produce competing blocks approximately simultaneously. Such forks may have arbitrary length (thankfully, with exponentially decreasing probability under reasonable assumptions), which may need to be resolved. Doing so involves having a mechanism of synchronizing chains where the receiver is missing multiple blocks. So there isn't anything special here, it's just the normal protocol for relaying blocks that is used.</p>
<p>What that protocol is depends on the software used.</p>
<ul>
<li><p>The basic approach involves sending an <code>inv</code> for the new tip. The receiver will then fetch the block using <code>getdata</code>, notice it is missing its parent, and ask for that parent using another <code>getdata</code> and so forth, until it reaches a parent that the receiver already has.</p>
</li>
<li><p>Since Bitcoin Core 0.10, nodes will respond to an <code>inv</code> with a <code>getheaders</code>, to retrieve all block headers between a point the receiver already has and the announced tip. The request contains a list of recent block hashes the receiver has to avoid duplicating things. Only when the receiver has all the headers, and has validated them, it will start asking for the full blocks that are missing along the way. This permits fetching blocks from multiple peers in parallel.</p>
</li>
<li><p>Since the adding support for <a href="https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki" rel="nofollow noreferrer">BIP130</a> (&quot;sendheaders&quot;) in Bitcoin Core 0.12, announcements of new blocks themselves are done by immediately sending the headers, avoiding an <code>inv</code> + <code>getheaders</code> step.</p>
</li>
<li><p>Since adding support for <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow noreferrer">BIP152</a> (&quot;compact blocks&quot;) in Bitcoin Core 0.13, blocks can also be announced (in negotiated cases) without any <code>inv</code> or <code>headers</code> message at all, instead sending a compact block directly (which uses an encoding that avoids transactions the receiver is assumed to already have). In case there are missing transactions, or parent blocks, those are requested using the normal means (<code>getdata</code> or <code>getheaders</code>).</p>
</li>
</ul>
<p>Note that all mechanisms are still available for all nodes on the network. The more modern ones are generally superior, but older or simpler software implementations can still use the <code>inv</code>/<code>getdata</code> approach if desired.</p>

CC BY-SA 4.0
2020-10-20T03:41:03.017Z
2020-10-20T03:41:03.017Z
Pieter Wuille
<p>I understand that in selfish mining a malicious node can &quot;send its entire hidden chain&quot;. Exactly how is this done? I know that usually a single block is broadcast-ed right after it is mined, but how does it relay an entire chain?</p>
<p>I am looking at the original bitcoin protocol <a href="https://en.bitcoin.it/wiki/Protocol_documentation#inv" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Protocol_documentation#inv</a>
It seems that inv can broadcast many objects. So would a malicious node send an entire chain via one call to inv or many?</p>

CC BY-SA 4.0
2020-10-20T01:52:08.490Z
@Prayank, I read a few links describing that the entire hidden chain is "published" when the length of the hidden chain is N+1 where N is the length of the main branch.This link <https://decentralizedthoughts.github.io/2020-02-26-selfish-mining/> says "The selfish miner continues to extend her secret branch until the public chain is one step behind. Then she publishes her secret chain."
Azurite
<client><protocol><selfish-mining><inventory>
How does a node send a chain?
Azurite
# How does a node send a chain?

(Asked by: username_0 on 2020-10-19)

I understand that in selfish mining a malicious node can "send its entire hidden chain". Exactly how is this done? I know that usually a single block is broadcast-ed right after it is mined, but how does it relay an entire chain?

I am looking at the original bitcoin protocol <https://en.bitcoin.it/wiki/Protocol_documentation#inv>
It seems that inv can broadcast many objects. So would a malicious node send an entire chain via one call to inv or many?

**Tags:** client, protocol, selfish-mining, inventory

> **Comments:**
> **username_0**: @Prayank, I read a few links describing that the entire hidden chain is "published" when the length of the hidden chain is N+1 where N is the length of the main branch.This link <https://decentralizedthoughts.github.io/2020-02-26-selfish-mining/> says "The selfish miner continues to extend her secret branch until the public chain is one step behind. Then she publishes her secret chain."  

---

## 1 answers

### Answer by username_1 on 2020-10-20. Score: 1

> I understand that in selfish mining a malicious node can "send its entire hidden chain". Exactly how is this done? I know that usually a single block is broadcast-ed right after it is mined, but how does it relay an entire chain?

Forks appear naturally, when two miners produce competing blocks approximately simultaneously. Such forks may have arbitrary length (thankfully, with exponentially decreasing probability under reasonable assumptions), which may need to be resolved. Doing so involves having a mechanism of synchronizing chains where the receiver is missing multiple blocks. So there isn't anything special here, it's just the normal protocol for relaying blocks that is used.

What that protocol is depends on the software used.

* The basic approach involves sending an `inv` for the new tip. The receiver will then fetch the block using `getdata`, notice it is missing its parent, and ask for that parent using another `getdata` and so forth, until it reaches a parent that the receiver already has.
* Since Bitcoin Core 0.10, nodes will respond to an `inv` with a `getheaders`, to retrieve all block headers between a point the receiver already has and the announced tip. The request contains a list of recent block hashes the receiver has to avoid duplicating things. Only when the receiver has all the headers, and has validated them, it will start asking for the full blocks that are missing along the way. This permits fetching blocks from multiple peers in parallel.
* Since the adding support for [BIP130](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) ("sendheaders") in Bitcoin Core 0.12, announcements of new blocks themselves are done by immediately sending the headers, avoiding an `inv` + `getheaders` step.
* Since adding support for [BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) ("compact blocks") in Bitcoin Core 0.13, blocks can also be announced (in negotiated cases) without any `inv` or `headers` message at all, instead sending a compact block directly (which uses an encoding that avoids transactions the receiver is assumed to already have). In case there are missing transactions, or parent blocks, those are requested using the normal means (`getdata` or `getheaders`).

Note that all mechanisms are still available for all nodes on the network. The more modern ones are generally superior, but older or simpler software implementations can still use the `inv`/`getdata` approach if desired.


---

