Since, at the time, a block was sent as a single network message, there was indirectly a 32 MB limit on the size of the block, but there wasn't any specific size limit specifically intended for blocks.
Got it - so blocks are not sent as a single network message now (I haven't kept up with the latest changes)?
I haven't followed the recent changes very closely, so I'm not sure what has been implemented yet, but there was an idea that was being discussed about sending the block headers first, separate from the rest of the block. Since most nodes would already have heard about most of the transactions that are in the block, back when they relayed them in the first place, nodes would only need to request the few transactions that they were missing. This would reduce the overall bandwidth needed to operate a full node, and would increase the speed at which a new block was propagated through the network. Obviously for this to happen, the block would no longer be a single network message.
I'm not sure what the plans were for the initial download on a new node, but I thought "headers first" had already been implemented there?
I'm led to believe that headers
are sent first; bitcoin-cli getblockchaininfo returns a number of headers roughly equal to the number of blocks in total, even during a sync. I'm not certain, but my assumption would be that this is in fact header-first transfer, and not just bad wording. (I'm also assuming it's unrelated to the inv messages sent over P2P to describe available blocks).
Where does the 32MB network message limit come from? 32MiB due to the number of bits in a length field? (also not in regard to a blocksize limitation)