I saw some recent comments about RuffCT/StringCT, which is a supposed improvement to RingCT. What is RuffCT/StringCT, and how is it different than RingCT? What improvements (if any) will this bring to Monero? What tradeoffs are there?
Add a comment
|
1 Answer
StringCT is an upgrade to the existing RingCT MLSAG ring signatures. It was initially informally known as RuffCT in honor of Tim Ruffing, who is one of the authors of the paper (soon to be published) from which this new type of ring signature originates. The initials of all of the authors of the paper are RTRS, so RTRS Ring CT == STRRRingCT == StringCT. Therefore the current working name for this upgrade to RingCT is StringCT.
Ring signatures are what give Monero untraceability. Therefore ring signatures that allow for higher ring sizes will mean greater untraceability, privacy and fungibility for Monero. Ring signatures that are more compact will give Monero greater scalability. StringCT delivers these improvements.
RingCT ring signatures are O(n) with respect to storage requirements, where n is the ring size. StringCT ring signatures are O(log n) in size. In our tests, this means a ring signature with 1024 inputs will only take twice as much space as a ring signature with 8 inputs, instead of requiring 128x the storage.
StringCT ring signature sizes are also independent of the number of real inputs. A RingCT ring signature with 20 real inputs and a ring size of 32 (meaning 32 * 20 = 640 inputs in total referenced in the ring signature) would require 41600 bytes of storage. An equivalent StringCT ring signature would only require 802 bytes of storage. As you can see, these are dramatic storage savings.
These savings are storage savings, and not computation savings. It has therefore been suggested that Monero may in the future be able to use GPU accelerated Elliptic Curve math to allow for higher ring sizes. GPU acceleration can mean up to 120x faster EC operations with modern consumer graphics cards[1], which would pave the way for higher ring sizes that are more computationally intensive.
[1] GPU accelerated EC operations paper: https://eprint.iacr.org/2014/198.pdf