CLI user Bitcoin wallet strategy

[da-kami]

Problem

Currently we don't have a coherent strategy and flow for the Bitcoin wallet on the user side (CLI)
Currently the CLI wallet only offers a deposit command - which was the minimal requirement to make a swap with the ASB (automated swap backend) possible.
We need a coherent strategy for Bitcoin wallet management, that offers a good usability for the showcase setup.

There are two main questions to be answered:

1. Are we expecting the user to do multiple swaps with the Bitcoin wallet?
2. Should the user be in control of the Bitcoin wallet?

A - The user is not in control of the wallet

If we answer question 1. with NO, i.e. the user uses the tool for one specific swap (or very sporadic swaps that don't require leaving money in the tool I would suggest the following solution:

1. The user provides a fallback Bitcoin address for each swap.
2. If Bitcoin is refunded the fallback address is used
3. If Bitcoin is redeemed, but the user sent too much funds to the CLI, the remaining Bitcoin are transferred to the fallback-address.
4. When triggering a swap the tool will print an address to be funded that the user has to send funds to.
5. There are no extra commands for the wallet.

Note that this strategy has the risk that, if something goes wrong on the way, it might be hard for the user to recover the funds.
We might still need withdraw/balance commands for power users, but that could be seen as additional feature.

We can go as far as stating: The internal wallet(s) (we can apply this to the Monero wallet as well) never holds funds longer than for the duration of the swap. This means that any remaining funds (Bitcoin/Monero), depending on the scenario that was executed (redeem/refund) are sent to a user wallet by the end of the swap.

B - The user in control of the wallet

If we answer question 1. with YES, i.e. we expect the user to do multiple swaps, it will be in the user's interest to transfer a larger amount of Bitcoin to the swap tool once to save transaction fees. If we expect that the user should have the commands. (This would give the feel of a power user application.)

Recommendation: Combined solution

I think the strategies can be combined. If the user specifies a fallback address the remaining funds or refunded Bitcoin can end up on the fallback address. If no fallback is specified it would stay within the swap tool.

The swap tool offers deposit, balance and withdraw commands but they are not advertised. Power users will find out anyway.

It is not much work to provide the commands (and we might need them anyway for failure scenarios).
But, to offer a user experience with less interaction we would have to implement scenario A as well.

The hard part is, that if we default to the CLI wallet then user might always default and then has to use the commands. We could do it the other way round - always ask for a fallback address, but power users can specify the one of the swap tool itself. (Bit weird, but coherent...)

Goal

A coherent Bitcoin wallet strategy, for the CLI that offers best usability for the showcase application.

[thomaseizinger]

For Monero, I would expect the flow to be that we always transfer everything to the address the user gave us in the beginning. So even though we have a wallet for the user, it should basically always be empty and only hold funds temporarily.

[da-kami]

Yeah, since the user expects to get the Monero that is good.
We agree on the Monero side, I would keep the discussion to Bitcoin then.

[thomaseizinger]

Here is another option:

• Don't ask the user for a fallback address to minimize on-boarding friction
• Bitcoin refund goes to the internal wallet
• Provide only a withdraw command to move all funds to another address

This optimizes for the happy-path where we don't need a Bitcoin address from the user. In case something goes wrong, the user's funds are still safe and they can transfer them out of the wallet at any time. We might even want to call that command recover to better communicate that this should not be needed under normal circumstances.

[da-kami]

To clarify, you are proposing that there is only a withdraw command and no deposit and no balance command.

When the user triggers a swap he is asked to send the amount of Bitcoin he chose to the swap_cli wallet. The swap_cli prompts the user with an address and then waits for the funds to arrive, then commences with swap execution.

If the swap is redeemed there is no Bitcoin left in the swap_cli wallet.
If the swap is refunded the Bitcoin will end up in the swap_cli wallet and the user can use the withdraw command to withdraw.

---

I like this solution! It simplifies the whole scenario to the only command that is actually necessary.

[thomaseizinger]

Yes, that is what I meant!

There would also be the possibility to send the Bitcoin back to the address they came from but that might not be totally safe because it could be a multi-sig or other shit 😅

Re balance:

We can always check on startup how much money we have and display that.