I do note that what Luke did was create a separate message type for unvalidated blocks in order to indicate to the peers that the block is unvalidated.
This message could be a hashes only.
"fastblock"
block header
boolean verified
hash[] txHashes
These blocks could be forwarded as long as they (appear to) extend the main chain. The verified field indicates if the block was verified.
I think p2pool does something like that?
Nodes could respond by asking for all transactions that they are missing.
Except for initial download, there seems little point in using the original block message.
avoids imperiling SPV nodes
SPV nodes are supposed to use number of confirms for security. If there is a 6 block fork, they are already in danger.
However, the verified flag at least puts the attacker at risk of disconnect.
The other obvious enhancement would be to split block forwarding to avoid sending redundant data for transactions which have already been received by the far end, this can be done without increasing round trips by just using the existing INV caches to track what txn we know the peer already knows.
Sending only the hashes accomplishes mostly that. Let the node ask for missing transactions.
If nodes didn't forward until they had all the transactions, then it creates an incentive to make sure transactions are pushed in advance.
I think a "blockpreview" message would also be useful. It would be like the blockfast message but would not actually meet POW (nonce = 0).
The preview would be a list of hashes to be included in a block. Nodes would store (merkle-root, Hash[]) maps.
For a miner, the block propagation process could be
Miner sends (unverified) "headers" message containing the new block [ * ]
Peer checks if the header extends the block tree, if not it does nothing [ ** ]
Peer checks if POW is met and difficulty value is correct, if not, it disconnects
Peer checks if merkle root is in preview map cache, if not, it requests a "fastblock"
Peer checks if all transactions are known, if not, it requests the extra transactions.
Once the transactions are all known, it forwards the headers message (unverified).
Once the transactions have all been verified, the block can be stored to disk and added to the chain.
[ * ] The headers message would need a verified field
[ ** ] Headers would be forwarded even if they extend an alternative chain (but probably only within the last few blocks)