You're confusing storage, protocol, and commitment structure. They are all different things.
The *commitment* structure of blocks (= how its hashes are defined) involves a Merkle tree:
The txids of the individual transactions are the leaves of a tree.
Using those txids, the root of the Merkle tree is computed
The block header consists of a few fields (version, previous block hash, timestamp, difficulty, nonce) plus that Merkle root hash
The hash of that block header becomes the block identifier.
The above _only_ determines how "hash of a block" is defined. But it doesn't say anything about how that block is stored on disk, or how it is made available to other nodes in the P2P protocol. In fact, there are many different ways of doing that. The only requirement is that they all permit computing the exact same hash of the block.
In the P2P protocol, the normal block transfer mechanism asks for a block by its hash, and the response uses the format `<block header> <num_txn> <tx_0> <tx_1> ... <tx_n>`. This permits computing the block hash by reconstruct the whole Merkle tree on-the-fly.
Bitcoin Core on disk stores blocks in flat files, using the same format as the P2P format above, but prefixes each block with a 4-byte magic value plus a 4-byte length market.
In the P2P protocol extension BIP152 (compact blocks), only the header plus short (6-byte) hashes for each of the tansactions in the block are sent. The recipient then reconstructs the block using transactions from their own mempool, asking for any missing ones.
In the P2P protocol extension BIP37 (server-side bloom filtering), the recipient first gives the sender a Bloom filter that identifies which addresses/scripts/transactions the recipient is interested in. Then the recipient asks for blocks by block hash, but the sender will filter the blocks according to the previously sent filter. The sender then responds with a message for each block, consisting of the block header, followed by a sequence of transactions (for matching entries) and hashes of pruned subtrees (for subtrees without any matching entries). This permits the recipient to recompute the Merkle root as well (by using the hashes of pruned subtrees in place of their explicitly-computed hash). This is the only place in the protocol where the Merkle root structure is actually exploited. BIP37 is currently deprecated however (made optional in BIP111 first), due to DoS and privacy concerns the protocol has, as well as not preventing lying by omission (the Merkle computation guarantees that matching transactions are actually in the claimed block, but the sender can always claim to not find any matches).
The Electrum protocol is separate from the P2P protocol, and is used between Electrum servers (which are connected to full nodes they draw data from) and Electrum clients. This protocol permits the client to ask for transactions individually (by address, ...); the server then responds with matching transactions + Merkle paths for each match. This allows the client to verify the transactions against known block headers as well (same Merkle root), but but requires a relatively costly index to enable searching for transactions. It is also not very private, as the server gets to see what the client is interested in.
You can get bonuses upto $100 FREE BONUS when you:
💰 Install these recommended apps:
💲 SocialGood - 100% Crypto Back on Everyday Shopping
💲 xPortal - The DeFi For The Next Billion
💲 CryptoTab Browser - Lightweight, fast, and ready to mine!
💰 Register on these recommended exchanges:
🟡 Binance🟡 Bitfinex🟡 Bitmart🟡 Bittrex🟡 Bitget
🟡 CoinEx🟡 Crypto.com🟡 Gate.io🟡 Huobi🟡 Kucoin.
Comments