[DNM] Change default coin selection algo to 'smallest'

[bogatyy]

Using all as default seems to be a major privacy risk, especially coupled with the Keybase wallet option.

An attacker can send dust coins to any known Keybase username (I did the experiment with https://keybase.io/mcdallas who was running a Keybase wallet) and subsequently predict with 100% accuracy whenever the target recipient made a payment.

Here is me sending dust coins to mcdallas: https://grinscan.net/block/82584
Output 0800d1de2... is what came back to me so the other output 08552d3e... has to be his.

Now I look at block https://grinscan.net/block/82601 and know he did another transaction since that output is spent. I can keep doing this forever by sending him another dust marker after the previous known output is spent. Notably a user with a running Keybase wallet would not even notice this attack (unless they check their outputs manually).

[antiochp]

Not convinced this is the right approach.

The smallest strategy selects the smallest coins first (and as few as necessary).
So its going to choose your dust outputs first anyway...

I think the real issue here is the wallet currently silently interacts to receive coins in a tx.
We should probably think more about how to prevent this.

[yeastplume]

Agreed this needs more thought, and the root of the problem is the non-interactivity on the recipient end. Note this is also the root cause of https://github.com/mimblewimble/grin/issues/638, where an unknown can spam unconfirmed outputs into a wallet listener at will.

This is only an issue with listener scenarios, file or other async exchanges don't suffer from this. We could ensure a recipient must always confirm somehow, but that makes things even more cumbersome in a process that already has enough friction. Thought required.

[mcdallas]

Perhaps we could provide some kind of hook for when you receive a transaction so the user can add their own logic. For example:

• Reject txs with amount < X

• Reject txs outside a list of known senders

• Automatically send coins to yourself for tumbling

It would also be useful for other kind of things like keeping your own records if you are an online shop.

[antiochp]

Reject txs outside a list of known senders

I think this might make a lot of sense for the keybase plugin.
Maybe you can only send/receive from people you are following/followed by in keybase?

[ignopeverell]

Agree with @yeastplume and @antiochp about not jumping to a quick fix too fast. For people doing file-based exchanges this won't be an issue. For others we have the self-sending functionality that @yeastplume added recently. Perhaps on every interactive receive we should trigger a self-send right after?

[lehnberg]

Agree on no quick fixes.

• Automatically send coins to yourself for tumbling

Perhaps on every interactive receive we should trigger a self-send right after?

Can you help me understand how this helps? If it's automatic (and therefore predictable and detectable), wouldn't it be just as easy to monitor the next output that is being created?

[sesam]

The attacker can just wait to see when any triggering stops.
Even self-send to dandelionize(*) the kernel wouldn't help much against a resourceful attacker.

Grin users with any public id (keybase, IP:port, email file transfers, etc), to not be tracked, must use some kind of coin join with a serious amount of other users, and coin control.

(*) dandelionize: make a tx look like is mixed with someone else's transaction

[mcdallas]

Can you help me understand how this helps? If it's automatic (and therefore predictable and detectable), wouldn't it be just as easy to monitor the next output that is being created?

You could create multiple outputs and use multiple inputs like a coinjoin with yourself, something like grin wallet send <amount> -m self -s all -o 10. I agree if it was automatic and on by default it makes it much easier to detect.

Maybe you can only send/receive from people you are following/followed by in keybase?

This probably solves the problem with keybase (although slightly annoying) but the http listener has the same weakness.

[ignopeverell]

@lehnberg as @mcdallas mentioned, you'd coinjoin with yourself. The dust sender knows when the dust is spent because she's involved in the transaction. If that's been coinjoined, even within your own wallet, it's not true anymore and then the only way to learn about the new output is to listen to all transactions. Still doable for now, but definitely makes it less trivial.

[0xmichalis]

Perhaps on every interactive receive we should trigger a self-send right after?

It would be nice to provide the ability to do self-coinjoin at least manually. Though I guess I can already construct such a transaction manually (?) and potentially tunnel it directly to a mining pool that I trust wouldn't propagate over the network for increased privacy (feature request to all prospective mining pools operators watching:)).

[sesam]

1. Wallet W receives a tainted tracking kernel T.
2. W triggers a self-send. This tx includes private kernel P, T, and creates new outputs A, B, C.
3. If dandelionized with some X, Y, Z, the attacker might only see tx_ABCPTXYZ.
4. W later creates a tx with inputs traceable to some of A, B and C and private R, giving the attacker a good chance to statistically connect R back to P and through T, to the identity of the owner of P and R.

Possible defences?

1. reject dust = too small be split up into >1 output while paying fees for that split
2. Poisson-delayed self-send of potentially tainted/identity-tied coins
3. additionally wait, keeping the self-send transaction in a segregated tx pool, and when an upstream stemming peer (someone not correlated to your node) sends you a tx for you to stem-forward, you include your self-send in there before forwarding (but then careful so you don't fluff that yourself later on if the embargo expires)
4. automated coin control? W could track "source" and "taint" for its coins and prevent the user from spending tainted, and require decreasing taint through 2. + 3. above

For more inspiration: cypherpunk remailers, onion routing, ZeroLink.
Also good to consider how much privacy most grin users will want to pay for in time and fees.

[antiochp]

Closing this - keeping all as the default strategy.
Lets investigate the privacy concerns highlighted here (and potential solutions) as a separate piece of work.