1

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?

satya
  • 171
  • 5

1 Answers1

4

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.

Murch
  • 75,206
  • 34
  • 186
  • 622
Pieter Wuille
  • 105,497
  • 9
  • 194
  • 308
  • 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 Jul 21 '21 at 05:17
  • Assuming at least one of the relays is honest, what checks/mechanism does the node use to ensure it has a complete view? – satya Jul 21 '21 at 05:24
  • 2
    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 Jul 21 '21 at 15:25
  • 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 Jul 21 '21 at 17:15
  • 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 Jul 21 '21 at 17:31
  • Is there any pseudocode somewhere for how the nodes work when propagating blocks? – satya Jul 21 '21 at 17:35
  • 2
    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 Jul 21 '21 at 20:13
  • 2
    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 Jul 21 '21 at 20:16