[limpbrains]

Why

isPaymentCodeValid too loose, createTransaction decodes on its own:

• any hrp passes: tsp1…, foo1… with valid checksum → true
• uppercase SP1… → valid, but createTransaction checks startsWith("sp1") case-sensitive and passes it through as regular address. Uppercase is common in BIP21 QR codes
• B_scan / B_m not checked to be points, error only later in createTransaction
• versions: BIP-352 says v1-30 → read first 66 bytes, ignore rest; v31 reserved. We rejected all non-0

How

New SilentPayment.decodePaymentCode(pc) → { Bscan, Bm } or throws:

• reject mixed case, then lowercase
• hrp must be sp (lib is mainnet only: pubkeyToAddress uses networks.bitcoin)
• version: 0 → exactly 66 bytes, 1-30 → at least 66, 31 → error
• ecc.isPoint for both keys

isPaymentCodeValid and createTransaction both use it. Tests for each case + uppercase createTransaction gives same output as lowercase. New tests fail on master.

npm test (105 passed), typecheck, prettier green.

Summary by CodeRabbit

• New Features
  • Payment codes using the sp prefix are now recognized without regard to letter case, and supported code versions can be validated.
• Bug Fixes
  • Payment-code validation now rejects mixed-case codes, unsupported prefixes and versions, malformed payloads, and invalid scan or spend points.
  • Uppercase and lowercase forms of the same valid payment code now produce matching transaction results.

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: e6ea08ac-61c8-42a9-8868-4fc36bab9889

Commits

Reviewing files that changed from the base of the PR and between f04948c and d436ec1.

Files selected for processing: 2

• src/index.ts
• tests/silent-payment.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

Walkthrough

SilentPayment adds a decoder that validates payment-code prefixes, casing, versions, payload lengths, and scan and spend points. isPaymentCodeValid now uses this decoder. Transaction creation uses it to recognize uppercase payment-code prefixes. Tests cover decoder validation and compare transaction outputs for uppercase and lowercase forms.

Suggested reviewers: overtorment

Priority: Normal

Merge Risk: Minimal · up to d436e

No merge-blocking issue was identified.

Pre-merge checks: 5

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly summarizes the main change: stricter validation of silent payment code prefixes, case, versions, and keys.
Docstring Coverage		No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Documentation-only edits and deletions within survi…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 2 files.

Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Overtorment]

Checked the decoder against BIP-352 (bech32m with a 1023 limit, hrp sp, v0 exactly 66 bytes, v1-30 first 66 bytes, v31 rejected, both keys checked as points) and it looks right. Tests, typecheck and prettier pass locally. One heads-up about the BlueWallet side before we bump the dependency there.

[Overtorment]

Heads-up for when we bump this in BlueWallet: isPaymentCodeValid("SP1…") now returns true, but BlueWallet still does case-sensitive startsWith('sp1') in SendDetails.tsx (the allowSilentPaymentSend gate) and in AbstractHDElectrumWallet.createTransaction (hasSilentPaymentOutput). So an uppercase code gets past validation, skips the wallet-capability check, never goes through sp.createTransaction, and then fails in psbt with SP1… has no matching Script. It doesn't lose funds, but it's a confusing failure, and wallets that can't send SP don't get the proper error.

This lib is fine as it is. The bump PR needs to lowercase the address (or use .toLowerCase().startsWith('sp1')) in those two places. Alternatively, export a small isSilentPaymentCode(address) helper from here so the prefix check lives in one place.

[Overtorment]

LGTM. The uppercase SP1 note is non-blocking and can be handled on the BlueWallet side when bumping the dependency.

[limpbrains]

LGTM. The uppercase SP1 note is non-blocking and can be handled on the BlueWallet side when bumping the dependency.

This library now depends on tiny-secp256k1 v2 (WASM)
We can't use it directly in BW
So for BW I've backported this check here

I think we should probably refactor this library to make ecc implementation pluggable, like bitcoinjs does. WDYT ?