silentpayments: document recipient correctness requirement for sender #1990

theStack commented at 5:12 PM on November 5, 2026: contributor

Background: An adversary can create a fake SP address reusing another owner's scan public key. If such an address is batched together with that owner's address, the owner's output may be ordered after the adversary's (resulting in an output with a k value > 0) and is then not found by the BIP352 scanning algorithm. This PR adds an API doc comment on the SP sending function to raise awareness of this issue.

Independently of Silent Payments, the general observation that it's the senders responsibility to ensure the recipient addresses belong to the owner seems trivial; if a recipient doesn't control the keys behind the provided address, the payment obviously fails. The crucial difference in the BIP-352 scenario with shared scan public keys is that the presence of incorrect recipient addresses could make payments to correct recipient addresses unfindable for the owner (not unspendable though), so this is worth to point out explicitly.

Note that the issue only exists if the incorrect addresses have a lower k value than the correct ones, so we could e.g. recommend to to put all recipients that are known to be correct in an earlier recipient position, but that might be a level of detail that is creating even more confusion. At the moment the SP ecosystem seems to be far away from multi-party sending, so it seems reasonable to give a conservative recommendation and possibly re-evaluate that at a later point.

A very restrictive alternative could be to limit the group size to 1 (i.e. effectively only ever creating k=0 outputs) to be on the safe side, but this suggestion didn't have consensus for the BIP-352 authors, and I don't think the libsecp256k1 implementation should be more restrictive than the BIP. An in-between solution could be to e.g. introduce a "dangerous" flag parameter that has to be set to allow group sizes of > 1, or introduce a safer variant of _sender_create_outputs with that limitation, but I'm not sure if it's worth it to extend/change the API at this point.

See also Ruben's write-up for a more detailed description of the problem and potential future mitigations. The various AI scanner findings are included as a comment below there for additional context.

Thanks to l0rinc for first finding this issue (PRed in Bitcoin Red Team's bitcoin-security-council/secp256k1 repository on Sep. 19th). Similar vulnerability reports were later submitted by the Anthropic OSS scanner (Oct. 16th) and Project Loupe (Oct. 29th).

silentpayments: document recipient correctness requirement for sender

Background:
An adversary can create an address reusing another owner's scan public
key. If such an address is batched together with that owner's address,
the owner's output may be ordered after the adversary's and is then not
found by the BIP352 scanning algorithm.

Thanks to l0rinc for first finding this issue (PRed in Bitcoin Red
Team's bitcoin-security-council/secp256k1 repository on Sep. 19th).
Similar vulnerability reports were later submitted by the Anthropic OSS
scanner (ANT-2026-X2ZAAB2N, Oct. 16th) and Project Loupe (Oct. 29th).

9a80949cba

theStack commented at 5:13 PM on November 5, 2026: contributor

cc @RubenSomsen

theStack added this to the milestone 0.8.1 on Nov 5, 2026

theStack added the label user-documentation on Nov 5, 2026

RubenSomsen commented at 9:52 PM on November 5, 2026: none

Looks good to me. It matches the conclusion I landed on after my write-up exploring the possible ways of dealing with this particular case.

Yudis-bit commented at 3:06 AM on November 7, 2026: contributor

If this cannot be established, the recipients in question should instead be paid in separate transactions.

recipient_sort_cmp already falls back to r->index on identical scan keys, and secondary sorting on spend keys would be unnecessary since grinding an earlier spend key takes only two curve multiplications. Enforcing uniqueness inside _sender_create_outputs would break legitimate labeled batching, while relaxing the receiver's early-break invariant degrades mobile scanning from O(1) to O(outputs) scalar multiplications per transaction. Documenting the caller contract keeps policy outside the C library.

ACK 9a80949cb.

fametrano commented at 12:38 AM on November 11, 2026: contributor

ACK 9a80949cbab56d0d2023791b0144d4865ef0887e

The description weighs recommending that recipients known to be correct go first, and leaves it out. For PSBT senders that advice would not hold, so the doc is right without it.

Here k within a scan-key group follows the caller's index. BIP375 orders the group by spend key, then output index ("sort the codes lexicographically in ascending order to determine the ordering of the k value"), so a PSBT sender cannot choose who gets k=0: an address reusing the scan key with a lower spend key takes it wherever its output sits. Separate transactions work in both flows.

Measured at this head with two spend keys indexed against spend-key order, against btclib-wallet's BIP375 derivation: the k values swap, and match once index follows spend-key order (details).