Ensure the CLI does not hold any funds before exiting

[da-kami]

Currently the CLI may hold Bitcoin funds after a swap if:

• A user transferred more than the maximum accetable amount (by the swap counterparty ASB) to the CLI,
• A refund scenario was triggered.
• Special case: A user triggered a mainnet swap against a testnet ASB (we only fail upon spot-pricce request, so the user sent the funds to the mainnet swap CLI but then the swap is rejected)

The CLI holding Bitcoin after a swap leads to unwanted behaviour, because currently a user can only recover the Bitcoin by swapping again.

The current CLI is designed for the lifecycle of one swap. The solution of adding balance & withdraw functionality is not in line with a one swap at the time solution. We propose to add a --change-address [bitcoin-address] parameter to the CLI where all "change" Bitcoin (if any) will be transferred by the end of a swap.

Note: The Monero is already transferred to the user wallet after redeeming so only the Bitcoin side needs additional work.

[da-kami]

Edge cases of this problem might not be solvable completely. E.g. if max tradable amount for a swap is 1 BTC and the user transfers 1 + fees + amount_smaller_dust (or whatever we consider the smallest transferable amount) some fraction of BTC will remain in the wallet inside the CLI.

Note that it will also be hard for the user to hit the exact max tradable (accepted) amount of an ASB, because fees are deducted inside the CLI upon evaluating the BTC given. So, in most scenarios when a user transfers max ASB tradable amount to the CLI only max - fees will actually be swapped. If users start trying to "optimize" towards the actual max they might run into the scenario that I described above.

I think we can ignore these edge cases for now (and accept that tiny amounts might remain in the CLI wallet) but I wanted to point these issues out. @thomaseizinger @bonomat

[da-kami]

This is another edge case: #560

[thomaseizinger]

Edge cases of this problem might not be solvable completely. E.g. if max tradable amount for a swap is 1 BTC and the user transfers 1 + fees + amount_smaller_dust (or whatever we consider the smallest transferable amount) some fraction of BTC will remain in the wallet inside the CLI.

Note that it will also be hard for the user to hit the exact max tradable (accepted) amount of an ASB, because fees are deducted inside the CLI upon evaluating the BTC given. So, in most scenarios when a user transfers max ASB tradable amount to the CLI only max - fees will actually be swapped. If users start trying to "optimize" towards the actual max they might run into the scenario that I described above.

I think we can ignore these edge cases for now (and accept that tiny amounts might remain in the CLI wallet) but I wanted to point these issues out. @thomaseizinger @bonomat

I think this can be solved by swapping slightly less than what the user originally wanted. Say max amount if configured as 1 BTC. The user transfers 1 BTC + fees + amount_smaller_than_dust then we construct a transaction that distributes the funds as follows:

• amount_smaller_than_dust + whatever_is_necessary_to_not_be_dust
• 1 BTC - whatever_is_necessary_to_not_be_dust - fees
• fees