Here I make the wallet select the preset inputs twice during the coin selection process (on v24.0).
Making it think that the selection process result covers the entire tx target when it does not. It’s actually creating a tx that sends more coins than what inputs are covering for.
Which, combined with the SFFO option, makes the wallet incorrectly reduce the tx recipient’s amount by the difference between the original target and the double-counted inputs. Which means, a created and relayed tx sending less coins to the destination than what the user inputted.
Technical Explanation
The reason why this happens is that the CoinsResult::Erase
method is removing only one output from the available coins
vector (there is a loop break that should have never been
there) and not all the preset inputs.
Which makes the Coin Selection process receive the preset inputs inside the selectable coins and inside the preset inputs vector. Which is not good, because we merge the preset inputs inside the automatic Coin Selection result manually at the end of the process, so this result can already contain the preset inputs.
So.. this ends up with the Coin Selection result having less inputs selected and not covering the entire target amount. Which, alone, makes the wallet crash inside the “insane fee” assertion.
But.. to make it worst, adding the subtract fee from output functionality to this mix ends up with the wallet by-passing the “insane” fee assertion, decreasing the output amount to fulfill the insane fee, and.. sadly, broadcasting the tx, with a reduced recipient’s amount, to the network.
Important Note
This is only a problem for v24.0 and not in master.
Since #25685, we no longer use the CoinsResult::Erase
method inside
the Coin Selection Process.