You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In compact block opportunistic reconstruction we have a comment above the MarkBlockAsReceived call:
// Clear download state for this block, which is in
// process from some other peer. We do this after calling
// ProcessNewBlock so that a malleated cmpctblock announcement
// can't be used to interfere with block relay.
That's great and all, but we don't have anything similar in ::BLOCK handling. Thus, if you have a compact block blocktxn request in-flight from one peer, another peer can send you a malleated block as a regular block message causing the in-flight state to be cleared. That peer will get banned, so its a one-time block propagation slowdown (and shouldn't even be all that much of a slowdown), but worth noting. Writing it up primarily cause it should be considered in some eventual in-flight-blocks refactoring in conjunction with a #10984 rebase.
The text was updated successfully, but these errors were encountered:
In compact block opportunistic reconstruction we have a comment above the MarkBlockAsReceived call:
That's great and all, but we don't have anything similar in ::BLOCK handling. Thus, if you have a compact block blocktxn request in-flight from one peer, another peer can send you a malleated block as a regular block message causing the in-flight state to be cleared. That peer will get banned, so its a one-time block propagation slowdown (and shouldn't even be all that much of a slowdown), but worth noting. Writing it up primarily cause it should be considered in some eventual in-flight-blocks refactoring in conjunction with a #10984 rebase.
The text was updated successfully, but these errors were encountered: