bip bip-376 privacy silent-payments psbts hardware-wallets

BIP376: Spending Silent Payment Outputs with PSBTs — Making Privacy Practical

Bitcoin Index · · 7 min read
BIP376: Spending Silent Payment Outputs with PSBTs — Making Privacy Practical

Silent Payments are elegant. You publish one static address, people send you Bitcoin, and every payment lands at a unique on-chain address with no interaction required. No address reuse, no notification transactions, no privacy leak. Just cryptographic magic.

But there’s been a catch: spending those outputs. If your hardware wallet can’t safely spend your silent payment funds, the whole system stays theoretical. You might get paid privately, but you’re stuck with a hot wallet to spend it.

BIP376, currently in review, fixes this. It defines how to spend silent payment outputs using Partially Signed Bitcoin Transactions (PSBTs), the standard interface between software wallets and hardware signers. With BIP376, your Ledger or Coldcard can spend silent payments as easily as any other UTXO, with full verification and no trust in the host computer.

This is the missing piece of the silent payments stack.

The three-BIP architecture

To understand BIP376, you need to see the full picture. Silent payments aren’t one BIP. They’re a system.

BIP352: Silent Payments (merged)
The core protocol. Defines how senders derive unique taproot addresses from a static, reusable silent payment address using Elliptic Curve Diffie-Hellman (ECDH). The receiver scans the blockchain to detect payments.

BIP375: Sending Silent Payments with PSBTs (merged)
Specifies how to create silent payment outputs in a PSBT workflow. Introduces fields for ECDH shares and DLEQ proofs so collaborative signing (multisig, coinjoin) works without trusting other participants.

BIP376: Spending Silent Payment Outputs with PSBTs (draft)
The new piece. Standardizes how to spend silent payment outputs in a PSBT workflow, with mandatory verification to prevent theft.

Together, these three BIPs cover the full lifecycle: sending, receiving, and spending. BIP376 is the final link.

The problem: Hardware wallets need standards

When you spend a silent payment output, you need more than just your base private key. You need the tweak that was applied when the payment was received.

Here’s the math: when someone sends you a silent payment, they compute a shared secret using ECDH, then tweak your public spend key to create a unique output address. To spend that output, you need to apply the same tweak to your private spend key.

The formula (simplified):

signing_key = base_spend_key + tweak

In a hot wallet, this is straightforward. The wallet computed the tweak during scanning and stored it alongside the UTXO. When spending, it retrieves the tweak and derives the signing key.

But in a PSBT workflow, the entity creating the transaction (the Updater) and the entity signing it (the Signer, often a hardware wallet) are separate. The hardware wallet needs to:

  1. Receive the tweak from the host
  2. Verify the tweak is correct (not malicious)
  3. Derive the signing key
  4. Sign the transaction

Without a standard, every wallet implementation would do this differently. Hardware vendors wouldn’t know what to support. Interoperability would be impossible.

That’s the gap BIP376 fills.

How BIP376 works

BIP376 introduces two new PSBT fields for inputs spending silent payment outputs:

1. PSBT_IN_SP_TWEAK

Purpose: Carries the 32-byte tweak value

This is the same tweak computed when the payment was received. Per BIP352, it’s derived from the shared secret between sender and receiver, plus any label used to organize payments.

The Updater (typically your software wallet) retrieves this from storage and adds it to the PSBT.

2. PSBT_IN_SP_SPEND_BIP32_DERIVATION

Purpose: Tells the Signer which private key to use for the base spend key

Contains the master key fingerprint and BIP32 derivation path. The Signer (hardware wallet) uses this to derive the base spend private key from its seed.

Why a new field? Silent payments use 33-byte compressed keys (with Y-coordinate parity), not the 32-byte x-only keys taproot uses. Existing taproot fields aren’t compatible.

The spending flow

  1. Updater (software wallet) creates a PSBT spending a silent payment output

    • Adds PSBT_IN_SP_TWEAK with the stored tweak
    • Adds PSBT_IN_SP_SPEND_BIP32_DERIVATION with the spend key derivation path
    • Sends PSBT to hardware wallet

  2. Signer (hardware wallet) receives the PSBT

    • Derives base spend private key using BIP32 path
    • Computes signing_key = base_spend_key + tweak
    • Verifies the tweak (critical security step)
    • Signs if verification passes

  3. Finalizer cleans up temporary fields and produces the final transaction

The magic is in step 2. The verification step ensures the hardware wallet isn’t tricked into signing for the wrong key.

The security feature: Mandatory tweak verification

Here’s why verification matters.

Attack scenario without verification:

  1. Malicious software creates a PSBT spending your silent payment output
  2. Software provides a fraudulent tweak corresponding to the attacker’s key
  3. Hardware wallet blindly computes signing_key = your_key + malicious_tweak
  4. Hardware wallet produces a valid signature
  5. Attacker broadcasts the transaction and steals your funds

