Improve usability of Sweep_All option for specific subaddresses

[0x00031337]

It is planned to remove - behind Monero - the ability to use PaymentID. Is it only 64-character, long, uncoded PaymentID? Or maybe the option of removing 16-character PaymentIDs, and therefore Integrated Addresses, is being considered? In the latter situation, when we are forced to use Subaddresses, we may be exposed to loss of privacy by mixing outputs from multiple destination addresses (sweep_all). The solution to the situation is to sweep from a specific Subaddress, but it is difficult to do even by the CLI wallet.

[Doy-lee]

I'm not up to date with the Monero side of this, but we will be following suite and deprecating both payment IDs. A sweep_all inherently deanonymises by making all the outputs linked to one destination.

Although if I remember correct, with the change to subaddresses there were some talks to improve the UX of dealing with subaddresses- if by the time we reach that point and there's still no improvement on that regards we can introduce some.

[jagerman]

I noticed recently that sweep_all in the CLI was being "strange" by sweeping only a very small portion of my balance. Now that this issue is posted, I realize why -- it already only sweeps one subaddress at a time:

Command description: 
  Send all unlocked balance to an address. If the parameter "index<N1>[,<N2>,...]" is
specified, the wallet sweeps outputs received by those address indices. If omitted,
the wallet randomly chooses an address index to be used.

transfer tries to do the same, but will apparently use multiple if necessary:

Command description: 
  Transfer <amount> to <address>. If the parameter "index=<N1>[,<N2>,...]" is specified,
the wallet uses outputs received by addresses of those indices. If omitted, the wallet
randomly chooses address indices to be used. In any case, it tries its best not to combine
outputs across multiple addresses. ...

[0x00031337]

Yes, sweep_all in CLI now works as described by jagerman. However, I would like to draw your attention to the possibility of blocking (or obstructing in the maximum way possible) mixing indexes when executing commands that cause blockchain events (sweep_all index=0,1,2,3,4....). An ordinary user will not be aware of threats. This is especially true for the new GUI, where subaddresses are created and displayed by default and we can combine inputs from multiple addresses. This happens if we specify a transfer amount higher than on one of the subaddresses. What's more, we can not specify with the GUI which inputs we want to use. We also can not determine from which address to send funds. If you do not deliberately approach this issue, Loki's privacy and security may be put into question.