<p>A security assumption is that nodes are connected to at least one honest peer. If all of their peers are malicious, is is perfectly feasible for them to withhold information about certain blocks or transactions from a victim. Look up eclipse attacks, if you want to know more about this style of attacks, or the mitigations that exist against them.</p>

CC BY-SA 4.0
2021-07-21T05:17:44.893Z
So, is an honest relay expected to send headers for both the side chains in the "inv" and "headers" message?      If multiple relays send "inv" message to a node, will the node send "getheaders" message to each one of them and compare? Or will the node send "getheaders" message to only one of the relays?
satya
CC BY-SA 4.0
2021-07-21T05:24:39.640Z
Assuming at least one of the relays is honest, what checks/mechanism does the node use to ensure it has a complete view?
satya
CC BY-SA 4.0
2021-07-21T15:25:29.240Z
There is no such thing as a "complete view". Every node independently decides which block it considers to be the currently active one based on the information they have, and honest nodes will relay this information to their peers. Nodes only know about stale blocks because at the time they were relayed, from the perspective of the relayer, they weren't stale.
Pieter Wuille
CC BY-SA 4.0
2021-07-21T17:15:47.987Z
Thank you, Pieter :) Please let me know if this is right. Suppose a node is connected to 8 peers. Each of the (honest) peers that has a new block sends "inv" message to the node "if the peer considers this block will be part of the main chain". The node responds with "getheaders" message to "all the peers" that sent "inv" message. Whenever a peer returns a header, the node requests for "getdata" to the same peer. If the node doesn't get the "block" within 2 seconds, the node picks another peer that sent the same header and requests "getdata" from it.
satya
CC BY-SA 4.0
2021-07-21T17:31:45.233Z
Is there any (somewhat) formal specification of the required assumptions of the Bitcoin block propagation to work? Eg: What does "honest" peer mean here? What information is an "honest" peer required to propagate, and what is optional?   I'm trying to integrate Bitcoin with another blockchain. Knowing formal assumptions is kinda important.
satya
CC BY-SA 4.0
2021-07-21T17:35:07.720Z
Is there any pseudocode somewhere for how the nodes work when propagating blocks?
satya
CC BY-SA 4.0
2021-07-21T20:13:28.560Z
There cannot be a formal specification of the Bitcoin protocol, because there is no authority that can decide one. The rules of the network are defined by what people run, unsatisfying as that may be. Imagine we write a document and somehow bless it to be the Bitcoin protocol specification. And now someone finds a discrepancy between that document and the node software actually running on the network. Absent an authority that can force everyone to download new software, the only conclusion is that the document is wrong, and needs to be fixed.
Pieter Wuille
CC BY-SA 4.0
2021-07-21T20:16:16.210Z
There is of course documentation, where people **describe** the rules (rather than **prescribe**) them. Some of it can be found on the https://bitcoin.it wiki (though a lot there is outdated) and https://developer.bitcoin.org/. Most significant changes that affect interaction between different implementations are first proposed as BIPs (https://github.com/bitcoin/bips), but a lot more client-specific policy like relay behavior is simply in the client's respective source codes.
Pieter Wuille
CC BY-SA 4.0
2021-07-21T04:44:28.003Z
2021-07-21T14:14:01.100Z
2021-07-21T14:14:01.100Z
Pieter Wuille
<p>In Bitcoin, many forks occur when multiple miners mine blocks at the same time. Then there will be multiple blocks at the same block height.
I was looking at the Bitcoin P2P developer guide at <a href="https://developer.bitcoin.org/devguide/p2p_network.html" rel="nofollow noreferrer">https://developer.bitcoin.org/devguide/p2p_network.html</a></p>
<p>For propagating blocks, a relay sends an &quot;inv&quot; message to its peers. The peers request header info with &quot;getheaders&quot; and relay responds with &quot;headers&quot; message. Then the peers request block info with &quot;getdata&quot; and relay responds with &quot;block&quot; message.</p>
<p>In this case, how can peers be assured of getting multiple blocks at the same block height? A relay could deliberately propagate &quot;inv&quot; and &quot;headers&quot; messages for only one of the blocks at the same block height.</p>
<p>How can peers even know that a fork happened? Is getting the information about the fork the responsibility of the relay or the peer?</p>

