Add a flag to indicate coin origin in wallet

[imaginaryusername]

Each receive event should add a flag in wallet file to the address linked to corresponding output(s). This will be important for retaining information for future enhancements, and should ideally be implemented before wider release. They can remain unused before implementation of said enhancements, but having the flags ready will be very beneficial.

1) Received: Addresses linked to coins that are received from outside sources. Currently binned as "unshuffled".

2) Shuffled: Addresses linked to flat-amount outputs of a shuffle transaction. Currently binned as "shuffled".

3) Shuffle change: Addresses linked to variable-amount outputs of a shuffle transaction EXCEPT if the parent is from 4). Currently binned as "unshuffled".

4) Spend-shuffled change: Addresses linked to change that's result of a spending a "shuffled" coin, or change from a shuffle transaction whose parent is a 4). Currently binned as "unshuffled".

Additional logic:

Change resulting from spending 1) should be flagged as 1).

Change resulting from spending 3) or combining 1) and 3) should be flagged as 3).

Change resulting from spending 2) is obviously flagged as 4).

Change resulting from spending 4) is still flagged as 4).

Change resulting from spending a combination of 1) or 3) with 4), ideally prevented in the future, shall be flagged as 3).

If an output is unidentifiable (perhaps from an unaware wallet spending from the same seed, or when cashshuffle is disabled), it is flagged as 3) at loading cashshuffle.

If applying logic to an unflagged wallet:

An address whose only output that comes from a transaction identified as "shuffle" shall have its outputs segregated into 2) (> equivalent amounts in tx) and 3) (variable amounts). For all other outputs, we can flag as 1) unless we're willing to implement additional code to fetch one more step up to identify 4).

If an address is reused (the wallet itself will never do that) via receiving coins on an existing used address:

If receiving coin on 1), address retains 1).

If receiving coin on 3), address retains 3). Note that 3) is informatically the same as 1).

If receiving coin on 4), address retains 4). In the future when they are bucketed separately, it's important that such an action does not result in mixing with 1) or 3), which is harmful.

If receiving coin on 2), address (along with associated outputs) is switched to 4). It would be unwise to continue considering them sparkly clean.

Additionally, in the future spending from the same address, regardless of which bucket they are in, should always consolidate all coins on the same address (unless >100kb).

Any suggestions welcome!

EDIT: added logic for address reuse.

EDIT2: added logic for flagging a virgin wallet.

EDIT3: logic for change from shuffle cat 4.

[cculianu]

This is a good idea. I also wanted something like this initially but feared it would be invasive. Given how we're going "all in" on this, it might not be a bad idea to flag them as such and then even modify the coin chooser to do interesting things with these flags when picking coins.

I'l like to hear other people's thoughts on this as well.

[markblundeberg]

It may be possible to hack this in using the existing address label functionality. Put a "(clean)" prefix or something.

Dunno if that's clever or stupid.

What if I do a shuffle-spend, thereby leaving some change on a clean change address (category 4), but that change then gets put into a new shuffle and there is shuffle-change coming out of that? Ideally that change should be categorized differently from its shuffle output otherwise the second shuffle can just be delinked.

[imaginaryusername]

@markblundeberg It's probably unavoidable that such a change be tossed back to cat 3 (imo); else we get into a situation where we have infinite buckets fairly quickly. Categorizing it as cat 4 is very undesirable, cat 3 still leaks but is imo less harmful.

[markblundeberg]

@markblundeberg It's probably unavoidable that such a change be tossed back to cat 3 (imo); else we get into a situation where we have infinite buckets fairly quickly. Categorizing it as cat 4 is very undesirable, cat 3 still leaks but is imo less harmful.

Putting them in cat 3 breaks the firewall between the dirty / and clean addresses, which seems to be the main concern here. If we break the firewall between various clean addresses then it feels less invasive. I lean more towards putting them in category 4 ("clean change") than category 3 ("dirty change")

For safety, we can make it so that neither "clean send" nor "dirty send" would include category 4 coins.

[imaginaryusername]

Fair enough, I guess it make more sense to link "shuffled at least once" change. Editing.

[cculianu]

From Anthony Zegers (I'm pasting this here becasue I don't want to forget this):