AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 32 Bitcoin

Explain how MAX_CACHED_DERIVATIONS was chosen and test the cap

Public commit record

What the developer wrote

Authored by kdmukai

83/100 · Strong
Explain how MAX_CACHED_DERIVATIONS was chosen and test the cap

The cap was documented as a bound a real wallet would never approach.
That is backwards: a 3-of-5 multisig -- the largest common policy --
consolidating 200 inputs wants more cached levels than the cap allows.

That case is the watermark the number comes from. Record it, what the
cache costs at that size, and what going over means: the psbt still
parses correctly, it may just derive some levels more than once.

Nothing checked that last claim. Parse a multisig and a single-sig psbt
with the cache free to grow, then again with the cap low enough to fill
partway through, and require identical parser state. Assert the cap was
actually reached, so removing the cap outright fails the test rather
than passing it quietly.

Compare the two parses through a new assert_same_parse_result helper,
which checks field by field so a failure names the field that differs.
test_cache_does_not_change_parse_output still hand-rolls the same
comparison as a tuple of fields and should be moved onto the helper in
a follow-up.

Also give PSBTParser a class docstring; the cap comment had grown large
enough to read as one.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a documentation and testing improvement for an existing safety cap in the PSBT parser. It does not change the cap's value or behavior; it explains why the cap exists (to stop a malicious PSBT from consuming unbounded memory), adds a test proving that hitting the cap does not corrupt the parse result, and clarifies that the cap was chosen based on a realistic large multisig transaction. There is no new vulnerability being fixed here, but the change makes the existing defense easier to understand and verify.

Recommended action

No immediate action required. Treat as routine hardening/quality improvement. Reviewers may want to confirm that the new test actually exercises the cap by running tests and checking that removing the cap causes the assertion to fail as claimed.

Security signals we found

01

Existing resource-limiting cap is documented as a defense against maliciously crafted PSBTs causing unbounded memory growth

02

New regression test verifies that cache exhaustion does not alter parse output

03

No change to cap value or derivation logic; behavior-preserving documentation/test commit

Risk score

Why this scored 32/100

Our methodology →
Potential impact 5/30
Exploitability 4/25
Stealth signal 6/15
Affected reach 5/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.