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

feat: implement silent payment derivation paths and master HD wallet integration (#2708)

Public commit record

What the developer wrote

Authored by Konstantin Ullrich

93/100 · Strong
feat: implement silent payment derivation paths and master HD wallet integration (#2708)

* feat: implement silent payment derivation paths and master HD wallet integration

- Added default derivation paths for silent payments (mainnet and testnet).
- Introduced `_masterHD` for handling seed-based key derivations.
- Updated silent payment address record to include spend derivation path.
- Refactored UTXO handling and scanning logic to support multiple receivers with unique derivation paths.
- Improved logging for better debugging of silent payment workflows.

* refactor: remove debug prints
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds support for Bitcoin "silent payments" in Cake Wallet. It introduces new derivation paths for scanning and spending, stores a spend derivation path on each silent payment address record, and changes how private keys are derived when spending silent-payment UTXOs. The change is a feature implementation/refactor rather than a clearly labeled security fix. There is no direct evidence in the commit that it fixes an active vulnerability, but it touches sensitive key-derivation and UTXO-handling code, so correctness matters for funds safety.

Recommended action

Treat this as a high-sensitivity code change requiring focused review and regression testing of silent payment scanning and spending. Verify that: (1) the new derivation paths match the intended BIP-352 specification for the correct network; (2) the default testnet fallback for `spendDerivationPath` cannot cause mainnet wallets to derive/record testnet paths; (3) scanning both mainnet and testnet receivers does not leak metadata or produce false-positive UTXOs; (4) the tweak-add operation uses the correct private key and cannot be tricked by a malformed tweak; (5) existing silent payment address records deserialize safely and remain spendable. Consider requesting test vectors or a security write-up from the vendor.

Security signals we found

01

Silent payment key derivation paths added and used for scan/spend private keys

02

Spend private key derivation moved from `silentAddress.b_spend.tweakAdd` to `_masterHD.derivePath(spendDerivationPath).tweakAdd(tweak)`

03

Two receivers (mainnet and testnet derivation paths) are both scanned regardless of current network

04

New `spendDerivationPath` field persisted in address JSON records with a testnet default fallback

05

Large amount formatting switched from int to BigInt, potentially preventing overflow-related formatting issues

Risk score

Why this scored 29/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 4/10
Evidence quality 2/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.