<p>B forwarding to C before having received all transactions means forwarding before validating the proof of work, which would open a DoS vector. <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#cmpctblock" rel="nofollow noreferrer">BIP152 explicitly proscribes</a> doing so:</p>
<blockquote>
<p>A node MUST NOT send a cmpctblock message <strong>without having validated that the header properly commits to each transaction in the block</strong>, and properly builds on top of the existing, fully-validated chain with a valid proof-of-work either as a part of the current most-work valid chain, or building directly on top of it.</p>
</blockquote>
<p>With regard to the impossibility for B to construct a compact block announcement to C due to the shortIDs calculation, my understanding is that it is not correct. B can just reuse the same nonce A used in the original announcement. Technically, I think B can just forward the very same <code>cmpctblock</code> message it received from A.</p>
<p>It is also my understanding that the latency reduction, along with the bandwidth savings, are largely lost when most nodes don't have most transactions.</p>

CC BY-SA 4.0
2024-08-07T01:43:53.550Z
Is this the DoS vector: A receives a valid block; A uses that valid block's header PoW to send B an invalid block (e.g. by swapping a valid shortid for a made-up shortid) with missing transactions; B forwards that invalid block to its peers, wasting bandwidth, memory, and CPU.  The invalid block will potentially propagate across BIP152 high-bandwidth connections faster than the actual valid block for that header propagates. With the requirement to verify the merkle tree means the only way an invalid block can propagate is if that's what the miner produced, meaning they'll lose the block reward
David A. Harding
CC BY-SA 4.0
2024-08-07T06:54:58.870Z
Yes, as nodes are eager to process and share blocks if they didn't validate the PoW you could make the network aggressively broadcast tons of invalid data at no cost.
Antoine Poinsot
CC BY-SA 4.0
2024-08-06T19:45:43.917Z
2024-09-03T14:00:31.920Z
2024-09-03T14:00:31.920Z
Antoine Poinsot
<p>A new block is being relayed from node <em>A</em> to <em>B</em> to <em>C</em> using <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow noreferrer">BIP152</a> compact block's high-bandwidth mode, which allows relaying a block after only validating its header proof-of-work.  When node <em>B</em> receives the compact block, it's missing some transactions, so node <em>B</em> can't reconstruct the block immediately.  It has to request the missing transactions from node <em>A</em>.</p>
<p>Before <em>B</em> has received the missing transactions, is it possible for it to announce the block to node <em>C</em>?</p>
<p>My understanding is that this is impossible.  The compact block that node <em>B</em> receives only references the missing transactions by their BIP152 <code>shortid</code>, which is generated from each transaction's txid in a way that is specific to each connection (preventing third parties from increasing collision risk).  Since node <em>B</em> is missing the transactions, it also doesn't know their txids, so it is unable to create shortids for them for sending a compact block to node <em>C</em>.</p>
<p>That means, even if node <em>C</em> has the transactions that node <em>B</em> is missing, it will not receive a compact block announcement until node <em>B</em>'s transaction request has completed its round trip.  (Of course, this assumes that node <em>C</em> only receives new blocks from node <em>B</em>.)  That seems to imply that the propagation latency reduction of high-bandwidth mode skipping full validation before relay is largely lost when a block includes transactions that are not widely available.</p>

CC BY-SA 4.0
2024-08-05T15:56:27.217Z
I'll let someone more familiar with the topic formulate a proper answer but i think doing so would open a DoS vector since you wouldn't be able to verify the proof of work at all (and BIP152 explicitly proscribes it). It is also my understanding latency gains are largely lost when most nodes don't already have most transactions.
Antoine Poinsot
CC BY-SA 4.0
2024-08-06T13:02:13.290Z
@AntoinePoinsot That sounds exactly right. Want to turn it into an answer?
Pieter Wuille
CC BY-SA 4.0
2024-08-06T13:34:52.577Z
Sure, will do! [space for minimum characters count]
Antoine Poinsot
<block-propagation-time><compact-blocks>
Can a BIP152 compact block be sent before validation by a node that doesn't know all transactions?
David A. Harding
# Can a BIP152 compact block be sent before validation by a node that doesn't know all transactions?

(Asked by: username_0 on 2024-08-05)

A new block is being relayed from node *A* to *B* to *C* using [BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) compact block's high-bandwidth mode, which allows relaying a block after only validating its header proof-of-work. When node *B* receives the compact block, it's missing some transactions, so node *B* can't reconstruct the block immediately. It has to request the missing transactions from node *A*.

Before *B* has received the missing transactions, is it possible for it to announce the block to node *C*?

My understanding is that this is impossible. The compact block that node *B* receives only references the missing transactions by their BIP152 `shortid`, which is generated from each transaction's txid in a way that is specific to each connection (preventing third parties from increasing collision risk). Since node *B* is missing the transactions, it also doesn't know their txids, so it is unable to create shortids for them for sending a compact block to node *C*.

That means, even if node *C* has the transactions that node *B* is missing, it will not receive a compact block announcement until node *B*'s transaction request has completed its round trip. (Of course, this assumes that node *C* only receives new blocks from node *B*.) That seems to imply that the propagation latency reduction of high-bandwidth mode skipping full validation before relay is largely lost when a block includes transactions that are not widely available.

**Tags:** block-propagation-time, compact-blocks

> **Comments:**
> **username_1**: I'll let someone more familiar with the topic formulate a proper answer but i think doing so would open a DoS vector since you wouldn't be able to verify the proof of work at all (and BIP152 explicitly proscribes it). It is also my understanding latency gains are largely lost when most nodes don't already have most transactions.  
> **username_2**: @username_1 That sounds exactly right. Want to turn it into an answer?  
> **username_1**: Sure, will do! [space for minimum characters count]  

---

## 1 answers

### Answer by username_1 on 2024-08-06. Score: 4 | Accepted answer

B forwarding to C before having received all transactions means forwarding before validating the proof of work, which would open a DoS vector. [BIP152 explicitly proscribes](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#cmpctblock) doing so:

> A node MUST NOT send a cmpctblock message **without having validated that the header properly commits to each transaction in the block**, and properly builds on top of the existing, fully-validated chain with a valid proof-of-work either as a part of the current most-work valid chain, or building directly on top of it.

With regard to the impossibility for B to construct a compact block announcement to C due to the shortIDs calculation, my understanding is that it is not correct. B can just reuse the same nonce A used in the original announcement. Technically, I think B can just forward the very same `cmpctblock` message it received from A.

It is also my understanding that the latency reduction, along with the bandwidth savings, are largely lost when most nodes don't have most transactions.

> **Comments:**
> **username_0**: Is this the DoS vector: A receives a valid block; A uses that valid block's header PoW to send B an invalid block (e.g. by swapping a valid shortid for a made-up shortid) with missing transactions; B forwards that invalid block to its peers, wasting bandwidth, memory, and CPU.  The invalid block will potentially propagate across BIP152 high-bandwidth connections faster than the actual valid block for that header propagates. With the requirement to verify the merkle tree means the only way an invalid block can propagate is if that's what the miner produced, meaning they'll lose the block reward  
> **username_1**: Yes, as nodes are eager to process and share blocks if they didn't validate the PoW you could make the network aggressively broadcast tons of invalid data at no cost.  

---

