4 ms·
> There is a reason why the authors limited their considerations to transactions before the RingCT update. No, they did not. The 80% figure comes from weakne
by indolering 10y ago
> There is a reason why the authors limited their considerations to transactions before the RingCT update.
No, they did not. The 80% figure comes from weaknesses of clients post RingCT update.
- codehalo 10y agoFrom the paper: Applicability to current and future transactions using RingCT. The weakness studied in this section is pri- marily a concern for transactions made in the past, as transactions using the new RingCT transaction option are generally immune.
- indolering 10y agoThe key phrase being "in this section" - section 3 deals with the older vulnerability while section 4 deals with RingCT transactions.
- polarized 10y agoThe section 3 vulnerability traces (aka "de-anonymizes") precisely no transactions at all. It indicates that the probabilities across potential outputs sources are biased, but does not offer any method at all to identify any actual source. The estimate of the bias given in the paper for the current default and typical usage is that the most recent potential source has a probability of 45% instead of the ideal 20%. In fact this likely applies to 100% of current transactions, not 80%. This is a known issue, and not ideal, and the quantitative results in the paper are helpful, but the paper does not show what you claim it shows.
- snovv_crash 10y agoYes, that's section 3. What about section 4?
- polarized 10y agoSorry my mistake. My comment was about Section 4, not Section 3. RingCT is immune to the methods in Section 3 as stated in the last paragraph of Section 3. Section 4 does not trace any transactions. It identifies a probability bias which make the ring sigs less efficient, but still functional.