<bitcoin-core><blockchain-fork><p2p><stale-block>
How do full nodes get the information about stale blocks?
satya
# How do full nodes get the information about stale blocks?

(Asked by: username_0 on 2021-07-21)

In Bitcoin, many forks occur when multiple miners mine blocks at the same time. Then there will be multiple blocks at the same block height.
I was looking at the Bitcoin P2P developer guide at <https://developer.bitcoin.org/devguide/p2p_network.html>

For propagating blocks, a relay sends an "inv" message to its peers. The peers request header info with "getheaders" and relay responds with "headers" message. Then the peers request block info with "getdata" and relay responds with "block" message.

In this case, how can peers be assured of getting multiple blocks at the same block height? A relay could deliberately propagate "inv" and "headers" messages for only one of the blocks at the same block height.

How can peers even know that a fork happened? Is getting the information about the fork the responsibility of the relay or the peer?

**Tags:** bitcoin-core, blockchain-fork, p2p, stale-block


---

## 1 answers

### Answer by username_1 on 2021-07-21. Score: 4 | Accepted answer

A security assumption is that nodes are connected to at least one honest peer. If all of their peers are malicious, is is perfectly feasible for them to withhold information about certain blocks or transactions from a victim. Look up eclipse attacks, if you want to know more about this style of attacks, or the mitigations that exist against them.

> **Comments:**
> **username_0**: So, is an honest relay expected to send headers for both the side chains in the "inv" and "headers" message?      If multiple relays send "inv" message to a node, will the node send "getheaders" message to each one of them and compare? Or will the node send "getheaders" message to only one of the relays?  
> **username_0**: Assuming at least one of the relays is honest, what checks/mechanism does the node use to ensure it has a complete view?  
> **username_1**: There is no such thing as a "complete view". Every node independently decides which block it considers to be the currently active one based on the information they have, and honest nodes will relay this information to their peers. Nodes only know about stale blocks because at the time they were relayed, from the perspective of the relayer, they weren't stale.  
> **username_0**: Thank you, username_1 :) Please let me know if this is right. Suppose a node is connected to 8 peers. Each of the (honest) peers that has a new block sends "inv" message to the node "if the peer considers this block will be part of the main chain". The node responds with "getheaders" message to "all the peers" that sent "inv" message. Whenever a peer returns a header, the node requests for "getdata" to the same peer. If the node doesn't get the "block" within 2 seconds, the node picks another peer that sent the same header and requests "getdata" from it.  
> **username_0**: Is there any (somewhat) formal specification of the required assumptions of the Bitcoin block propagation to work? Eg: What does "honest" peer mean here? What information is an "honest" peer required to propagate, and what is optional?   I'm trying to integrate Bitcoin with another blockchain. Knowing formal assumptions is kinda important.  
> **username_0**: Is there any pseudocode somewhere for how the nodes work when propagating blocks?  
> **username_1**: There cannot be a formal specification of the Bitcoin protocol, because there is no authority that can decide one. The rules of the network are defined by what people run, unsatisfying as that may be. Imagine we write a document and somehow bless it to be the Bitcoin protocol specification. And now someone finds a discrepancy between that document and the node software actually running on the network. Absent an authority that can force everyone to download new software, the only conclusion is that the document is wrong, and needs to be fixed.  
> **username_1**: There is of course documentation, where people **describe** the rules (rather than **prescribe**) them. Some of it can be found on the https://bitcoin.it wiki (though a lot there is outdated) and https://developer.bitcoin.org/. Most significant changes that affect interaction between different implementations are first proposed as BIPs (https://github.com/bitcoin/bips), but a lot more client-specific policy like relay behavior is simply in the client's respective source codes.  

---

