BIP-376: The Missing Piece for Silent Payments in Hardware Wallets
Silent Payments arrived in Bitcoin Core 28.0 with a promise: static addresses that don’t compromise your privacy. You can publish one address and receive unlimited payments without creating a traceable chain of on-chain links. For privacy advocates, this is exactly what Bitcoin should have been from the start.
But there’s been a problem holding back mainstream adoption. Hardware wallets couldn’t support spending from Silent Payment outputs. You could receive funds privately, but spending them meant trusting a hot wallet with your keys. That’s not a tradeoff most serious Bitcoin users are willing to make.
BIP-376 solves this. Assigned as a Draft BIP on February 5, 2026, it defines the standardized PSBT fields that hardware wallets need to safely sign transactions spending Silent Payment outputs. No more choosing between privacy and security.
The spending problem
Silent Payments use clever cryptography to make every on-chain output unique while keeping your receiving address static. When someone sends to your Silent Payment address, they perform an Elliptic Curve Diffie-Hellman (ECDH) operation that creates a one-time output key. You can detect these payments by scanning the blockchain, but spending them requires something special: a unique tweak value that was computed when the output was created.
To spend a Silent Payment output, your wallet needs to:
- Retrieve your base spend private key
- Add the unique tweak for that specific output
- Check the parity of the resulting key
- Sign with the adjusted key
Hardware wallets are built for security, not computation. They’re air-gapped devices with no access to blockchain history. They can’t scan for previous transactions or recompute tweaks on the fly. Without a standardized way for wallet software to pass this tweak data to the hardware device, Silent Payments simply won’t work.
Before BIP-376, each hardware wallet vendor would need to create proprietary extensions. That’s a recipe for fragmentation, security holes, and slow adoption.
Two new PSBT fields
BIP-376 introduces two new per-input fields for PSBTv2 (the modern PSBT standard):
PSBT_IN_SP_TWEAK carries the 32-byte scalar value that must be added to your spend key. This is the output-specific tweak computed using the BIP0352/SharedSecret tagged hash. It’s not the same as a taproot script tree tweak, which is why existing PSBT fields won’t work.
PSBT_IN_SP_SPEND_BIP32_DERIVATION tells your hardware wallet how to derive the base spend key from your BIP32 seed. The key data is a 33-byte compressed public key (not the 32-byte x-only keys used elsewhere in taproot). This extra byte matters: Silent Payments need to preserve parity information to correctly derive signing keys.
When your wallet coordinator (like Sparrow or Electrum) constructs a transaction spending Silent Payment outputs, it adds these two fields to each relevant input. Your hardware wallet reads them, derives the signing key, and produces a valid Schnorr signature.
The security critical part
Here’s the part that makes this whole scheme safe: hardware wallets must verify that the tweak is correct before signing.
The coordinator provides the tweak value, but what if it’s wrong? What if malicious software tries to trick your hardware wallet into signing for an attacker’s key?
BIP-376 requires that the signing device compute d·G (where d is the derived signing key) and verify that its x-coordinate matches the output key from the UTXO being spent. If they don’t match, the device refuses to sign. This simple check (one elliptic curve multiplication) prevents an entire class of attacks where compromised wallet software tries to redirect funds.
This verification step is mandatory. A hardware wallet that skips it isn’t BIP-376 compliant.
Why this matters now
BIP-375 already handles sending to Silent Payment addresses via PSBT. That’s nice for software wallets, but hardware wallets don’t need special support just to send. They need it to spend.
Without BIP-376, Silent Payments remain locked in the hot wallet ecosystem. With it, hardware wallet vendors have a clear specification to implement. That means:
- Users can hold Silent Payment balances on cold storage
- Privacy doesn’t require sacrificing security
- Interoperability across wallet software and hardware devices
Several hardware wallet vendors have already announced Silent Payments support plans. BitBox02 made their announcement in 2024. Sparrow Wallet has an active bounty for Silent Payments integration. The pieces are coming together, and BIP-376 is the last major blocker.
Review progress and timeline
The proposal is in active review. Craig Raw (Sparrow Wallet maintainer), Murch (Bitcoin Core contributor), and other experienced PSBT developers have provided detailed feedback. The author, nymius, has been responsive and incorporated suggestions quickly.
The main areas of refinement have been around the Signer and Finalizer role specifications. Earlier drafts didn’t clearly specify the mandatory tweak verification or the cleanup procedures after signing. Those gaps are now filled.
What’s still missing: test vectors and a reference implementation. Both are marked as TODO in the BIP text. These will likely arrive before the proposal moves from Draft to final status, but the core technical design is solid.
Given the pace of review and the clear demand from hardware wallet vendors, I’d expect BIP-376 to reach completion within the next 6 to 12 months.
The bigger picture
Bitcoin’s privacy story has always been complicated. Address reuse is bad, but managing fresh addresses for every payment is awkward. CoinJoin helps, but requires coordination. Silent Payments offer a different path: privacy that’s built into the protocol, requires no interaction between sender and receiver, and creates no additional on-chain overhead.
But privacy features that only work in hot wallets are niche at best. For Silent Payments to become a mainstream privacy tool, they need to work with the security tools people already trust. Hardware wallets are that tool.
BIP-376 bridges the gap. It’s a small technical proposal (just two PSBT fields), but its impact is large. Once implemented, users won’t have to choose between privacy and security. They can have both.