silentpayments: drop "shuffle outputs" recommendation from API docs
What changed, and why it matters
This commit only changes documentation comments in a header file. It removes a recommendation that callers shuffle transaction outputs before scanning, and instead clarifies that outputs should be passed in their original transaction order. There is no code change, no security fix, and no vulnerability being addressed.
No security action required; treat as a routine documentation update.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch edits include/secp256k1_silentpayments.h, deleting two lines that recommended shuffling tx_outputs and adding wording that tx_outputs should be in original transaction (vout) order. It is a pure documentation/API clarification for the silent payments scanning function. No implementation, behavior, or cryptographic logic is modified.
Changed components
include/secp256k1_silentpayments.hInspect captured patch +2 / −3
diff --git a/include/secp256k1_silentpayments.h b/include/secp256k1_silentpayments.h
index d9b3eae..256e95a 100644
--- a/include/secp256k1_silentpayments.h
+++ b/include/secp256k1_silentpayments.h
@@ -348,8 +348,6 @@ typedef struct secp256k1_silentpayments_found_output {
* Scanning is bounded by SECP256K1_SILENTPAYMENTS_RECIPIENT_GROUP_LIMIT and may
* miss outputs if a transaction contains more outputs for a single scan public
* key group than this limit.
- * It's recommended to shuffle `tx_outputs` before calling this function to ensure
- * runtime is not affected by the ordering of the outputs.
*
* Returns: 1 if output scanning was successful.
* 0 if the transaction is not a Silent Payments transaction,
@@ -364,7 +362,8 @@ typedef struct secp256k1_silentpayments_found_output {
* represents the number of outputs found while
* scanning (0 if none are found). Can't be larger than
* SECP256K1_SILENTPAYMENTS_RECIPIENT_GROUP_LIMIT.
- * In: tx_outputs: pointer to the transaction's x-only public key outputs
+ * In: tx_outputs: pointer to the transaction's x-only public key outputs,
+ * in their original transaction (vout) order
* n_tx_outputs: the size of the tx_outputs array.
* scan_key32: pointer to the recipient's 32 byte scan key. The scan
* key is valid if it passes secp256k1_ec_seckey_verify
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.