When a block is broadcasted, are all the data of the transactions packed into it or are only its hashes included in the block

Question

Most of the blogs and answers to this question do not give a straightforward answer.

I have a good amount of information regarding bitcoin and would like to simply know if the transactions are packed as a whole inside the block when it is broadcasted or if only the hashes are included on broadcast and then the nodes (if they don't have a few transactions already in their mem pool) query the other nodes to give the transactions corresponding to that hashes?

Regards PL46U3@LTZ

Answer 1

It depends on which protocol is used. The two main ones that are commonly available:

• The original getdata/block-based protocol. A node would send getdata message with a block hash, and in return receive block message which contains the full block, including the headers, and all transactions.
• The BIP152 "compact blocks" protocol extension, introduced in 2016. In this mode, nodes would ask (again using getdata) for a compact block (cmpctblock), which consists of the block header, the coinbase transaction, and short (48 bits) salted hashes of all the transactions in the block. The receiver would then try to reconstruct said block using the transactions it already has in its mempool (or elsewhere), request missing ones (using getblocktxn), receive those (using blocktxn), try to reconstruct again, and if that still fails, fall back to requesting the full block using the original protocol.

Both of these approaches do require that the receiver is somehow made aware of the block's existence. There are again a number of ways this can be done:

• The original inv-based protocol, where new block hashes are announced. Nodes can also ask for large sequences of block headers (for catching up on historical blocks) using getblocks).
• The BIP130 "sendheaders" protocol extension. This allows nodes to request that new blocks are announced using their headers (headers message) rather than using the hashes. Headers are 80 bytes, while hashes are 32, so they're slightly bigger, but headers are much more useful for the receiver to make decisions based on (e.g. they can already verify proof-of-work).
• The BIP152 compact block protocol also includes a "high bandwidth" mode, where nodes can request that new blocks get announced immediately using cmpctblock, rather than needing a round-trip using inv or headers first.

Nodes may also negotiate ahead of time that cmpctblock messages may be sent unannounced (without corresponding getdata request), to reduce the latency.

Modern Bitcoin Core versions use getdata/block for initial block download, and then compact blocks for newly found blocks (and sendheaders for learning about them).