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

payjoin address getter fix (#3191)

Public commit record

What the developer wrote

Authored by malik1004x

76/100 · Adequate
payjoin address getter fix (#3191)

* payjoin address getter fix

* fix payjoin getter address type

* Update cw_bitcoin/lib/electrum_wallet_addresses.dart

---------

Co-authored-by: Omar Hatem <omarh.ismail1@gmail.com>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes how Cake Wallet picks the Bitcoin address used when receiving a Payjoin transaction. Previously it used the wallet's default 'primary address', which could be a Silent Payment or Lightning address type that Payjoin does not support. The change adds a new getter that falls back to a standard Segwit address when the primary address type is incompatible. If left unfixed, Payjoin receivers might hand the sender an address the Payjoin protocol cannot handle, likely causing the Payjoin session to fail or fall back to a normal payment, potentially leaking privacy or losing Payjoin's fee-bumping benefits.

Recommended action

Review the Payjoin manager to confirm it validates or rejects unsupported address types defensively, and add tests covering Silent Payment and Lightning address wallets to ensure Payjoin receiver derivation always produces a compatible address. Consider documenting the supported address types for Payjoin in user-facing or developer docs.

Security signals we found

01

Incorrect address type selection for Payjoin receiver initialization

02

Potential protocol incompatibility between Payjoin and Silent Payment / Lightning address types

03

Privacy/fee-obfuscation degradation if Payjoin falls back to non-Payjoin transaction

04

No explicit security disclosure or CVE referenced in commit metadata

Risk score

Why this scored 42/100

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