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
This PR extends mutation checks originally introduced in PR #29412, which prevented immediate processing of mutated blocks received via the legacy BLOCK message. The new change applies the same protection to compact blocks during PartiallyDownloadedBlock::FillBlock, just before returning READ_STATUS_OK.
This acts as a belt-and-suspenders safeguard against potential mutation-based attacks during block relay by honest peers. It introduces a behavior change: if a compact block decodes successfully but fails mutation checks, the peer is now disconnected and discouraged rather than the block being silently discarded.
Prerequisites
p2p
Notes and Questions
What is CheckBlockFn and IsBlockMutatedFn ? How are they helpful ?
What Does DeploymentActiveAfter function checks and how is it important for systems like Bitcoin ?
What does FillBlock does ?
Preparation Steps
Clone the Bitcoin Core repository if you haven't already:
What is CheckBlockFn and IsBlockMutatedFn ? How are they helpful ?
They are the name of important function signatures that we use . These helps in improved readability , less complex code and enables us to allow different implementations of the same function signatures where we would have had to write separate functions instead.
What Does DeploymentActiveAfter function checks and how is it important for systems like Bitcoin ?
In projects like Bitcoin , it is necessary that important events like Consensus changes are tagged and stored somewhere else to used . DeploymentActiveAfter is one such function where important consensus changes are tagged with the block number they were deployed at which is useful to check if the block we are querying was mined after the consensus was deployed or before.
What does FillBlock does ?
FillBlock fills the PartiallyDownloadedBlock with the transactions that we give which are obtained from our own mempool .
This discussion was converted from issue #122 on June 07, 2025 09:32.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Bitcoin Core PR Review Club
Session Details
PR Summary
This PR extends mutation checks originally introduced in PR #29412, which prevented immediate processing of mutated blocks received via the legacy BLOCK message. The new change applies the same protection to compact blocks during PartiallyDownloadedBlock::FillBlock, just before returning READ_STATUS_OK.
This acts as a belt-and-suspenders safeguard against potential mutation-based attacks during block relay by honest peers. It introduces a behavior change: if a compact block decodes successfully but fails mutation checks, the peer is now disconnected and discouraged rather than the block being silently discarded.
Prerequisites
p2p
Notes and Questions
CheckBlockFnandIsBlockMutatedFn? How are they helpful ?DeploymentActiveAfterfunction checks and how is it important for systems like Bitcoin ?FillBlockdoes ?Preparation Steps
Clone the Bitcoin Core repository if you haven't already:
Fetch and checkout the PR:
Build and run tests (if applicable):
Review the code changes and consider the provided questions.
Joining the Session
The Jitsi link will be shared in the #announcements channel of the Bitshala Discord shortly before the session.
Looking forward to seeing you there!
All reactions