Silent Reusable Payment Addresses (SRPA)

Technical
,
#1

I would like to discuss the possibility of implementing a feature similar to a stealth identity for wallets, where payments can be received using the same QR code, address, or URIs. For this proposal, we could refer to this feature as the “Silent RPA” mode that’s compatible with CashFusion for Bitcoin Cash wallets that:

  1. Receives all payments on one-time addresses derived via ECDH from a static SRPA public key (stealth-address logic similar to BIP352, but using BCH’s existing P2PKH/P2PKT scripts rather than Taproot).

  2. Feeds those UTXOs into CashFusion, with all fusion outputs (including change) sent to fresh SRPA-derived addresses.

  3. Sends to third parties using the same ECDH derivation against the recipient’s SRPA public key.

The result is a wallet living entirely in “SRPA space” infinite receive → fuse → send cycles, with full compatibility with existing CashFusion rounds and HD-wallet participants.

Motivation

  • Maintain CashFusion interoperability: fusion transactions byte-for-byte identical, regardless of participant type.

  • Silent Payments enhance stealth addresses by eliminating all on-chain hints or metadata linking sender and receiver upfront, preventing the creation of identifiable trails to begin with.

  • Bring Monero-style privacy to BCH without adding confidential-amount layers where our chain arithmetic calculation of the supply remains fully auditable.

Specification

  1. SRPA Keypair
  • Wallet holds a static keypair (sk, PK = sk·G).
  • Backup: sk plus last-scanned block height.
  1. One-Time Address Derivation (BIP352-style)

For any chosen input UTXO with ephemeral pubkey P_in:

shared = ECDH(P_in, sk)                   # = P_in · sk  
addr_bytes = HASH(shared ∥ “srpa”)        # domain separation  
one_time_script = standard_P2PKH(addr_bytes)
  1. Receive Flow
  • Sender uses the above derivation (analogous to BIP352) to compute your one-time address.
  • Wallet scans every new block’s inputs, computes shared for each P_in, and detects UTXOs to its one-time scripts.
  1. CashFusion Integration
  • Fusion rounds include SRPA and HD participants interchangeably.
  • All fusion outputs (including change) are generated via the ECDH derivation above.
  • On-chain txs remain standard CashFusion format (identical scripts and values).
  1. Send Flow
  • To pay another SRPA user, pick any fused UTXO’s input P_in, derive the recipient’s one-time address via the same function, and build the tx.

Backward Compatibility

  • No protocol changes: CashFusion tx format and script templates unchanged.
  • Standard wallets ignore SRPA outputs.
  • SRPA wallets track both SRPA and HD outputs, mixing seamlessly with non-SRPA users.

Deployment

  • Opt-in “Full Silent RPA Mode” in Electron Cash (or other wallets).
  • No consensus upgrade required wallet-level only.
  • Testnet rollout first; use compact Neutrino-style filters for faster input scanning. Scanning performance via Bloom or Golomb filters (e.g., Neutrino).

Disadvantages

  • Wallet recovery: if you lose sk, re-scan from the genesis block.

Mitigation and improvement for better UX

  • Optional Prefix & Suffix Filtering for light client as defined in the RPA spec by im_imaginaryusername, wallets may optionally support the prefix_size field (0, 4, 8, 12, or 16 bits) encoded in the paycode: string to embed that many bits of the shared-secret hash in each output allowing receivers to scan only 2^prefix_size × fewer inputs (e.g. ~256× fewer with an 8-bit prefix) at the cost of a proportionally smaller anonymity set. Wallets should also parse any URI suffix parameters to configure off-chain relay methods. Implementations must ignore unknown or reserved fields for forward compatibility. Both features should be exposed as advanced, opt-in toggles in the UI (e.g. “Fast Scan (prefix filter)” and “Off-chain Relay Settings”) with clear disclosure of the privacy vs usability trade-offs.

Reference

  1. RPA Proposal Draft
  2. BIP352 - Silent Payment
2 Likes
#3

For Wallets implementing merge avoidance they should strictly disable it when both SRPA and CashFusion are active. inspired by Ryan X. Charles.

[Receive logic] - HD or SRPA derivation
[UTXO pool] - all outputs, labeled (e.g. SRPA, HD)
[Spend logic] - context-aware merge avoidance toggle

In this design:

  • SRPA outputs are tracked and labeled distinctly from HD outputs.
  • Merge avoidance is an important privacy layer that prevents UTXO merging during normal spending, preserving unlinkability. However, because CashFusion requires merging UTXOs to create strong anonymity sets, merge avoidance must be disabled when both SRPA and CashFusion are active, allowing SRPA outputs to participate fully in fusion.
  • Once CashFusion is off, merge avoidance should be re-enabled to protect privacy during normal spends.

The wallet toggle logic can be summarized as:

if SRPA_enabled and CashFusion_enabled:
    merge_avoidance = False  # Disable merge avoidance to allow fusion merging
elif SRPA_enabled or standard_HD:
    merge_avoidance = True   # Enable merge avoidance to protect unlinkability
else:
    merge_avoidance = False  # Default off when neither applies

Where SRPA privacy is preserved outside fusion rounds while CashFusion mixing is fully effective by allowing necessary merges. Wallet behavior remains clear, simple, without degrading privacy.