Silent Payments Gets a Security Patch: BIP-352 Limits Outputs to Prevent DoS Attack | Bitcoin Index

Bitcoin’s Silent Payments protocol just got a quiet but important security patch. On March 2, 2026, BIP-352 was updated to version 1.1.0 with a change that prevents a denial-of-service attack most users will never see, but could have made the protocol unusable if exploited.

The fix introduces K_max, a limit on how many outputs a single transaction can create for one recipient. The cap is set at 2,323, a number that sounds arbitrary until you understand the math behind it.

What are Silent Payments?

Before diving into the fix, here’s the problem Silent Payments solve: Bitcoin addresses are meant to be single-use for privacy. Reusing an address links all your transactions together on the public blockchain. But generating fresh addresses for every payment creates friction. You can’t put a static donation address on your website without destroying your privacy.

Silent Payments let you publish one reusable address. Senders use it to generate unique, unlinkable outputs on-chain, no interaction required. The receiver scans the blockchain to detect payments using cryptographic keys only they control.

It’s elegant. But there’s a trade-off: scanning every eligible transaction takes computational work. And that’s where the attack comes in.

The attack: weaponizing scanning complexity

Under BIP-352, a sender can create multiple outputs for the same recipient in one transaction. The receiver’s wallet checks for them sequentially: if it finds output 0, it checks for output 1. If it finds output 1, it checks for output 2. And so on, until no more outputs are found.

For normal transactions, this is efficient. But Bitcoin’s consensus rules allow a single transaction to contain up to 23,255 taproot outputs if it fills an entire 4 MB block.

Without a limit, an attacker could craft a transaction with all 23,255 outputs targeting one Silent Payments address. When the victim scans that transaction, the inner loop runs 23,255 times, resulting in quadratic complexity (O(N²)). On modern hardware, processing that single transaction would take several minutes instead of the usual tens of seconds for an entire block.

An attacker could fill blocks with these adversarial transactions, targeting public donation addresses or exchanges. The goal wouldn’t be to steal funds, just to make scanning so slow that Silent Payments become unusable.

The fix: K_max = 2,323

The patch caps the number of outputs per recipient at 2,323. This reduces the worst-case complexity from O(N²) to O(N · 2,323), bringing the attack scenario back down to tens of seconds.

When scanning, wallets stop checking after the 2,323rd output, even if more exist in the transaction. When sending, wallets reject transactions that exceed the limit before broadcasting.

Simple. Effective. But why 2,323 specifically?

The math behind 2,323

The number isn’t random. It represents the maximum number of P2TR (taproot) outputs that fit in a 100 kB transaction, Bitcoin Core’s standard relay policy limit.

Here’s the calculation:

Standard transaction limit: 100,000 bytes
Taproot output size: ~43 bytes (version, pubkey, amount, overhead)
Maximum outputs: ~2,325
Conservative choice: 2,323 (accounting for transaction overhead)

This means honest senders using standard transactions can’t accidentally hit the limit. Miners could include larger non-standard transactions in blocks, but receivers stop scanning after 2,323 outputs regardless.

The limit aligns with existing Bitcoin network policy, not arbitrary protocol design. It’s a natural ceiling.

Why this change is safe

Technically, this is a breaking change. A transaction with 2,324 outputs to one recipient would be valid under BIP-352 v1.0 but rejected by v1.1.0.

In practice, it’s completely safe:

No existing wallet supports this. No Silent Payments implementation (Cake Wallet, Bitcoin Core, BitBox02, Nunchuk) allows creating anywhere near 2,323 outputs in a single transaction.
Economic implausibility. Creating 2,300+ outputs costs significant fees and serves no legitimate use case.
Early adoption phase. Silent Payments is still emerging. Breaking changes are acceptable before widespread production use.
Coordinated rollout. Wallet developers were notified in advance and updated implementations before the BIP change merged.

Sebastian Falbesoner, who proposed the fix, noted in GitHub PR #2106:

“In theory this is a backwards incompatible protocol change. Practically, no existing Silent Payments wallets out there supports sending to such a high quantity of recipients (not even in terms of total number of recipients), so the K_max limit should be safe to introduce, without any negative effects in the wallet ecosystem.”

Who’s behind this?

The change was proposed by Sebastian Falbesoner (theStack), a Brink-funded Bitcoin Core contributor from Vienna. Falbesoner is one of the co-authors of BIP-352 itself and known for thorough code review work on projects like BIP-324 (v2 P2P transport).

He posted to the Bitcoin-Dev mailing list in mid-February 2026 seeking feedback. According to Bitcoin Optech Newsletter #392, wallet developers were notified in advance. No major concerns were raised.

The timeline:

February 19, 2026: Falbesoner opens PR proposing K_max=1,000
February 27, 2026: Updated to K_max=2,324
March 2, 2026: Final adjustment to K_max=2,323 and merge

The limit evolved as developers refined the analysis. The initial proposal of 1,000 was conservative. The final 2,323 value maximizes legitimate use cases while still providing DoS protection.

What this means for Bitcoin privacy

This change strengthens Silent Payments’ viability as a production privacy tool. By eliminating a clear DoS vector before it could be exploited, the protocol becomes more robust for real-world use.

For users, nothing changes. The limit is far beyond any realistic use case. For wallet developers, it’s a simple validation check: ensure per-group recipient count ≤ 2,323 before broadcasting.

Silent Payments is still in early adoption, but support is growing:

Cake Wallet: First mobile wallet to implement Silent Payments (2024)
Bitcoin Core 28.0+: Merged support for sending and receiving via CLI
BitBox02: Hardware wallet support added (2024)
Nunchuk: Added support February 2026

The scanning requirement means adoption will be limited to users running full nodes or trusting third parties with their scan keys. But light client solutions are an active area of research. As the BIP-352 appendix notes, “tweak data” approaches could reduce scanning overhead significantly.

The bigger picture

Five years ago, a finding like this might have led to drama or rushed fixes. Instead: coordinated disclosure, thoughtful discussion, clean implementation.

This is how mature protocols handle security issues. Identify the problem, propose a solution, get feedback, ship the fix. No exploits. No panic. Just good engineering.

Silent Payments fills a unique niche in Bitcoin’s privacy toolkit. It eliminates on-chain linkability without on-chain notification transactions (unlike BIP-47) and uses standard Bitcoin elliptic curve operations (unlike Monero-style stealth addresses). It complements CoinJoin and PayJoin rather than replacing them.

The K_max limit doesn’t change these trade-offs. It simply hardens the protocol against abuse.

For a protocol still finding its footing, that’s exactly what it needs.

Sources

Last updated: March 4, 2026