I would like to have a comparison between the privacy features of Monero vs Ryo. I have heard some people say that these are privacy-oriented coins, and I would like to learn more.
Add a comment
|
1 Answer
History
Ryo is a fork of Sumokoin (SUMO), which itself is a fork of Monero (XMR).
Sumokoin (SUMO) launched with the following statement:
Sumokoin is forked from the source code of Monero cryptocurreny, one of the most innovative digital coins which is well-known for security, privacy, untraceability and active development, therefore, naturally inheriting all of those great features, yet without the burden of its past.
Sumokoin (SUMO) launched following the initial release of the "An Empirical Analysis of Traceability in the Monero Blockchain" paper released on 13 April 2017. While this paper introduced a number of Monero privacy limitations, the majority of them were limited to pre-RingCT outputs, ones that Monero had not used in meaningful numbers since January 2017. Future transactions were subject to the "guess-newest" heuristic for some time after, but Sumokoin (SUMO) did not change the selection algorithm. Thus, the claim that the fork removes the "burden of [Monero's] past" is dubious, since there was no practical benefit to Sumokoin (SUMO) transactions at the time of launch.
According to the Ryo roadmap, the following occurred in June 2018:
Sumokoin hardforked to ASIC friendly POW and Ryo continued on with the original chain.
Ryo forked following accusations that the Sumokoin (SUMO) team had printed additional funds for the founders than was publicly claimed. The Ryo team that resulted felt that the Sumokoin (SUMO) team was not knowledgeable enough to maintain a Monero fork.
Code Changes
Ryo began on a largely Monero codebase and merged a number of upstream features, including multisig, fluffy (compact) blocks, and bulletproofs.
Monero and Ryo use their own custom Proof of Work (PoW) algorithms.
Payment IDs
Monero has slowly been deprecating payment IDs, working on removing both forms completely and eventual subaddress adoption. Monero currently supports legacy payment IDs and short payment IDs. Ryo removed support for legacy payment IDs. Ryo and Monero automatically include a short payment ID in all transactions. Ryo developers argue that removing long payment IDs is good for privacy, which is true. However, it is incorrect to say that Ryo transactions are necessarily less identifiable as a result, since Ryo has fewer transactions.
I haven't found a good resource that reports the number of Ryo transactions per day, but I estimate there are less than 500. Monero typically has >4000, so there is a greater total number of other transactions that match various spend behaviors. Of course, users should reduce their exposure by avoiding payment IDs whenever possible.
Note that Monero and RYO now offer equal payment ID protections.
Ringsize
Monero uses ringsize 11. Ryo uses ringsize 25. Ryo proponents argue that larger ringsizes are better, which is strictly true. I have included a graph below indicating the proportion of rings that would be compromised (y-axis) if attackers had knowledge over a certain proportion of outputs (x-axis). Both cryptocurrencies provide essentially the same protection until 65% compromised. The larger ringsize protects similarly until about 82% compromised. This buffer of protection is useful.
However, it is simpler to have visibility over the same proportion of outputs for a smaller cryptocurrency than a larger one. Suppose I create 500 transactions in perpetuity on both Monero and Ryo, and I have no access to any other information. I would have visibility over about 500/(500+500) = 50% of Ryo outputs, while I would have visibility of only 500/(4000+500) = 11% of Monero outputs.
Put another way, let's compare the number of perpetual transactions I would need to have visibility over to compromise 1 ring per day. With Monero, I would need to create approximately 3100 transactions. With Ryo, I would need approximately 575. Ryo would need ringsize ~42 to provide the same protection as Monero against someone creating 3100 transactions.
Larger ringsizes may be better for privacy if you compare a small vs. large ringsize for a single network. However, large networks naturally have better protection from the other transactions and their entropy. Small cryptocurrencies need larger ringsizes to provide the same privacy level according to this one metric. There are many other metrics of assessing relative privacy levels, but this is one for a basic form of attack.
Relative Pool Information
The number of pool-related transactions do not scale proportionally to network size. Small networks have a higher proportion of pool-related transactions than large ones. While transactions paid to miners may partially scale, blocks mined don't scale the same way.
Public mining pools often provide a lot of public information that observers can use to have visibility over outputs. At the time of writing, https://ryo.miner.rocks controls ~60% of the hashrate, and they publish lists of blocks mined and transactions paid. Observers can use this information to construct a list of outputs that can only be spent by the pool, not by other network participants. Many Monero pools also publish this information, but the total impact of this information is lower for Monero since the mining pools are a smaller proportion of network activity.
Fees
Monero uses 3 main preset fee values. Ryo uses 1 main fee value. Single fees are better for privacy, but there are some usability tradeoffs when network congestion is high.
Transaction Structure
Ryo imposes some stricter transaction restrictions on the consensus layer in some cases, which prevents malicious or oblivious wallets from sending some types of revealing transactions.
Summary
Monero and Ryo are very similar, since they share most of the same code. Only a few parameters are changed between them. However, any changes to the code are relatively minor if the network is significantly smaller. Ryo has some strict improvements, but they need to weighed against Monero's larger network size. Comparing certain parameters in a vacuum without considering the wider network situation leads to false conclusions.