3

A new block is being relayed from node A to B to C using BIP152 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.

Improve this question
3
  • 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.
    – Antoine Poinsot
    Commented Aug 5 at 15:56
  • 1
    @AntoinePoinsot That sounds exactly right. Want to turn it into an answer?
    – Pieter Wuille
    Commented Aug 6 at 13:02
  • 1
    Sure, will do! [space for minimum characters count]
    – Antoine Poinsot
    Commented Aug 6 at 13:34

1 Answer 1

Reset to default
4

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 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.

Improve this answer
2
  • 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
    Commented Aug 7 at 1:43
  • 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
    Commented Aug 7 at 6:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.