[PROPOSAL] Avoid selecting coinbase outputs as decoys by default #101

Video about blackballing public mining pool data.

Mining pools reveal information regarding what outputs they mine. They also typically list the transactions paid to miners. An attacker can compile a list of outputs that the pool controls and search for other transactions on the network that do not appear in the pool's list. This reduces the privacy of transactions by reducing their effective ringsize.

Note that we are not trying to increase the privacy of the mining pool data. This information is already public. We are trying to protect everything else by making this data less impactful.

One way to easily mitigate the threat of mining pool data is to configure the wallet software to avoid coinbase outputs by default. The only other ways to preserve these outputs to other network participants are to either have the pool 1) churn or 2) not publish transactions to miners.

I recommend that Wownero's official wallets avoid coinbase outputs by default. It's the best way to ensure a malicious pool can only have a limited impact on the network.

Alternatively, Wownero can say "screw it" and accept the risk, knowing a large ringsize provides built-in resilience against these attacks. However, in nearly every case a coinbase output is selected, it provides no protection for the user.

I also support this idea (excluding screw it part).

Good point. I'm not sure how difficult the implementation would be, but if
not too bad this would be interesting to pursue. This will then force
miners to not use the regular wallet right?

On Tue, Oct 16, 2018, 07:10 abhishek1104 notifications@github.com wrote:

I also support this idea (excluding screw it part).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/wownero/wownero/issues/101#issuecomment-430252561,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFrhk3tkccYDlwogSMbP8lIGyhskDXDBks5ulejfgaJpZM4Xbgfx
.

I'm all for maximizing privacy... +1

@jwinterm they would likely run the wallet in "pool mode" or similar

Monero's gamma distribution, though better for most known untraceability attacks, makes it far more likely for coinbase outputs to be selected, exacerbating these issues: https://np.reddit.com/r/Monero/comments/9qiwnn/why_are_there_so_many_recent_transactions_with/

If anyone has time to work on the infrastructure to allow me to empirically test the impact of coinbase outputs, please check out this GitHub issue.

Requirements:

Have wallets avoid coinbase outputs as decoys by default.
Add --pool-mode option to wallet startup, and/or add as a configurable option for individual transactions.
--pool-mode uses the normal selection algorithm, except it allows for the selection of coinbase outputs.
Add warning when sending coinbase outputs, saying that they are not well-protected by ring signatures. Recommend that users "churn," or send the transactions back to the same address, before sending out to other users using methods #5 or #6. Public pools won't care and will send out these outputs anyway without churning, and this only causes measurable harm to themselves and private pools. Private pools and independent miners need to churn to compensate for the general carelessness of public pools.
Add --churn-coinbase-separate <times> <blocks> command, which independently churns all coinbase outputs over <blocks> blocks. Default <blocks> = <coinbase outputs> * 100. Send churn transactions with one coinbase output every random(1,<blocks>) blocks. A more complicated selection method is recommended. After an individual output is churned once, churn according to a normal spend distribution (approx. 2 days) until it it churned <times> times. Default <times> = 2. Initial churn uses --pool-mode selection config, subsequent uses normal selection config.
Add --churn-coinbase-together <times> command, which churns all coinbase outputs as several inputs in a single transaction. Add warning saying this strongly attributes these coinbase outputs to one entity. Churns again until funds have been churned <times> times. Default <times> = 2. Initial churn uses --pool-mode selection config, subsequent uses normal selection config.
Maintain a list of outputs sent in transactions with change outputs. For instance, if transaction A has outputs A (to recipient 1), B (to recipient 2), and C (change to sender), then keep a list that says "C is connected to A and B." This list only needs to be generated for users of --pool-mode.
Use this list in --pool-mode when sending transactions. When sending outputs, check to see if they are in this list. If so, include all of the associated outputs in the ring signature. If there are extra remaining outputs to be filled, select using the --pool-mode method. This makes the change output appear identical to the other outputs when exchanges publish their outputs, and it helps preserve the integrity of the exchange change output.
Limit the number of outputs sent in --pool-mode to the ringsize or fewer. I believe that this is already the case in Wownero. For instance, the ringsize needs to be 20 or more for the network to allow users to send transactions to 19 recipients (20 outputs). If this is not the case, the protections in #8 are weaker but still better than nothing.

Requirements: 1. Have wallets avoid coinbase outputs as decoys by default. 2. Add `--pool-mode` option to wallet startup, and/or add as a configurable option for individual transactions. 3. `--pool-mode` uses the normal selection algorithm, except it allows for the selection of coinbase outputs. 4. Add warning when sending coinbase outputs, saying that they are not well-protected by ring signatures. Recommend that users "churn," or send the transactions back to the same address, before sending out to other users using methods #5 or #6. Public pools won't care and will send out these outputs anyway without churning, and this only causes measurable harm to themselves and private pools. Private pools and independent miners need to churn to compensate for the general carelessness of public pools. 5. Add `--churn-coinbase-separate <times> <blocks>` command, which independently churns all coinbase outputs over `<blocks>` blocks. Default `<blocks>` = `<coinbase outputs>` * 100. Send churn transactions with one coinbase output every `random(1,<blocks>)` blocks. A more complicated selection method is recommended. After an individual output is churned once, churn according to a normal spend distribution (approx. 2 days) until it it churned `<times>` times. Default `<times>` = 2. Initial churn uses `--pool-mode` selection config, subsequent uses normal selection config. 6. Add `--churn-coinbase-together <times>` command, which churns all coinbase outputs as several inputs in a single transaction. Add warning saying this strongly attributes these coinbase outputs to one entity. Churns again until funds have been churned `<times>` times. Default `<times>` = 2. Initial churn uses `--pool-mode` selection config, subsequent uses normal selection config. 7. Maintain a list of outputs sent in transactions with change outputs. For instance, if transaction A has outputs A (to recipient 1), B (to recipient 2), and C (change to sender), then keep a list that says "C is connected to A and B." This list only needs to be generated for users of `--pool-mode.` 8. Use this list in `--pool-mode` when sending transactions. When sending outputs, check to see if they are in this list. If so, include all of the associated outputs in the ring signature. If there are extra remaining outputs to be filled, select using the `--pool-mode` method. This makes the change output appear identical to the other outputs when exchanges publish their outputs, and it helps preserve the integrity of the exchange change output. 9. Limit the number of outputs sent in `--pool-mode` to the ringsize or fewer. I believe that this is already the case in Wownero. For instance, the ringsize needs to be 20 or more for the network to allow users to send transactions to 19 recipients (20 outputs). If this is not the case, the protections in #8 are weaker but still better than nothing.