Selecting utxo's based on tags requires reading lots of plaintext.
Ability for users to create tags (e.g. sales from business X, twitter account X, coins from KYC exchange X, coins from KYC exchange Y) and then allow users to select these tags when spending.
For example, I want to pay for something to do with my business X so I send from utxo's tagged 'sales from business X' by selecting this utxo tag when constructing the tx.
Many seperate wallets may be overkill and is inconvenient beyond one or two additional wallets.
Manually reading tags works and is the best option but recent development on the coin selection algorithm suggests that automating coin selection is something that wasabi Devs feel is desirable. As such this feature would give the user some ability to control the set of utxo's on which the automated coin selection algorithm can run.
@6102bitcoin it's not a bad idea but we have to think more about it.
Let me take the opportunity to say that what you describe in the "What's the problem" section is a real problem. The coins' cluster text is sometimes long but it is not how it should be. The cluster text is long because users don't fully understand how to label their coins properly, I mean, a coin cluster text in Wasabi should be a comma-separated list of people who know/can-know about the coin. This is why it should look something like "Albert, Robert, Maria, Lee, Rabi", however in many cases users get something like "Payment from TV, Moved from mycellium, Coinbase withdrawal, Sell chocolate Easter bunny, blah blah blah"
The first thing we have done is to make the cluster text exactly the same for all the coins that belong to the same cluster so, it is much easier to check visually. Also, after you select the coins you want to spend, the coins selecting algorithm tries to avoid combining multiple clusters if possible (btw, it doesn't select the coins for you, it just tries to select the best subset of coins among the ones you already selected). Finally, it could be possible to tag clusters with something like Family, Donations, etc.
Anyway, many ideas sound good for some people (and devs) but we have to analyze how those ideas could impact in all the wallet's users very careful first.
Btw, we can recognize that there's a 1 to 1 relationship between clusters and coin's specific labels.
IMO we should simplify the coin list in a way that we don't show all the coins, but rather all the clusters in the same anonset level instead.
So today it looks like this:
coin1 - greencheckmark - 1BTC - ""
coin2 - greencheckmark - 2BTC - ""
coin3 - greencheckmark - 3BTC - "foo"
coin4 - green - 1BTC - "bar, buz"
coin5 - green - 2BTC - "bar, buz"
coin6 - green - 3BTC - "bar, buz"
To this:
cluster1 - greencheckmark - 3BTC - "" (2 coins)
cluster2 - greencheckmark - 3BTC - "foo" (1 coin)
cluster3 - green - 6BTC - "bar, buz" (3 coins)
I would also add a feature to ensure the expandability of the clustered coins. It can be a treeview with a (+) or can be a checkmark at the bottom of the list, etc.
Me too, I was just afraid of suggesting controls we didn't battletested yet:)
So there is consensus that we need to improve the cluster labeling and associated manual coin selection, let me try to break it down into separate sections and how I suggest to improve it:
the tl;dr: Have two types of labels: Involved Parties as the top level, and Reason for Payment on the second level.
Involved Parties in the receive tab, so that the user can easily select them by clicking, and does not have to type in the exact same phrasing again. this prevents that some minor difference in the label messes with the coin selection, both typos as well as re-phrases. then allow for manual typing of Reason for Payment.Salary September & Salary October, then this is considered as two different clusters. This might be solved by having a label of Involved Parties [considered in coin selection algorithm], and another with Reason for Payment [for differentiation within cluster]. For coinjoined coins, the Involved Parties would be empty / private.Involved Parties cluster, and consider these as one cluster in the manual coin selection, while still optimizing for fees. Have a drop down menu that lists all the individual coins with their individual Reason for Payment, and provide manual coin selection for these. So if the user wants to spend "any coin of the salary", then he selects the top level cluster and automated coin selection does it's magic. If the user wants to spend "specifically the salary from october", then he selects this in the drop down. If the user selects "send private coins [according to the anonset target]" then send the joined coins. Involved Party, then consider this in the coin selection algorithm. involved parties cluster containing both the initial received coin, as well as the CJ change of that cluster. The user can again select either the entire cluster, or a specific coin within it, to enqueue for joining. After anonset target is reached, the coin is displayed in the green shield cluster, and can only be manually enqueued for joining. So for example, this is the wallet of Alice, she has received coins from Bob and Charlie:
Involved Parties Reason for Payment
===========================================================================
Private | 5.0000 0000 bitcoin
---------------------------------------------------------------------------
- confirmed | Anonset 100 | 2.0000 0000 bitcoin | Zero Link Coin Join
- confirmed | Anonset 100 | 1.0000 0000 bitcoin | Zero Link Coin Join
- confirmed | Anonset 100 | 1.0000 0000 bitcoin | Zero Link Coin Join
- confirmed | Anonset 100 | 1.0000 0000 bitcoin | Zero Link Coin Join
Bob | 2.5000 0000 bitcoin
---------------------------------------------------------------------------
- confirmed | Anonset 1 | 1.0000 0000 bitcoin | Payback for coffee
- confirmed | Anonset 1 | 1.5000 0000 bitcoin | Winning bet
Charlie | 3.0000 0000 bitcoin
---------------------------------------------------------------------------
- confirmed | Anonset 1 | 3.0000 0000 bitcoin | Salary October
Now Alice sends 1.2 btc that she got from Bob, to Charlie to pay for pizza:
Involved Parties Reason for Payment
===========================================================================
Private | 5.0000 0000 bitcoin
---------------------------------------------------------------------------
- confirmed | Anonset 100 | 2.0000 0000 bitcoin | Zero Link Coin Join
- confirmed | Anonset 100 | 1.0000 0000 bitcoin | Zero Link Coin Join
- confirmed | Anonset 100 | 1.0000 0000 bitcoin | Zero Link Coin Join
- confirmed | Anonset 100 | 1.0000 0000 bitcoin | Zero Link Coin Join
Bob | 1.0000 0000 bitcoin
---------------------------------------------------------------------------
- confirmed | Anonset 1 | 1.0000 0000 bitcoin | Payback for coffee
Charlie | 3.0000 0000 bitcoin
---------------------------------------------------------------------------
- confirmed | Anonset 1 | 3.0000 0000 bitcoin | Salary October
Bob, Charlie | 0.3000 0000 bitcoin
---------------------------------------------------------------------------
- unconfirmed | Anonset 1 | 0.3000 0000 bitcoin | Change of (Pizza), Winning Bet
[We might even get rid of the anonset value, since every coin in the cluster has the same anonset, I think?]
Most helpful comment
I would also add a feature to ensure the expandability of the clustered coins. It can be a treeview with a (+) or can be a checkmark at the bottom of the list, etc.