Prevent remaining dust when sending max BTC

[314159265359879]

Affected transaction: https://mempool.space/tx/0a2abf93ada04e8e9335987ee762f5871adab50e083b42b60e774bae1c2925ce
When using send-max the wallet should prevent this.

The user was not 100% certain if they switched to custom fee and then back to medium. I thought we wanted the send amount to change when selecting low, medium or high, when in "send-max" mode, so that everything (economical is spend). And I see that happening when switching between low, medium, high or custom fee.

With a much lower fee the number of economical UTXO's increases so the total spend does increase. But that is not relevant for this case because it spends a single big UTXO.

The next step would be to try and reproduce this on a wallet that has a single UTXO, to see if there is any difference between the low, medium, high and custom options and if any dust is left. If it is related to this issue: #4777, I wouldn't see it because I am not transmitting these transactions unless I create four wallets with a single UTXO and try all four fee options. I will revisit after 4777 is resolved.

[friedger]

I was not able to send max BTC. It is really hard to empty an address!

I used custom fees so that the fees + transferred amount = current balance. Then I receive an error {"code":-26,"message":"dust"}
Looking at the txs it shows that an output with 0 btc was added.

The UI could show the remaining balance on the review page

[friedger]

My issue is probably more related to adding always a change address if not using sendMax: https://github.com/leather-wallet/extension/blob/d8e0088e97fbe8c195c6040c05764322c112faf4/src/app/common/transactions/bitcoin/utils.ts#L175

I created the tx with the full amount using custom fee because sendMax was not emptying the wallet. Some dust was left over.

[314159265359879]

@friedger thanks for the added detail, SendMax is expected to leave dust amounts when those amounts would cost more to include in a transaction than they are worth.

Any chance that was the case? What was the size of the UTXO that were not getting included?

If adding a single input adds 70 vB... (depends on script type) at 20 sats/vB no UTXO would be included of 1400 sats or less because it is not economical.

[friedger]

@314159265359879 I have three utxos above the dust limit, they are used, I see them in console log as coin selection. The dust amount changes with the fee that I choose. I suspect that the spendable balance is not updated/calculated correctly.

[friedger]

#5472 addresses the issue when not using "send max", but still sending the max amount.

[friedger]

When this issue is solved, then #3139 can be closed as well.

[314159265359879]

Thanks for diving into this one and creating a PR!

[friedger]

I experienced that sending max does indeed send all btc , however, the display is wrong.

The "Sending" amount is correct, however, the "Total spend" is wrong. Also, the broadcasted tx uses a higher fee rate than shown.

With the higher fee rate, the broadcasted tx does not leave any dust in the account because there is only 1 output.

[314159265359879]

@friedger did I understand correctly that your PR here #5472 addresses the concern so that the displayed amount is correct?

When sendMax is clicked, no fee has been selected, so the sats needed to cover the "high" fee option are reserved. Sending the transaction with the standard fee will leave the difference between medium and high fee, is that what you are seeing? Related:
#3080 and this comment about current behavior #3080 (comment)

I believe this will be addressed with the next UX redesign so fees are selected together with the amount being sent rather than in isolation. pinging @markmhendrickson to check me on that.

[friedger]

I don't know where the higher fee comes from. Maybe from "high" fee option, however, I think it is more a problem of determine the size.

[markmhendrickson]

I believe this will be addressed with the next UX redesign so fees are selected together with the amount being sent rather than in isolation

The amount will continue to be set before the fee is determined, which is necessary given how Bitcoin transactions are constructed. We can't reliably calculate the fee before knowing the amount afaik.

[friedger]

I still see this here: https://mempool.space/tx/6b5376d7d20aa502cbe0318bd2d1a2b21706a368a9f6e9a7e4b44e7b7e9265bc

using 6.44.0

[markmhendrickson]

@friedger any idea why it wasn't handled with the merged PR?