How can individuals safeguard themselves and the community against a key reusing fork?

Question

Regardless of the true intention behind the MoneroV developers, it forking off the existing Monero blockchain poses danger to the privacy of Monero users. While the MoneroV forking date has been put off, it may (un)surprisingly occur punctually next month. And we definitely cannot be sure whether a State Sponsored Agency may be planning a similar attack in the near future.

I am concerned about what I, as an individual, can do to safeguard (1) my funds; (2) my privacy; (3) other Monero users' funds; and (4) other users' privacy.

Question: What can I do before and after the "fork attack" to mitigate its risks?

From what I've read in the linked QA and elsewhere, some people suggested the following, though I am not sure about their effectiveness, or whether these methods will actually expose me or others to greater danger.

1. Don't claim coins in fork
2. Churn after fork
   • Preferably to a new wallet
   • Preferably multiple times
   • Preferably using either (1) all key images being after fork, or (2) a good mix of pre- and post-fork key images
   • Preferably with a higher-than-default ringsize, and when others are also churning with the same ringsize. Note that the upcoming hard fork... I mean network upgrade... will increase minimum ring size to 7.
   • Preferably not right after the fork
3. Any non-technical measures e.g. redirect newcomers interested in the forked coin to original Monero; discourage exchanges to list fork coin...

Answer 1

First, there is no stealing possible, so your funds are safe ASSUMING THE MONEROV (OR OTHER KEY REUSING FORK) SOFTWARE IS NOT A TROJAN. If it is not, then the key reuse only affects one of the privacy layers Monero offers, and does not allow either double spending nor stealing. Of course, since monerov is currently closed source, it may be that the binaries are a trojan to steal keys.

The main danger by far is the unravelling of ring signatures caused by using the same pre-fork output on two different chains with different rings: since the key image on both rings is the same, an attacker can deduce the real input is on both rings, and using random rings means only one input will usually match. This can be prevented by reusing the same ring on all chains, in order for the intersection to be the whole set. This will be done automatically if both forks use the shared ring database which Monero included in response to this threat. The shared ring database ("ringdb") will store the rings used for your outputs, so they can be reused when spending the same output again. It will be included in Monero 0.12, which will be released in the next few days. Hopefully the monerov people will include this feature too. If they do, then its use will be automatic.

If they do not include it, or include a broken version of it, then it's only half automatic (on the Monero side), and you will have to be more careful:

• spend on the key reusing fork
• check the rings used by your key reusing fork transaction by running print_tx TXID on that fork's node dameon (the rings are near the top of the transaction printout)
• use the set_ring command in Monero's monero-wallet-cli to save those rings to the ringdb, eg:

set_ring KEY_IMAGE_HERE relative A B C D E F

A B C D E F should be the ring printed by print_tx TXID. Those are encoded as relative offsets. If you obtain the rings as absolute instead (maybe from a block explorer), then replace "relative" with "absolute" in the command above.

• then spend monero, and any ring will be reused as required.

Now, some people may not use this, and thus will strip themselves of privacy in the process. For these cases, Monero includes a second line of defense, to allow your rings to avoid using outputs which are known spent (since using one of those decreases the privacy ring signatures offer). This is the blackball database. This can be created locally if you have both chains using the monero-blockchain-blackball tool, eg: monero-blockchain-blackball ~/.bitmonero/lmdb /path/to/monerov/database. This will take a while to scan the databases. Once this is done, the wallet will automatically avoid the inputs which were found to be unsuitable.

Note that since this process takes time, the blacklist database will be made available on the getmonero.org website, and can be imported (using blackball FILENAME in monero-wallet-cli, or from the "Shared ringdb" page in monero-wallet-gui). It will be updated on the site from time to time, so can be imported regularly.

Last, a third line of defense is to alter the fake output selection algorithm:

