All right, crazy idea time.

The second version of the “ An Empirical Analysis of Traceability in the Monero Blockchain” research paper by Möser, et. al included some interesting information on public pools. They looked at the information that public pools shared with miners and others.

This is the first piece of research that I know of that sought to evaluate the impact of public mining pool information. They also estimated the proportion of transactions that are related to pool mining. As you can see in the chart below, the proportion of pool transactions in 2015 is extremely high.

This creates a problem. Pools have an incentive to share information with miners. Miners like to know when the pool mines blocks and makes payments. This information reduces pool corruption; if they report 1/4 of the network hashrate, people will be suspicious if the pool only claims to mine 1/20 of the new blocks, for instance.

I sought to look further into the information that public pools make available in 2018. The information can be divided into two main types of information: coinbase outputs and transaction outputs. Coinbase outputs are those which are mined from a block reward. If pools publicize a list of blocks that they mine, observers know that the pool earned the coinbase output associated with this block. Coinbase outputs contain the block reward and transaction fees.

Transaction outputs in this context refer to outputs generated in other transactions that pools control. For instance, suppose a pool mines block A and receives its associated coinbase output, value 1 XMR. It then pays out 0.5 XMR to one miner. The pool creates a transaction with two outputs, each for 0.5 XMR. The pool receives this change output, and it publishes this payout transaction for others to see.

Initially, users do not know which of the outputs is a change output. However, if a pool later creates a transaction spending it, then users know that the output was spent in that transaction. It could not have been spent in any others where it is used as a decoy. We need to prevent this from happening.

I cover strategies to address these issues in the below Breaking Monero episode and my DEFCON talk. I have a master deck on all the known possible strategies to limit leaked information, but that’s not the point of this post.

Breaking Monero Episode 10: Public Pool Outputs

All right, back to coinbase outputs.

Under normal Monero network conditions (when there are no secret ASICs, for instance), public pools represent a huge proportion of mining power. The unknown hashrate, which includes private pools and solo miners, was literally a rounding error on April 9, 2018.

Nanopool, Miningpoolhub, SupportXMR, MineXMR, DwarfPool, and most other pools share the blocks they mine. I could not immediately find the information for f2pool and Minergate, so let’s conservatively say that 88% of the coinbase outputs could be directly matched with public pool data.

If clients selected a random coinbase output around this time, that means there was about an 88% chance that this coinbase output would be heuristically dead. Observers could identify that this coinbase output was spent by the pool, not other users. There is a lot of nuance here, but the exceptions are quite rare. Especially rare for these coinbase outputs.

Furthermore, most users aren’t likely to spend coinbase outputs anyway. Keep in mind that people who mine on pools never possess these outputs. They are paid out different ones. The only people who would actually spend coinbase outputs for real are pools and those with solo miners or private pools. It takes a lot of hashrate to consistently mine blocks. Hardly anyone does it alone.

I argue that selecting coinbase outputs as decoys in normal transactions is high-risk. Most of the time, we can directly show the funds were spent by a pool in another transaction. The vast majority of the time, each selected coinbase output lowers users’ effective ringsize by 1. If users create ringsize 11 transactions with 5 coinbase outputs, their effective ringsize is actually 6. This leaves them more vulnerable to other attacks. Not great.

What Can Monero Do?

Monero has a few options, each with their own drawbacks.

One solution is to adjust the selection algorithm to select fewer of these outputs on average. This has been discussed in length with the Monero Research Lab. A new selection algorithm should be added soon. However, users will still use about 1 coinbase output per transaction on average. We would still be essentially wasting a decoy for most transactions.

Monero can ask users to download and run the spent-output tool and pull in mining pool data. Users who do this would avoid using these coinbase and transaction outputs as decoys. This is currently partially possible, but there are many implementation limitations. These lists take hours to generate. The pool APIs are often rate-limited. You can’t import them into any mobile wallets, only the official GUI and CLI. Plus, they are prone to manipulation. Users who ask pools for information could receive false data, and users who download spent output lists generated by other users (like mine at moneroblackball.com) are at risk of these being tampered with. It’s no good as a network-wide solution either.

In my opinion, the most obvious solution is to accept that there is no way for normal users to conceivably spend coinbase outputs. They will most likely be regarded as decoys. Wallet clients should avoid selecting them entirely.

Users don’t need to create crazy lists or worry about receiving potentially false data. The solution would just magically work on all Monero wallets. There would be no additional blockchain bloat. Win-win, right?

Sort of.

Sure, it’s a clear win for normal users. And public pools are indifferent, since they already publish this information anyway. If they cared about their privacy, they wouldn’t publish this information.

But private mining pools and solo miners are negatively impacted. The current selection algorithm essentially “averages” out the way people spend Monero. Coinbase outputs are outliers. I argue this warrants treating them differently.

Private miners want to spend Monero without allowing others to know that they mined those coins. They want to protect the source of their funds. If users no longer add entropy to these coinbase outputs, then their total entropy set is reduced.

However, Monero could institute a consensus requirement that any ring signatures with coinbase outputs can only contain coinbase outputs. This would add a small amount of entropy from other private mining pools. Of course, we are talking about a 90% compromised scenario here, where Monero would need a ringsize of 45 to hide the real coinbase output 99% of the time. Private miners would have less privacy sending coinbase outputs to others directly compared to the current system.

Instead, private miners should just churn. If they have enough hashrate to mine blocks consistently, they can mine their churn transactions for free. If a solo miner lucks out, they probably aren’t going to complain too much about paying an additional half cent to regain some privacy.

The problem doesn’t go away entirely. Users who select outputs created from coinbase-only rings can be used in other heuristics. But it’s still incrementally better than the current situation and won’t lead to large-scale marked spent outputs. For this to work however, mining pools must adjust their behavior to send one of these generated outputs as a payout and to make unclear which output is the change output they spend later. With these changes, these outputs are protected by plausible deniability even when spent by public pools.

Ultimately, I think that the harm to private miners is extremely small in comparison to the benefits to the network. Monero has thousands of transactions per day, and (nearly) each one has wasted decoys. Private miners are only a fraction of the total Monero network under normal scenarios (unless we want to start defending private ASIC manufacturers). By asking them for a favor, the rest of the network can benefit tremendously.