If the block size is increased past 32MB, then one block won't be able to fit into message anymore.
This means that blocks need to be partitioned over multiple messages and ideally, the receiving node should be able to check each sub-block is valid before receiving the next sub-block. This prevents sending a node a huge block and then at the end it turns out that it was a difficulty 1 block.
The merkleblock message already achieves this. The reference client would just need to be able to combine multiple merkle blocks together to make one block.
Extra fields could be added to the merkle block to help manage the process.
| Field Size | Description | Data type | Comments | ||||||
| ? | block_size | var_int | The size of the block in bytes | ||||||
| ? | sub_block_position | var_int | The position of the first transaction in the block | ||||||
| ? | sub_block_index | var_int | The index of the sub block | ||||||
| ? | sub_block_count | var_int | The number of the sub blocks for the block |
If all the fields are set to zero, then it means that it is an independent merkle block. Otherwise, a block is being broken down into pieces.
When sending partitioned blocks, the rule would be that the transactions have to be in sequence. The recipient could create a large array and would know where to copy the transactions.
This would allow out of order merkleblocks.