Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
theStack wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion bip-0352.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,6 +188,7 @@ Future silent payments versions will use the following scheme:
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 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>
Copy link
Contributor

@nymius nymius Jan 13, 2026

Choose a reason for hiding this comment

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

If we ignore the block size limits, and consider this restriction, a transaction with 4294967295 + N1 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.

Footnotes

  1. N > 0 ↩

Copy link
Contributor

@murchandamus murchandamus Jan 13, 2026

Choose a reason for hiding this comment

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

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

Copy link
Contributor

@nymius nymius Jan 13, 2026

Choose a reason for hiding this comment

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

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).

Copy link
Contributor

@murchandamus murchandamus Jan 13, 2026

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

@theStack theStack Jan 15, 2026

Choose a reason for hiding this comment

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

@nymius: It took me a while to fully understand what you mean, but after reading your comment in the libsecp SP implementation PR (bitcoin-core/secp256k1#1765 (comment)) 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.

Copy link
Contributor

@nymius nymius Jan 15, 2026

Choose a reason for hiding this comment

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

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

* The transaction has at least one input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
* The transaction does not spend an output with SegWit version > 1<ref name="skip_txs_with_unknown_prevouts">'''Why skip transactions that spend SegWit version > 1?''' Skipping transactions that spend unknown output scripts allows us to have a clean upgrade path for silent payments by avoiding the need to scan the same transaction multiple times with different rule sets. If a new SegWit version is added in the future and silent payments v1 is released with support, we would want to avoid having to first scan the transaction with the silent payment v0 rules and then again with the silent payment v1 rules. Note: this restriction only applies to the inputs of a transaction.</ref>

Expand Down Expand Up @@ -291,7 +292,7 @@ The sending wallet performs coin selection as usual with the following restricti

==== Creating outputs ====

After the inputs have been selected, the sender can create one or more outputs for one or more silent payment addresses in the following manner:
After the inputs have been selected, the sender can create one or more outputs (the number of recipients must fit within an unsigned 32-bit integer<ref name="maximum_recipients"></ref>) for one or more silent payment addresses in the following manner:

* Collect the private keys for each input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
* For each private key ''a<sub>i</sub>'' corresponding to a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output, check that the private key produces a point with an even Y coordinate and negate the private key if not<ref name="why_negate_taproot_private_keys">'''Why do taproot private keys need to be checked?''' Recall from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] that each X-only public key has two corresponding private keys, ''d'' and ''n - d''. To maintain parity between sender and receiver, it is necessary to use the private key corresponding to the even Y coordinate when performing the ECDH step since the receiver will assume the even Y coordinate when summing the taproot X-only public keys.</ref>
Expand Down