14:28:38 <cankerwort[m]> Are the verification numbers on triptych (which indicate ringsize ~100 has comparable verification time as current transactions) inclusive of the increased read/write actions to find x10 number of ring members in the block chain file? Or do those preliminary numbers only deal with the "self contained" verification?
14:28:48 <cankerwort[m]> If these questions even make sense
14:29:29 <sethsimmons> They're the verification time for the entire transaction AFAIK, including ring members at each ring size.
14:30:31 <nikg83[m]> <cankerwort[m] "Are the verification numbers on "> kayront: read/write would be for blocks and as someone already told trx size would be same as it is right now ; you don’t next 100time read/write
14:30:56 <cankerwort[m]> But how could this be tested/ measured without a ~100GB blockchain to perform the disk operations on?
14:31:34 <cankerwort[m]> But you need to go look further back in the block chain to verify each ring member, no?
14:33:04 <cankerwort[m]> in other words I am asking if speed tests on triptych have accounted for the fetching of data to verify as well as the actual verification
14:34:15 <cankerwort[m]> Which intuitively seems like it would only ever scale linearly (the fetching/searching aspect)
14:34:45 <sethsimmons> Hmm, I think I confused something in my explanation of HDD vs SSD
14:35:00 <sethsimmons> To verify a ring-member you don't have to find the last transaction, as you don't know when it was true-spent.
14:35:24 <sarang> None of the numbers provided by the codebase test framework account for such lookups at this point
14:35:25 <sethsimmons> So to verify a transaction you validate that all key images are valid and not double-spent
14:35:34 <sarang> (for Triptych)
14:35:43 <sethsimmons> I'll let sarang take over :)
14:36:05 <cankerwort[m]> Yes Seth it was that explanation in the other channel which brought this thought up
14:36:15 <sethsimmons> Yeah, sorry, I worded things poorly there.
14:36:42 <sarang> Note that output binning may be useful for reducing this time
14:36:51 <sarang> by requiring certain output groups always to appear together
14:37:13 <cankerwort[m]> Thanks for the info sarang. I am wondering if long term the scaling of x10 lookups might not be worth the "privacy scaling" of x10 ring members
14:37:51 <sarang> Again, keep in mind that binning may be helpful in a way that makes the lookups scale better than the "worst-case scenario" so to speak
14:37:53 <sethsimmons> Verification doesn't require x10 the IOPS when bumping ring size x10 using Triptych unless I'm misunderstanding how verification works.
14:38:07 <sarang> If instead of pulling 100 outputs you pull 10 fixed bins, for example
14:38:28 <sarang> sethsimmons: to verify a transaction you need the previous outputs for the math to work
14:38:37 <cankerwort[m]> As more ring members has diminishing returns (per sgp's spreadsheet) while a fixed number of lookups per txn in am ever growing block chain might not be sustainable
14:39:16 <cankerwort[m]> Because read/write is the bottleneck for most users
14:39:20 <sethsimmons> <sarang "sethsimmons: to verify a transac"> Hmm, so disk is going to get hit harder and harder the more we scale ring size, independent of verification time of the transaction itself?
14:39:45 <sarang> Yes, but again, depends how you select anonymity sets
14:39:50 <sarang> which is TBD
14:40:02 <sethsimmons> I didn't realize that, I thought verification times took that into account.
14:40:06 <sethsimmons> Is there any way to validate that change in concrete numbers?
14:40:20 <sethsimmons> <sarang "Yes, but again, depends how you "> Yeah, might need to explore binning before jumping to Triptych then
14:40:24 <sethsimmons> Or something similar
14:40:26 <sethsimmons> Hmm
14:40:34 <cankerwort[m]> Binning is an ongoing area of research from what I remember you saying before?
14:41:21 <sarang> Yes. It was specifically introduced in the context of Monero several years back by Miller et al.
14:41:41 <sarang> but it's part of a broader and more complex question of anonymity set selection
14:42:40 <sethsimmons> So if we implemented Triptych + 128 ring size today we would see a massive increase to IBD time and disk speed requirements.
14:42:54 <sethsimmons> inb4 new "MoNErO DoESnT ScALe" FUD
14:43:21 <sethsimmons> <sethsimmons "So if we implemented Triptych + "> Massive is a poor choice -- substantial is a better term.
14:43:35 <sethsimmons> Would be interesting to get a hard comparison of that cost.
14:43:54 <sethsimmons> Do you have any estimates or ways to estimate that, sarang?
14:44:11 <cankerwort[m]> I immediately searched for the Miller paper because I would like to know more about implications of binning, and I accidentally found this paper from last month:
14:44:11 <cankerwort[m]> https://arxiv.org/abs/2001.03937v1
14:44:51 <cankerwort[m]> Might be of interest
14:45:23 <cankerwort[m]> Binning paper is "an empirical analysis of traceability in the Monero blockchain"?
14:46:07 <sarang> I am not the person to ask for details on disk-related timing, unfortunately
14:46:22 <cankerwort[m]> <sethsimmons "Do you have any estimates or way"> I would assume this is hard to quantify without a simulated blockchain, and the effect would become worse as the block chain grows
14:46:57 <sarang> cankerwort[m]: keep in mind that output selection is heavily skewed in time toward newer outputs
14:47:03 <sethsimmons> <sarang "I am not the person to ask for d"> All good, wasn't sure if this was something we could simulate using existing tools/code.
14:47:07 <sarang> it is a random selection, but not uniformly random
14:47:34 <sethsimmons> Yes, so it would shortly be validating almost only Triptych transactions post-fork.
14:47:42 <sethsimmons> *outputs
14:47:54 <cankerwort[m]> Oh yah I forgot about typical spend pattern bias
14:48:02 <sarang> It would _only_ validate Triptych-generated outputs for key image reasons
14:48:16 <sarang> You cannot mix them
14:48:44 <sethsimmons> ahhh
14:48:45 <sethsimmons> true
14:54:12 <cankerwort[m]> I think these matters should definitely be considered when selecting a future ringsize anyways, particularly considering the diminishing returns on increasing it. The meme value of "100+ ring size" might be overstated.
14:55:52 <sarang> The number alone does not determine robustness against all analysis, to be sure
14:56:17 <sarang> It's possible to select a large anonymity set poorly, and more difficult to select it more optimally
14:56:44 <sarang> Different users likely have different threat models
16:17:09 <hautdryep> 'Oddly, no one who was directly involved with the SIR-C missions and currently still working the Lab, remembers the name Howard Chu, except for one who vaguely recalls Eugene Chu as having a brother names Howard'
16:17:09 <hautdryep> Ed Caro, NASA Chief Engineer. cryptogazette.com/wp-content/uploads/2019/12/1-768x1445.png
16:27:13 <strider[m]> Is there any new research into ring selection strategies? I see all these new proof schemes for uber massive rings, but I haven't heard any new research about how rings should actually be selected
16:27:43 <strider[m]> Im excited for uberrings :)
16:27:56 <gingeropolous> i haven't seen anything specific come across this channel, regarding immediate implementation for triptych
16:28:58 <gingeropolous> i presume the existing selection is assumed to work with larger ringsize, but i don't know if anyones crunched the numbers
17:24:40 <UkoeHB> Idk what numbers would need to be crunched. It should work fine
17:59:27 <sarang> The existing method (modified to handle the restriction on the new output pool) does work, albeit with larger ring representation size overall within a transaction
17:59:36 <sarang> but it's certainly not optimal
18:48:47 <humandoinghumant> Hi guys, I'm a masters student currently enrolled in a privacy technologies seminar course. The course has a research project component where we need to do some small but novel work in a privacy-related topic and I'd like to do something related to monero, if possible. So I've come here to ask if anyone has any ideas/starting points for a project that might be feasible over a 2-month (mid-feb to
18:48:47 <humandoinghumant> mid-april) timeline?
18:51:31 <moneromooo> Hi. Maybe a good way to select ring inputs for large ring sizes.
18:51:52 <moneromooo> Binning is one such possibility.
18:52:39 <moneromooo> If we use larger ring sizes, the space needed to describe a ring grows. Binning or other techniques can decrease that space.
18:53:12 <moneromooo> Another technique is deterministic selection, where you'd specify a seed and offset.
18:53:21 <moneromooo> There may be other interesting ideas around that.
18:54:11 <moneromooo> A related subject is ring reuse, where verifying several transactions where a ring is reused can be done faster than if not.
18:54:26 <moneromooo> I'm not sure how much this overlaps the privacy angle though.
18:55:43 <endogenic> humandoinghumant: 👏👏👏
19:00:54 <humandoinghumant> moneromooo: Ya, I saw there was discussion above regarding that. Seems like a good idea! If not too inconvenient, could you point me in the direction of some relevant papers for getting started?
19:02:13 <moneromooo> I do not have the url, but Miller et al discussed binning in "an empirical analysis of traceability in the Monero blockchain".
19:07:54 <humandoinghumant> A quick peek and this paper seems like a great starting point, thanks!
20:20:41 <sarang> humandoinghumant: Keep in mind that the paper no longer reflects exactly how we choose anonymity sets anymore (we've implemented changes since then)
20:20:46 <sarang> But its work is still quite relevant
20:37:31 <geonic> https://www.business-standard.com/article/technology/swiss-firm-terra-quantum-uncovers-vulnerabilities-that-imperils-encryption-121020800131_1.html
20:41:16 <geonic> relevant thread: https://twitter.com/aszepieniec/status/1358868716751118339?s=20
21:47:09 <sarang> Business site reporting on a press release reporting on non-published commercial work? Sign me up!
21:52:00 <sgp_> lol
23:52:21 <sgp_> anyone here against me adding the relay to matrix.monero.social which is run by the Monero Core Team?