Coin control & selection updates

[GBKS]

There have been several conversations around coin control & selection. The first implementation is imminent, so let's spec out the features and how we want to present them to users.

For what I gather:

• Coin control is about the user having manual control over their coins/UTXOs
• Coin selection is the automated process of choosing coins for a transaction

These things blur a little in the UI, so I won't stick with them too closely.

Basically, the application has a screen where the user can see their coins, for general insight and organization. And during the send flow, there's another screen that also shows coins, with various options (manual and automatic) to choose some of them to include in the transaction. Let's call these the "Coin management" and "Coin selection" screens.

Coin selection screen

The users goal is to choose one or more coins for a transaction. They already entered the recipient info and likely chose a fee rate. The screen shows:

• Transaction amount - the user needs to select this much
• Selected amount - how much they already selected
• Remaining amount - how much they still need to select
• Fee - this one changes based on selected coins
• Selection options
  • Manual - user decides
  • Lowest fee (TBD) - smallest UTXO with amount higher than the transaction amount + fee
  • Best privacy (TBD) - pick UTXOs so it looks like a Payjoin or something other magical in that vein
• Select all/none (TBD)
• Sort by amount, date (file size? label?)
• Group by address (aka Tree mode in QT)

There's a sneaky interplay between selected UTXOs, fee and transaction amount. Choosing a UTXO means data is being included in the transaction, which means a higher fee. If the user has selected "Include fee in amount" in the form, then this fee should be included in the transaction amount (right?).

Also, coins can be locked. We should decide whether we always display them at the bottom of the list. Or include them in sorting, and show them as disabled.

For the automatic selection options, one route would be to only show what the algo has chosen for the user, and hide the other coins behind a toggle. The user should also have an option to kick a coin from the automated selection, at which point the algo should update the selection with another coin.

To simplify the choice, we could also have some type of visual indicator for users. For example, single UTXOs that cover the whole amount could have a specific highlight.

Coin management screen

This screen can be accessed at any time, for the user to inspect their precious UTXOs. How it is accessed is TBD (possibly via the main menu, or in settings). We want to show a similar list to the coin selection screen, without all the selection options.

However, we may still want to make selecting coins possible. Users may want to select a few to start a new transaction, or (un)lock them. Adding labels is likely also an important activity on this screen.

Another idea is to somehow intelligently evaluate the wallet situation and make some suggestions. For example, if there are many (near-)dust coins and fees are low, recommend to clean up a little.

---

I am sure I missed a bunch of stuff. Let me know. Also check out what we have in the design docs so far for some visual starting points, as well as QT screenshots.

[johnny9]

Here is the first iteration of the screen bitcoin-core/gui-qml#448

[GBKS]

Michael already has done some great designs and I wanted to also take a stab at it, specifically looking at two ideas:

• How simple can this screen be
• Can the UTXOs list look just like the activity list (transactions != UTXOs, but there is some overlap)

The existing QT wallet shows 6 numbers by default (Quantity, Amount, Fee, After Fee, Bytes, Change). In this mockup, we just show one, and the user can expand to see a breakdown.

Options are also tucked away behind an "..." options button. Out of sight, easy to access, in line with how we organized various other screens.

All open for discussion.

[johnny9]

These are really good. I really like the expanded width and think that these wider layouts will be great on Desktop/Tablet. Do we have an idea of what the maximum lenth should be for layouts like this? We've previously used widths of 600 pixels maximum and 450 pixels maximum.

For Mode, I don't think i fully understand what that will mean so I'm guessing it will be cut for the first iterations but it appears to be in a good spot to enable it later.

For click/tap areas, my expectation is that the check box and label/address will toggle slection and then the items on the right will transition to the details screen.

Then the last piece will be to see how locking fits into this screen, either an option in the details screen or a context menu with right click/long press seems natural.

[johnny9]

When in the TreeView (group by address). What will the partial checkbox state look like when not all UTXOs in the group are selected but at least 1 is?

[GBKS]

Do we have an idea of what the maximum lenth should be for layouts like this? We've previously used widths of 600 pixels maximum and 450 pixels maximum.

The mock-ups follow these rules. 600 max, just like the activity screen and the design docs layout page.

For Mode, I don't think i fully understand what that will mean so I'm guessing it will be cut for the first iterations but it appears to be in a good spot to enable it later.

Yes, don't think modes will/should make it in. Those would automatically select coins based on certain rules, with a slightly different interaction logic (only show what's selected, hide the rest, each item has an option to remove from auto-selection).

For click/tap areas, my expectation is that the check box and label/address will toggle slection and then the items on the right will transition to the details screen.

I think we have two options. Either we follow the actual elements, or we cheat a little, as in the mocks below. With hit areas and hover/active states, it is sometimes more usable if you do cheat and users don't even notice. For example, in the MacOS top menu bar, the hover states of neighboring items actually overlap and don't match the hit areas. It gives you a little more flexibility in tightening up designs, while still having good usability. Which direction do you prefer?

When in the TreeView (group by address). What will the partial checkbox state look like when not all UTXOs in the group are selected but at least 1 is?

Do we need a partial check state?

[johnny9]

I think we have two options. Either we follow the actual elements, or we cheat a little, as in the mocks below. With hit areas and hover/active states, it is sometimes more usable if you do cheat and users don't even notice. For example, in the MacOS top menu bar, the hover states of neighboring items actually overlap and don't match the hit areas. It gives you a little more flexibility in tightening up designs, while still having good usability. Which direction do you prefer?

I prefer the first one.

Do we need a partial check state?

I think that depends on if we make it collapsible.

[rabbitholiness]

I really like the expandable summary component 👍

I'd probably put the title in the page header, as well as the menu icon. Here's an idea:

I feel that it makes the page a bit easier to scan. It also saves vertical space.

For the grouped view, I'd probably ditch the select/deselect all mechanism per address and just visually group them. Here are a few variations:

If we feel that we really need it, then I'd probably just have a "select all" per address, but wouldn't bother with a partial selection icon/state for the address. If the user selects it and then deselects one of the address' UTXOs, the button becomes active again.

[murchandamus]

There's a sneaky interplay between selected UTXOs, fee and transaction amount. Choosing a UTXO means data is being included in the transaction, which means a higher fee. If the user has selected "Include fee in amount" in the form, then this fee should be included in the transaction amount (right?).

On the backend we solve this issue by accounting for the transactions in terms of "effective value" as opposed to nominal value: the effective value is the nominal value minus the fees necessary for the UTXO to be spent by an input at the current feerate. Given that the feerate is known before we start coin selection, the effective values are constant during the selection which allows for a static selection target rather than one that increases over time.