The first one, called either segregate-pre-fork-outputs in monero-wallet-cli or "I will spend on a key reusing fork" in monero-wallet-gui, ensures that spending a pre-fork output only uses pre-fork fake outputs, since spending on both blockchains will moot post-fork outputs.

The second one, called either key-reuse-mitigation2 in monero-wallet-cli or "I might spend on a key reusing fork" in monero-wallet-gui, uses a selection of pre and post fork fake outputs to avoid special degenerate cases.

In any case, a key reusing fork will only affect ring signatures, and will not do anything against stealth addresses nor confidential transactions, the other two layers of protection in Monero.

As a last warning, be very wary of using your secret keys with other software, especially closed source. These are called secret for a reason.

Answer 2

This is information in supplement to user36303's comment.

I've created a high-level guide below on how to handle chain splits. Many of the actions can be taken with the steps listed in the other comment. Keep in mind that even if you do make transactions without claiming a chain split, you should commit to it. If you have even the slightest desire to claim these coins (suppose they peak in value later), then you will want to use the key-reuse-mitigation2 option. Using this option will reduce your privacy compared to what is the theoretical best, but it allows for greater flexibility.

1. Don't claim coins in fork

This is absolutely true. The best way to protect you and the network is to avoid chain splits completely. Even with precautions and special tools, you will be better off not claiming funds.

2. Churn after fork

I'll talk more broadly about churning and how it could mitigate the risks of chain splits.

In general, you churn to increase the anonymity set of your transactions without choosing an unusual ringsize. For the sake of chain splits, you can churn before and after the split to make the key image association essentially meaningless: no one can tell what happens before or after the transaction even if the transaction is compromised.

It is difficult to estimate the exact benefit of churning before the split since the proportion of to-be compromised UTXOs are unknown. If many people claim the funds, then this could pose a problem. With ringsize 7, the recommended number of churns is 8.

Churning after the fork is also though. It is uncertain how many of the decoys will be compromised. It is possible that the anonymity set increased through churning will be much smaller than the number of decoys referenced, since many of these decoys could be known to be false.

Churning within 2 days of the chain split has a high probability of decoys being compromised. While it is unlikely that churning in this situation will reduce your privacy, it will likely have limited or nearly no benefits. As you can see in the guide, I strongly recommend waiting at least 2 days after the split to churn if that is your desire. Even 2 days after, it is possible for the churns to be less effective. You could churn 12 times after the two day waiting period to be sure that it has the same protection even if half the decoys in each of these transactions are compromised.

Keep in mind that churning places stress on the network. It is not realistic for everyone to churn. I only reference it for extreme situations. If you do not have an extreme situation, you are likely fine with the steps outlined in the plausible deniability guide.

Also note that most people recommend churning with the current minimum, or at least most-used, ringsize. At the time of the first chain split, this number is 7.

3. Any non-technical measures e.g. redirect newcomers interested in the forked coin to original Monero; discourage exchanges to list fork coin...

This is a social threat, since it only becomes one under certain actions. If many people claim the funds, then it will have a larger impact (especially within the first 2 days after). If no one claims the funds, then the impact will be essentially zero. However, keep in mind there is the potential for significant impact within these first few days. Whether it is realized is something that will need to be seen.

Final Thoughts

The guides I linked and the tools user36303 referenced only work if you are permitted to use the same ringsize and ring member set on the split. This is not always the case. Suppose I forked "MoneroLight" with mandatory ringsize 1 (0-mixin) transactions. These tools provide no protections when claiming these funds, since there are no decoys. In such a scenario, the only way to stay safe is to not claim the funds. Churning aggressively before and after the split may mitigate the damage to you, but the damage will already be done to the network.

Also, churning is not very well researched. Be careful of timing attacks, IP address attacks, and other considerations that will reduce the effectiveness of churning in practice. Churning is unlikely a magic bullet that solves all the problems, though it likely still provides more benefits than harms. Please wait further research before seeing if churning is actually beneficial.