Improved Wallet State Management

[yeastplume]

Link to Rendered Document

Edit by lehnberg: Correcting link to rendered document

[lehnberg]

Nice. Couple of nitpicky points:

• Most RFCs will be "enhancements", and wallet-update-process sounds quite generic. What would a more descriptive title be? improved-wallet-state-management?

• For better readability for future readers, write in present form with the assumption that the RFC has already been merged. So rather than proposing changes, describe the already accepted changes. Similarly current wallet procedures become previous wallet procedures, etc.

• IIRC, largest doesn't lead to all outputs being locked, just the most possible. This to reduce UTXOs, but comes at a privacy cost. It might be worth noting that a smallest strategy might reduce output likability, but may also lead to increased transaction fees.

[yeastplume]

Updated the tense and title as per suggestions.

selection-strategy=all will sweep as many outputs as it can, up to a hardcoded limit of 500. In most cases this will have the effect of locking all user funds.

There was some conversation a while back where someone was arguing that the default selection strategy didn't actually reduce overall UTXO set size effectively. I admit this isn't something I've studied in any particular detail, so would be interested in hearing more opinions here. The only thing I can say with relative certainty is the current default 'sweep' method is terrible for usability regardless of it's effect on UTXO set size.

[lehnberg]

Looks much better @yeastplume 👍

selection-strategy=all will sweep as many outputs as it can, up to a hardcoded limit of 500. In most cases this will have the effect of locking all user funds.

I did not know this. Seems I had completely misunderstood this strategy to be something more like largest.

[DavidBurkett]

There was some conversation a while back where someone was arguing that the default selection strategy didn't actually reduce overall UTXO set size effectively.

Yea, I was the one that said that. While it results in a temporary reduction, as long as you're using a selection strategy that routinely spends "dust" (ie. don't use a "largest first" strategy), your current inputs will eventually be spent as you continue to use Grin, so you're mostly just inconveniencing yourself by spending them all everytime, and drawing a big circle around your inputs, reducing Grin to an accounts-based model which is bad for privacy.

[DavidBurkett]

For better readability for future readers, write in present form with the assumption that the RFC has already been merged. So rather than proposing changes, describe the already accepted changes. Similarly current wallet procedures become previous wallet procedures, etc.

I actually find it more confusing now that the tenses have been updated. I like when the RFC clearly states what takes place today, and how things will work after the RFC is implemented. I wouldn't suggest changing this RFC again, but maybe it's something we can talk about elsewhere?

[DavidBurkett]

Great work!

[yeastplume]

Added more clarity on smallest selection process, fixed typos.

[quentinlesceller]

Looking good 👍 some minors typo fix below before entering FCP.

[jaspervdm]

Do you think it would be a good idea to create a new tx log entry when 'confirmed' outputs no longer exist in the UTXO set? This would give a more consistent feel for people who are using their seed on multiple wallets at the same time, as spending on wallet A would also appear as a spend on wallet B. Obviously this information would not be perfect but it would prevent situations where funds suddenly disappear without a trace.

[yeastplume]

I think that could be a good enhancement. Right now the updater simply ignores the case where an output is not locked/doesn't have an associated transaction, i.e. it only updates a transaction if there's one to find. Could end up with a lot of spam in the tx log though since there's no real way to group outputs in this case, you'd just have to create a new TX for each instance of this occurring.

[jaspervdm]

We could group all outputs (without an associated tx log entry) that are no longer unspent in the same update cycle in 1 tx log entry. There is a chance that we group more than 1 tx but I don't think that is a big deal. It would however prevent a lot of spam.

[DavidBurkett]

If implemented carefully, this should actually solve a lot of the privacy issues we have with using shared nodes. We can probably do this in a way that prevents side channel leakage like Monero and Zcash have been found to be vulnerable to: https://hackerone.com/reports/713321

We just need to not block the thread for any operations that are only performed when our own transactions are received from a node, and never make special requests for our own transactions.

If we also introduce a way to anonymously submit transactions to random nodes via TOR, we could actually make it so shared nodes are just as private as using your own node, with one caveat: Wallets that are only on long enough to receive a transaction and logoff will still be terrible for privacy.

[0xmichalis]

Wallets that are only on long enough to receive a transaction and logoff will still be terrible for privacy.

@DavidBurkett can you explain why is this the case with a wallet connected via Tor?

[quentinlesceller]

In accordance with our RFC process, as of November 15 this can be considered in Final Comment Period with a disposition to merge. Previously announced on Keybase.

[quentinlesceller]

🎉 Wohooo! This RFC has now been merged! 🤸‍♀️
Tracking issue: mimblewimble/grin-wallet#244