<p>It would be radically inefficient for every miner to flood the network with their blocks before they've won the proof-of-work competition.</p>

CC BY-SA 3.0
2015-07-29T15:42:07.013Z
I do think you bring up a good consideration, but spam would be mitigated if the broadcasts had to have 1/10th (or some percentage) of the work necessary.
morsecoder
CC BY-SA 3.0
2015-08-01T04:48:21.600Z
I doubt the flood would be any worse than the transactions flood
balki
CC BY-SA 3.0
2015-07-29T00:25:34.897Z
2015-07-29T00:25:34.897Z
Tom Mornini
<p>This effectively already happens on several levels, though without direct miner interaction. Both Bitcoin Core and the <a href="http://bitcoinrelaynetwork.org/" rel="nofollow">Bitcoin Relay Network</a> have their own implementation of forward preparation for the validation of blocks with the intent of speeding up block propagation as much as possible. One focused on validation latency, one on bandwidth and latency.</p>

<ul>
<li><p>Bitcoin Core has a validation cache of transactions it sees unconfirmed on the network, this allows the most expensive operations (executing the script, and validating signatures) to happen long before they are included in any block. Very often a node which has been active on the network for even a few minutes has already validated a large portion of any new blocks that arrive. When a new block is seen the uncached transactions are validated, inputs are checked, and the block is connected without having to do extensive, expensive validation of the contents. </p></li>
<li><p>The Bitcoin Relay Network takes this concept even further, it keeps track of transactions a node has already validated and transmits blocks excluding those transactions in order to save time on the wire. For many blocks this means the network only needs to push around the header (80 bytes), and a 2 byte integer referencing all the included transactions. An entire block might only be a few hundred bytes total and can be shuffled around the network quickly, then reassembled by the client using the transactions they already have in their mempool. A large portion of miners and services use this to drastically reduce network latency and subsequently their stale block rate over just using the P2P network to relay blocks around. </p></li>
</ul>

<p>Miners do not transmit unsolved blocks purely because it would be a massive denial of service problem, and there might be hundreds of thousands of candidate blocks that don't get solved every hour. Ultimately the Relay Network achieves the same result as what you proposed (just transmit a nonce) and actually uses substantially less bandwidth than the normal P2P network. </p>

CC BY-SA 3.0
2015-07-29T00:59:57.967Z
2015-07-30T17:41:59.860Z
2015-07-30T17:41:59.860Z
Claris
<p>One of the concerns with increasing the block size is that it may get orphaned more often due to network latency in sending the big block. Why can't miners send the block without the nonce as soon as they start working on them. When they find the nonce, they can just send the nonce with block headers which will be quick. It will be also fast for other nodes to validate as they have to just check one hash with the nonce to know if the block is valid or not. They would have already validated the transactions before and merkleroot much before.</p>

CC BY-SA 3.0
2016-04-01T09:30:51.010Z
Reminds me of the "Weak Blocks" proposal.
Murch
<block><mining-theory><nonce><block-size-increase><latency>
Are blocks sent only after finding nonce?
balki
# Are blocks sent only after finding nonce?

(Asked by: username_0 on 2015-07-28)

One of the concerns with increasing the block size is that it may get orphaned more often due to network latency in sending the big block. Why can't miners send the block without the nonce as soon as they start working on them. When they find the nonce, they can just send the nonce with block headers which will be quick. It will be also fast for other nodes to validate as they have to just check one hash with the nonce to know if the block is valid or not. They would have already validated the transactions before and merkleroot much before.

**Tags:** block, mining-theory, nonce, block-size-increase, latency

> **Comments:**
> **username_1**: Reminds me of the "Weak Blocks" proposal.  

---

## 2 answers

### Answer by username_4 on 2015-07-29. Score: 4 | Accepted answer

This effectively already happens on several levels, though without direct miner interaction. Both Bitcoin Core and the [Bitcoin Relay Network](http://bitcoinrelaynetwork.org/) have their own implementation of forward preparation for the validation of blocks with the intent of speeding up block propagation as much as possible. One focused on validation latency, one on bandwidth and latency.

* Bitcoin Core has a validation cache of transactions it sees unconfirmed on the network, this allows the most expensive operations (executing the script, and validating signatures) to happen long before they are included in any block. Very often a node which has been active on the network for even a few minutes has already validated a large portion of any new blocks that arrive. When a new block is seen the uncached transactions are validated, inputs are checked, and the block is connected without having to do extensive, expensive validation of the contents.
* The Bitcoin Relay Network takes this concept even further, it keeps track of transactions a node has already validated and transmits blocks excluding those transactions in order to save time on the wire. For many blocks this means the network only needs to push around the header (80 bytes), and a 2 byte integer referencing all the included transactions. An entire block might only be a few hundred bytes total and can be shuffled around the network quickly, then reassembled by the client using the transactions they already have in their mempool. A large portion of miners and services use this to drastically reduce network latency and subsequently their stale block rate over just using the P2P network to relay blocks around.

Miners do not transmit unsolved blocks purely because it would be a massive denial of service problem, and there might be hundreds of thousands of candidate blocks that don't get solved every hour. Ultimately the Relay Network achieves the same result as what you proposed (just transmit a nonce) and actually uses substantially less bandwidth than the normal P2P network.


---

### Answer by username_2 on 2015-07-29. Score: 2

It would be radically inefficient for every miner to flood the network with their blocks before they've won the proof-of-work competition.

> **Comments:**
> **username_3**: I do think you bring up a good consideration, but spam would be mitigated if the broadcasts had to have 1/10th (or some percentage) of the work necessary.  
> **username_0**: I doubt the flood would be any worse than the transactions flood  

---

