BIP-352: limit number of recipients to 2^32-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.).

murchandamus commented at 6:09 pm on December 12, 2025: contributor

cc: @RubenSomsen, @josibake

murchandamus added the label Proposed BIP modification on Dec 12, 2025

murchandamus added the label Pending acceptance on Dec 12, 2025

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.

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

ACK 3795b711cb614d288e80fd41adf5e4e76e6c87b9

Eunovo commented at 5:25 am on December 28, 2025: contributor

ACK https://github.com/bitcoin/bips/pull/2055/changes/3795b711cb614d288e80fd41adf5e4e76e6c87b9

BIP-352: limit number of recipients to fit within unsigned 32-bit integer 14e04e0e09

theStack force-pushed on Jan 4, 2026

nymius commented at 7:21 pm on January 12, 2026: contributor

ACK 14e04e0e0999e88f9bb8c704c49b7690571d59e8

in bip-0352.mediawiki:191 in 14e04e0e09

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 number of taproot outputs in the transaction fits within an unsigned 32-bit integer<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 is inferred from the data type of ''k'', which is serialized as a 4-bytes sequence in the course of the shared secret scalar calculation ''t<sub>k</sub>''.</ref>

nymius commented at 7:35 pm on January 13, 2026:

If we ignore the block size limits, and consider this restriction, a transaction with 4294967295 + N¹ taproot outputs with only a single silent payment output wouldn’t be scanned. I recommend to keep the reference for the recipient case but remove this constraint, because even if the case was possible, the limit would be something arbitrary.

N > 0 ↩︎

murchandamus commented at 8:57 pm on January 13, 2026:

I assume this is intended as humorous, or do you actually propose a change in the phrasing?

nymius commented at 9:41 pm on January 13, 2026:

I wasn’t trying to. Maybe I’m going too far with the implications of the sentence, I just want to avoid someone thinking there is a magic number besides which you can ignore the transaction and don’t have to scan more outputs, and later suggest we can avoid the worst performing scanning case by lowering this number again. I’m saying The number of taproot outputs in the transaction fits within an unsigned 32-bit integer is an arbitrary limit that can be dropped without harm, because is not there where the problem lies. From following the referenced comments above, I understood the original idea of this change was to drop checks on the recipients side (while creating sp outputs), not on the receiving side (while scanning sp outputs).

murchandamus commented at 9:45 pm on January 13, 2026:

I see. From my cursory following along here, it seemed like you were joking about the large numbers involved. I’ll leave it up to the author to reply then.

theStack commented at 3:52 am on January 15, 2026:

@nymius: It took me a while to fully understand what you mean, but after reading your comment in the libsecp SP implementation PR (https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r2687881682) I think I got it. Trying to express in my own words: mandating a certain recipient limit at the sender side does not imply that we can safely skip txs that exceed that limit (in terms of number of taproot outputs) at the receiver side, as there could have been added an arbitrary number of other taproot outputs that are completely unrelated to the sender’s created SP outputs; the spec doesn’t prevent that, and doing it seems indeed not unreasonable (thinking e.g. of batched transactions at exchanges, combining SP and non-SP outputs). That’s a fair point, and in fact something I overlooked.

So the two limits (while being absurdly high for practical purposes) are less strongly connected than I initially assumed. Will put this PR to draft state for now and think it through again.

nymius commented at 1:05 pm on January 15, 2026:

Yes, I was referring to this, thanks for the clearer wording!

murchandamus commented at 8:58 pm on January 13, 2026: contributor

This seems ready to go, but I would prefer to get sign-off from one of the BIP authors, @RubenSomsen or @josibake.

theStack marked this as a draft on Jan 15, 2026

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