The hardware wallet just signed for a key it doesn’t control.

Defense: Before signing, the hardware wallet computes P' = signing_key · G (multiply the signing key by the generator point) and verifies the x-coordinate matches the output key P from the UTXO being spent.

This check is cheap (one elliptic curve multiplication) and proves the tweak is legitimate. If the check fails, the hardware wallet refuses to sign.

From the BIP:

“Without verification, the Signer would produce a valid Schnorr signature for a key it does not control, which could be used to steal funds. Verifying that the tweaked key matches the output key ensures the Signer is signing for the expected output.”

This is defensive cryptographic protocol design at its best. The verification step costs almost nothing but prevents a serious attack.

Current status: In active review

BIP376 was assigned on February 5, 2026 and is currently in draft status. The author, nymius, is a Bitcoin Dev Kit (BDK) contributor.

Recent development: On March 6, 2026, Craig Raw (creator of Sparrow Wallet) provided detailed technical review, leading to specification improvements:

  • Added explicit Signer and Finalizer role specifications
  • Made tweak verification mandatory with security rationale
  • Clarified field descriptions and corrected typos

Craig’s involvement is significant. Sparrow is the reference wallet for Bitcoin power users and privacy-focused workflows. If Craig is satisfied with the spec, it’s a strong signal the design is solid.

What’s next:

  • Test vectors (marked as TODO in the BIP)
  • Reference implementations (likely in BDK and Sparrow)
  • Hardware wallet vendor adoption

What this unblocks

Hardware wallet integration

Ledger, Trezor, Coldcard, and BitBox02 can all support silent payment spending with confidence. No need for each vendor to invent their own scheme.

Multisig workflows

Coordinators like Sparrow, Specter, and Nunchuk can support silent payment multisig spends (single-key spends for now; collaborative spends are future work).

Watch-only wallets

Services like BTCPay Server can create unsigned PSBTs for silent payment spends, then pass them to hardware signers.

Cross-wallet compatibility

A PSBT created by one wallet can be signed by a hardware wallet from a different vendor. Interoperability is the point.

Why silent payments matter

Bitcoin users face a privacy trilemma:

  1. Privacy: Avoid address reuse and payment linkability
  2. Usability: No sender-receiver interaction required
  3. Cost: No on-chain overhead or scanning burden

Traditional approaches make you pick two:

  • Unique addresses per payment: High privacy, but requires interaction (sender must request a fresh address)
  • Reusable payment codes (BIP47): No interaction, but on-chain notification transactions leak metadata and cost fees
  • Address reuse: No interaction, no cost, zero privacy

Silent payments solve this by using cryptographic derivation instead of on-chain notifications. You publish one static address. Senders derive unique output addresses using ECDH. You scan the blockchain to detect payments.

The trade-off: Scanning is computationally expensive. Light clients need either server assistance or block filters. But for users who can scan (or delegate scanning to a trusted server), silent payments offer the best privacy-usability combination available.

BIP376 makes this practical by ensuring you can spend your funds using the same hardware wallet you use for everything else. No compromises.

The bigger picture

Silent payments are still niche. As of March 2026, adoption includes:

  • Receiving: Bitcoin Core (experimental), Cake Wallet, Nunchuk (added Feb 2026)
  • Sending: Draft merged January 2025, implementations in progress
  • Spending: BIP376 in review, no public implementations yet

But the infrastructure is coming together. BIP352 (core spec), BIP375 (sending), BIP376 (spending), and BIP392 (descriptors) form a complete system.

Once hardware wallets adopt BIP376, the full send-receive-spend cycle becomes seamless. Users can:

  1. Publish a static silent payment address in their bio or on a donation page
  2. Receive payments automatically with full privacy
  3. Spend using their hardware wallet with verification and security

No interaction. No on-chain overhead. No address reuse. Just privacy by default.

Looking ahead

Expect BIP376 to merge in Q2 2026 after test vectors and reference implementations land. Hardware wallet support will follow 6-12 months later (vendors are conservative). BitBox02 might be first given their early silent payment support announced in September 2024.

For now, silent payments remain a tool for enthusiasts and high-privacy-requirement users. But BIP376 removes a major barrier. Hardware wallet support is the difference between “technically possible” and “practically usable.”

And in Bitcoin, usability determines adoption.

Sources: BIP376 Pull Request (GitHub), BIP352: Silent Payments, BIP375: Sending Silent Payments with PSBTs, BIP392: Silent Payment Output Script Descriptors, Craig Raw’s Review Comments (March 6, 2026), BitBox02 Silent Payment Support Announcement. Data/status as of March 2026.