Issue Details

Number

25150

Title

Coin Selection tracepoint overreports use of APS

Description

> > 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 https://github.com/bitcoin/bitcoin/issues/25003#issuecomment-1122685021_

URL

https://github.com/bitcoin/bitcoin/issue/25150

Closed by

Notes

Attention of

Kill Factor (1-10)

Save

Back to List