Estimating an Upper Bound for the Impact of Chain Splits on Monero

In early 2018, the Monero community and developers were preparing for the Monero v7 protocol upgrade when something caught us by surprise: Monero airdrops.

Airdrops were all the rage at the beginning of the year, with people forking cryptocurrencies with the hope of printing additional coins out of thin air. We had seen other communities subjected to these pumps and dumps, but we didn’t make the connection to Monero. Until MoneroV came along.

MoneroV was a ridiculous airdrop that claimed to “fix” many of the issues of Monero, most notably setting a fixed supply of MoneroV. The community generally found this prospect ridiculous, but the announcements set shockwaves of terror through the community. No one expected the fork to mean anything, but we were worried about the impact that chain splits had to privacy.

If a user sends one transaction on two chains, the real output in the ring signature is often revealed, since the key images are the same. Two transactions having the same key image and only shared output renders the ring signature useless and reveals the real output used in the transaction.

I hurriedly sought to understand the potential impact of chain splits on Monero privacy. I made this video in February which is mostly correct, though the “high-risk” zone is actually a few days before and after the split, not just a few days after. I communicated three major changes to the wallet behavior to mitigate these damages. I suggested a minimum ringsize increase from 5 to 7 with research expanding on MRL-0004. Ultimately, these protections were included in the Monero 0.12.0 release.

What Chain Splits Mean for Monero

Around this time, we were hit with two chain splits in short succession: Monerov6 (Monero Classic, Monero Original) on April 6 and MoneroV on May 3. I would like to reiterate that the community did not split; these forks went largely on their own and have seemingly died off.

Now that it’s several months after these chain splits, let’s investigate to see what the impact is. We can use an updated version of the Monero blackball tool and the same research table as before to estimate upper bounds for the proportion of outputs and the number of transactions that were compromised.

Here are the relevant results of running the blackball tool in late August 2018:

2018-08-21 10:21:07.248 7f7bb3e58c00 INFO bcutil src/blockchain_utilities/blockchain_blackball.cpp:1290 rct-key-image-attack: 31359 (0.45299%)
2018-08-21 10:21:07.248 7f7bb3e58c00 INFO bcutil src/blockchain_utilities/blockchain_blackball.cpp:1290 rct-chain-reaction: 8 (0.000115562%)

We’re going to take one number in particular: 8. This fits in nicely with our existing model, since this is the number of RingCT transactions that were compromised by a chain split chain reaction. We can use this number to estimate the proportion of compromised outputs in given windows.

We’re just taking a brief look at the data today to get some estimates, so a more verbose analysis will return much more specific data. Now let’s find a reasonable upper-bound.

Looking at the number of Monero transactions per day, it seems that it was close to 4000–6000 during the time of the splits. Let’s be conservative and select 4000 to get a higher upper bound.

Monero transactions per day. Source: https://stoffu.github.io/diff-chart/monero-tx-per-day.html

Now, we can use Excel and goal seek to manipulate our variables.

Let’s test ringsize 7 against ringsize 5 to see their differences, shall we? Since both of the chain splits occurred while Monero’s minimum ringsize is 7, we can test conditions where ringsize 7 leads to 8 compromised transactions. Here are the two we will test:

1. The maximum proportion of outputs compromised to cause all 8 of the transactions to be compromised in a single day.
2. The average proportion of outputs compromised such that 8 transactions would be compromised between April 6 and August 25.

To test the first scenario, we can run a goal seek to set the transactions compromised per day with ringsize 7 to 8. This results in 35.50% of outputs being compromised.

To test the second scenario, we can run a goal seek setting the total of the transactions compromised per day times the number of days (141 days) to 8. This results in 15.56% of outputs being compromised.

In short, 8 transactions would be compromised on average under situations where 35% of the weighted outputs are compromised for one day, or 15% are compromised for 140 days. The impact is the same.

Keep in mind that these percents are not completely accurate. If 6 or 10 transactions were compromised instead of 8 (for example), then these percents would change. Treat these as rough estimates.

We can also compare the average we found of 15.56% to the actual average of 0.45299% (given in the pasted data from the blackball tool). This suggests that the percent compromised was highly skewed to a small window, not equally spread out over a long time period. If we take all the outputs needed to compromise 8 transactions over a single day period, that would equal about 0.25174% of outputs over the 141 day period, a much closer number, even after excluding the year of RingCT outputs created before April 6.

We can go even further and estimate the real benefit of ringsize 7 over ringsize 5, testing again under the same scenarios. Under the first scenario, ringsize 7 results in 55 fewer compromised transactions (an 86% reduction). Under the second, it results in 330 fewer compromised transactions (a 97% reduction). The real number is much closer to 55 than 330 for the same reason explained earlier.

So here we are with our upper bounds. More thorough research should be able to find exact numbers.

Well, that’s all for this post. If you have any questions or comments, message me at @JEhrenhofer.