Monero Fork XMV Changes Tact, Promises ‘Open Source’ and Key Reuse Safeguards
The airdropped fork of Monero, MoneroV (XMV), recently delivered an announcement promising they would open source their code, and take the necessary safeguards to minimize their impact on one aspect of Monero’s fungibility, ring signatures, if users decide to claim XMV.
BTCManager first reported on MoneroV in February 2018, with the fork looking like it could deal some minor damage to the privacy of the Monero (XMR) blockchain. Some Monero enthusiasts were banned from the MoneroV Reddit channel for raising awareness of the privacy implications for, chiefly, their own chain, as well as Monero’s. Following a second planned fork date anticipated May 2, 2018, at block 1,564,965 (the first date penned was March 15, 2018), the MoneroV team have changed tact.
Initially, there were to be no mitigations for key reuse, and the wallets were thought to be closed source, which presented two problems for users of monero. First, The key reuse could be used to reduce the effectiveness of ring signatures, meaning if that a large proportion of monero users claimed XMV, they could risk putting a dent in the privacy of others – much like a negative externality, the eagerness of a large group of users could introduce a slight risk for the entire ecosystem.
Secondly, the closed source wallets mean that when users are trying to claim XMV, they will expose their private keys to software they cannot verify and hence could be at risk of an attack. When claiming the XMV, it was feared the user would have to enter their monero private key which is not supposed to be shared with anyone.
A Change of Mind
But now the MoneroV team have seemingly changed their minds.
Like the parent chain, MoneroV will also support an anti-ASIC stance, standing in contrast to the other Monero spin-offs. In an email to BTCManager on April 18, the MoneroV team wrote:
“We have included the shared ring database (“ringdb”) feature that was created by the Monero team. Essentially, any previous privacy concern was mitigated altogether.”
The shared ring database feature was implemented in response to the initial MoneroV announcement.
Secondly, they have promised that the source code will be “published on GitHub publicly for the community to audit before it is released in a downloadable form.”
At the time of writing, there is little activity on their GitHub, with three developers listed on the code repository. LucasJones, as well as two others, seem to be the only contributors. Lucas Jones is most likely a pseudonym; a quick Google search shows a lot of hits and mainly refers to a fictional character in an American soap. With just five days until the fork, there is no substantial code available for anyone to scrutinize.
As for the open source claim, we just have to wait and see if they keep their word. Responding to BTCManager with regards to why the code is not open sourced at present, the MoneroV team replied, “The reason it’s not published earlier is to prevent phishing attempts like ones occurred to other coins (someone will definitely publish a fake “MoneroV GUI” to steal user information before there’s an official one, etc.) and also technical as the seed node ip’s can not be publicly known prior to the fork.”
However, Justin Ehrenhofer of Monero said in an email that he wasn’t convinced and strongly advised against claiming the forked coin:
“I have never bought their argument for delaying the code publication. Even if it was released now, you cannot expect people to audit the code in time. I strongly advise against using the fork.”
The MoneroV team also hinted at a ‘unique difficulty adjustment’ which may be the pull request Masari‘s developer submitted to Monero’s master branch when ASIC miners and others continued the legacy v6 chain, although creating four ‘coins’ from the process, “We have incorporated a new, unique difficulty adjustment algorithm that will mitigate attacks on the network including block mining difficulty manipulations and lagging, as was the case in the Monero blockchain after the April 6 update.”
The Risk to Users Subsides but not Fully Eliminated
Although we see a change of tact, there are some extra steps needed to ensure there are no adverse effects on either the parent or MoneroV chain.
Monero contributor Ehrenhofer stated he was pleased that replay protection and sharedringdb were to be included. However, there are still some caveats:
“Unfortunately, the shared ringdb only mitigates the issue if widely used. They need to follow up with the exchanges and mining pools to make sure that they all use the database.”
When asked about following up with exchanges and mining pools, at the time of writing, the MoneroV team did not reply to BTCManager’s email.
MoneroV will be supported by many small exchanges, which are listed on the MoneroV website, and HitBTC is the only one that stands out. With limited exchange support and a higher ringsize implemented in XMR’s scheduled upgrade, Ehrenhofer said that the fork is unlikely to have a major impact on the privacy of Monero users:
“With ringsize of seven, MoneroV needs at least ~50 percent of transactions to use this feature to keep the proportion of compromised transactions low, while Monero needs a lower number. Thus, this means the potential impact on Monero is quite small.”
Bittrex Declines Support for XMV
Following the rejection of Bitcoin Private (BTCP), the offshoot of bitcoin and zclassic, Bittrex has also passed on MoneroV according to a tweet from April 26, 2018. Another large exchange that trades XMR, poloniex, has folowed suit. Maybe the forking mania has taken its toll and some exchanges are beginning to get sick of it.
The cryptocurrency exchange wrote in a statement, “Their team recently contacted us, but they did not apply in time to complete our token review process before the fork date. If we make any changes, we would publish an update both on our support site and on our Twitter handle.”
Whether this is down to the negligence of the MoneroV team or the Bittrex team is hard to determine, but some traders have criticized the exchange for not supporting the fork, given that they can acquire the forked coins for themselves from the monero they hold. A similar accusation was leveled at Bittrex when they declined support for BTCP.
In summary, while MoneroV’s move to incorporate shared ringdb, replay protection, and the CryptoNightv7 algorithm to fend off ASICs is welcomed by monero enthusiasts, exchanges and mining pools will also have to use the same database to prevent any issues involving key images.
So while our first article on XMV warned of a potential scam and blow to privacy, the situation has improved somewhat, and the risk to user privacy has subsided somewhat. With observers waiting for the source code to be published, it looks as if MoneroV’s change of tact is not sufficient or convincing enough.