Coin Selection tracepoint overreports use of APS #25150

1. 
   murchandamus commented at 8:37 pm on May 16, 2022: contributor

   I’m not sure about the original intention (maybe also the documentation is imprecise?), but if aps_create_tx_internal is called irrespective of the second CreateTransactionInternal result now, I don’t see a point in having the attempting_aps_create_tx tracepoint anymore.

   It helps us know whether the selected_coins tracepoint (that will happen within CreateTransactionInternal) is for the APS CreateTransactionInternal without having to look backwards when aps_create_tx_internal is seen.

   If I understand this correctly, the way this tracepoint is activated, it would log a result as having been produced per APS, whenever the APS result is preferred. Among other things, this would include if there are two equivalent (or even matching) solutions, or if there wasn’t any partial-spend concern with the original solution in the first place. This results in three different concerns:

   1. This feels like a potential footgun for someone trying to understand coin selection outcomes. They might want to know a) how often partial-spends even occurred in the first place, and b) how often the opportunistic APS protected them from it. From what I understand, they cannot actually learn either of these numbers. Instead, a subscriber of the tracepoint would get an inflated sense of how often they were protected from partial spends.
   2. Since the APS solution is preferred even when it has a slightly worse fee, when the general coin selection result and the opportunistic APS result differ, the APS result may actually have a worse waste score and get preferred for the transaction building, disimproving the outcome for the user even when there was no partial-spend in the original solution.
   3. The coin selection is run twice while that might be completely unnecessary in many cases.

   All together, I think both the design for this tracepoint and the design for the opportunistic APS may have the same solution: only run the opportunistic APS if the original selection result includes a partial spend: this would speed up coin selection, remove the potential for disimproving the selection result, and give useful numbers to the subscribers of the tracepoint.

   While I think this PR improves over the original deployment, if I got the above right, it might be better to remove this tracepoint due to not providing a clear signal instead.

   Originally posted by @Xekyo in #25003 (comment)

2. 
   willcl-ark commented at 1:51 pm on May 20, 2025: member

   @0xB10C do you think anything should be done with this tracepoint?

   Perhaps if @murchandamus is recommending removal then that could be the best course of action?

3. 
   murchandamus commented at 6:19 pm on May 20, 2025: contributor

   Maybe this issue would be more relevant if we renamed it to “Only run APS if the original solution would spend a subset of UTXOs sharing the same output script”. cc: @achow101
4. 
   0xB10C commented at 12:48 pm on June 4, 2025: contributor

   @0xB10C do you think anything should be done with this tracepoint?

   I’m not familiar familiar enough with coin selection to comment on if the tracepoint is broken or how to best fix it.

   If it’s still useful and being used, would be good to fix it, if not, I’d be happy to remove it. Can always be patched back in for coinselection measurements if needed in an adhoc basis.

   AFAIK @murchandamus and @achow101 were the main users when it was added.

5. willcl-ark added the label Wallet on Jan 16, 2026
6. willcl-ark added the label Scripts and tools on Jan 16, 2026

Contributors
murchandamus willcl-ark 0xB10C

Labels
Wallet Scripts and tools