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?

If these questions even make sense

They're the verification time for the entire transaction AFAIK, including ring members at each ring size.

<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

But how could this be tested/ measured without a ~100GB blockchain to perform the disk operations on?

But you need to go look further back in the block chain to verify each ring member, no?

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

Which intuitively seems like it would only ever scale linearly (the fetching/searching aspect)

Hmm, I think I confused something in my explanation of HDD vs SSD

To verify a ring-member you don't have to find the last transaction, as you don't know when it was true-spent.

None of the numbers provided by the codebase test framework account for such lookups at this point

So to verify a transaction you validate that all key images are valid and not double-spent

(for Triptych)

I'll let sarang take over :)

Yes Seth it was that explanation in the other channel which brought this thought up

Yeah, sorry, I worded things poorly there.

Note that output binning may be useful for reducing this time

by requiring certain output groups always to appear together

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

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

Verification doesn't require x10 the IOPS when bumping ring size x10 using Triptych unless I'm misunderstanding how verification works.

If instead of pulling 100 outputs you pull 10 fixed bins, for example

sethsimmons: to verify a transaction you need the previous outputs for the math to work

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

Because read/write is the bottleneck for most users

<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?

Yes, but again, depends how you select anonymity sets

which is TBD

I didn't realize that, I thought verification times took that into account.

Is there any way to validate that change in concrete numbers?

<sarang "Yes, but again, depends how you "> Yeah, might need to explore binning before jumping to Triptych then

Or something similar

Hmm

Binning is an ongoing area of research from what I remember you saying before?

Yes. It was specifically introduced in the context of Monero several years back by Miller et al.

but it's part of a broader and more complex question of anonymity set selection

So if we implemented Triptych + 128 ring size today we would see a massive increase to IBD time and disk speed requirements.

inb4 new "MoNErO DoESnT ScALe" FUD

<sethsimmons "So if we implemented Triptych + "> Massive is a poor choice -- substantial is a better term.

Would be interesting to get a hard comparison of that cost.

Do you have any estimates or ways to estimate that, sarang?

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:

Might be of interest

Binning paper is "an empirical analysis of traceability in the Monero blockchain"?

I am not the person to ask for details on disk-related timing, unfortunately

<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

cankerwort[m]: keep in mind that output selection is heavily skewed in time toward newer outputs

<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.

it is a random selection, but not uniformly random

Yes, so it would shortly be validating almost only Triptych transactions post-fork.

*outputs

Oh yah I forgot about typical spend pattern bias

It would _only_ validate Triptych-generated outputs for key image reasons

You cannot mix them

ahhh

true

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.

The number alone does not determine robustness against all analysis, to be sure

It's possible to select a large anonymity set poorly, and more difficult to select it more optimally

Different users likely have different threat models

'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'

Ed Caro, NASA Chief Engineer. cryptogazette.com/wp-content/uploads/2019/12/1-768x1445.png

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

Im excited for uberrings :)

i haven't seen anything specific come across this channel, regarding immediate implementation for triptych

i presume the existing selection is assumed to work with larger ringsize, but i don't know if anyones crunched the numbers

Idk what numbers would need to be crunched. It should work fine

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

but it's certainly not optimal

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

mid-april) timeline?

Hi. Maybe a good way to select ring inputs for large ring sizes.

Binning is one such possibility.

If we use larger ring sizes, the space needed to describe a ring grows. Binning or other techniques can decrease that space.

Another technique is deterministic selection, where you'd specify a seed and offset.

There may be other interesting ideas around that.

A related subject is ring reuse, where verifying several transactions where a ring is reused can be done faster than if not.

I'm not sure how much this overlaps the privacy angle though.

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?

I do not have the url, but Miller et al discussed binning in "an empirical analysis of traceability in the Monero blockchain".

A quick peek and this paper seems like a great starting point, thanks!

humandoinghumant: Keep in mind that the paper no longer reflects exactly how we choose anonymity sets anymore (we've implemented changes since then)

But its work is still quite relevant

relevant thread: twitter.com/aszepieniec/status/1358868716751118339?s=20

Business site reporting on a press release reporting on non-published commercial work? Sign me up!

lol

anyone here against me adding the relay to matrix.monero.social which is run by the Monero Core Team?