BIP-352: limit number of recipients to 2^32-1 #2055

1. 
   theStack commented at 6:03 pm on December 12, 2025: contributor

   Explicitly specifying a limit on the number of SP recipients / taproot outputs to scan for was suggested in the course of reviewing the BIP-352 module implementation in libsecp256k1, see https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r2609620541 (related earlier discussion on take 3: https://github.com/bitcoin-core/secp256k1/pull/1698#discussion_r2381448515 ff.).
2. 
   murchandamus commented at 6:09 pm on December 12, 2025: contributor

   cc: @RubenSomsen, @josibake
3. murchandamus added the label Proposed BIP modification on Dec 12, 2025
4. murchandamus added the label Pending acceptance on Dec 12, 2025
5. in bip-0352.mediawiki:191 in 3795b711cb

   187@@ -188,6 +188,7 @@ Future silent payments versions will use the following scheme:
   188 For silent payments v0 a transaction MUST be scanned if and only if all of the following are true:
   189 
   190 * The transaction contains at least one BIP341 taproot output (note: spent transactions optionally can be skipped by only considering transactions with at least one unspent taproot output)
   191+* The transaction does not contain more than 4294967295 (2<sup>32</sup>-1) taproot outputs<ref name="maximum_recipients">'''Why specify a limit of recipients, if the maximum number of possible transaction outputs is practically constrained by Bitcoin's consensus rules (block weight limit) anyway?''' Specifying an explicit limit improves clarity and ensures that implementations can safely choose compatible data types without the risk of becoming non-compliant. The limit matches the maximum possible value for ''k'' in the course of the shared secret scalar calculation ''t<sub>k</sub>'', where ''k'' is serialized as a 4-bytes sequence.</ref>
   

   ---

   ---

   

   furszy commented at 7:21 pm on December 12, 2025:

   nit: I think it would be clearer and harder to misinterpret to state directly that both k and the number of recipients are unsigned 32-bit integers.

   ---

   

   murchandamus commented at 7:01 pm on January 2, 2026:

   +1. The block size limits transactions to fewer than 23,300 P2TR outputs, so stating such a high limit seems more confusing than explaining what type of number are used.

   ---

   

   theStack commented at 1:42 pm on January 4, 2026:

   Makes sense. Rephrased without stating the limit explicitly, but rather using the phrasing “fits within an unsigned 32-bit integer”. Suggestions welcome.
6. 
   furszy commented at 7:21 pm on December 12, 2025: member

   ACK 3795b711cb614d288e80fd41adf5e4e76e6c87b9
7. 
   Eunovo commented at 5:25 am on December 28, 2025: contributor

   ACK https://github.com/bitcoin/bips/pull/2055/changes/3795b711cb614d288e80fd41adf5e4e76e6c87b9
8. BIP-352: limit number of recipients to fit within unsigned 32-bit integer 14e04e0e09
9. theStack force-pushed on Jan 4, 2026

Contributors
theStack murchandamus furszy Eunovo

Labels
Proposed BIP modification Pending acceptance