BIP-352: Limiting the number of per-group recipients (K_max)

The core of the problem lies in the inefficiency encountered when transactions involve a large number of recipients sharing the same scan public key, particularly under adversarial conditions. A solution proposed to mitigate this issue involves implementing a "K_max" protocol limit, which would cap the maximum number of per-group recipients allowed in a single transaction. This approach, while marking a shift from previous protocols, is expected not to affect current Silent Payment (SP) wallets, provided the K_max value is set at a pragmatically high level, specifically suggested as 1000. The detailed rationale and specifics of this proposed modification have been documented in a draft Bitcoin Improvement Proposal (BIP), available for review here.

The discourse surrounding this proposal has been expansive, with the community actively engaging through various platforms, including GitHub where ongoing dialogues can be accessed and contributed to via this issue link. Efforts to ensure broad community engagement and gather feedback have included direct notifications to SP wallet developers and sharing information across developer mailing lists.

Following constructive feedback, there has been a consensus on the K_max protocol change, leading to the initiation of a new Pull Request (PR) in the Bitcoin Improvement Proposals (BIPs) repository, signifying a critical step forward in enhancing Bitcoin's underlying protocols. This development, accessible through this link, highlights the collective commitment of the Bitcoin community to foster iterative improvement through shared knowledge and open discourse.

In a notable update, the proposed K_max protocol change was merged, setting the limit at 2323. This specific figure aligns with the maximum number of taproot outputs possible within a <= 100 kvB transaction, considering the smallest Silent Payments eligible input. As such, adherence to the current transaction size policy rule ensures compliance with the K_max limit, virtually eliminating concerns over encountering this threshold in practical scenarios. This adjustment underscores the collaborative effort of the community in proposing, discussing, and refining changes essential for the evolution of Bitcoin's infrastructure. Links to resources for further exploration include a Bitcoin transaction size calculator available at Jlopp or BitcoinOps, with the latter providing insights into transaction size calculations albeit without accounting for two extra bytes needed for output-count compactSize encoding.