Skip to content

Conversation

@theStack
Copy link
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 bitcoin-core/secp256k1#1765 (comment) (related earlier discussion on take 3: bitcoin-core/secp256k1#1698 (comment) ff.).

@murchandamus
Copy link
Contributor

cc: @RubenSomsen, @josibake

@murchandamus murchandamus added Proposed BIP modification Pending acceptance This BIP modification requires sign-off by the champion of the BIP being modified labels Dec 12, 2025
Copy link
Member

@furszy furszy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 3795b71

For silent payments v0 a transaction MUST be scanned if and only if all of the following are true:

* 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)
* 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>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Pending acceptance This BIP modification requires sign-off by the champion of the BIP being modified Proposed BIP modification

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants