I spent some time in Excel with my perf test data. This is probably the most important high-level-view plot.

Basically, my take-away is we will probably have to accept 64-member rings. Note that BOTH axes are log-2.

Since I know people will ask... here is tx size.

These are 2-in/2-out transactions.

koe000: What is the significance of decomp.n and decomp.m? They have a big effect on verification times

From what I see in the data

It is how reference sets are handled by grootle proofs. n^m = ref set size

I found that 3-series was slightly better than 2-series, and >3 was either equal to or worse than 2.

For transaction size*, verification costs were independent of decomposition base.

wow, so sizewise a 128 ringmember seraphis is the same size as a 32 ringmember triptych.

Rucknium

and squashed a 128 is about 16 msec?

I like this combined view better.

gingeropolous[m]: more like 18msec

17.6*

and a current clsag ringsize 11 is like 9msec?

gingeropolous[m]: I really like how clean this data is :) thanks to your nice machine

glad it worked out!

yeah about 9msec in this poc

though, should we get #s on different processors etc?

right, but they should still be 'relatively' the same (proportionally)

yeah

With batching, squashed can shave off another ~2ms I think.

I'm not sure how useful that ^ is.

<UkoeHB> "For transaction size*, verificat..." <- What do you mean by this?

Check my 'decomp' image. The verification lines all match, while tx sizes don't line up.

With my OLS regression approach, I'm seeing both decomp.n and decomp.m have a substantial effect on verification times, with the effect of decomp.m being larger. But my approach may be inappropriate here.

Yes, I mean verification costs as a function of ref set size (as a function of decomposition) are the same if you change the decomposition base (n). The ‘variable relation’ is the same.

So, no "interaction effect" between ref set size and decomp.n

I guess?

verif.time = beta_1 * ref.set.size + beta_2 * decomp.n + beta_3 * ref.set.size*decomp.n + error

Then beta_3 = 0

There is no combined effect, I think we are trying to say

All the effect of ref.set.size and decomp.n on verification time is accounted for by their individual effects in isolation rather than their combination. It's probably not an important point.

<koe000[m]> "mock_tx_perf_z2a_2_refset.png" <- koe000: mind if I share this on Twitter, or too early for that?

Also, thank you all for producing such clean charts/data this early on! Extremely useful for the non-statisticians among us 🙂

sethsimmons: it is a bit early, I want to clean up the charts a bit

UkoeHB: Definitely understand, will put it in the backlog 🙂

Thanks for all your work on Seraphis! Looking very exciting.

UkoeHB: does seraphis reduce or increase the number of communication rounds necessary for multisig compared to monero today?

I know triptych increased the number

boogerlad[m]: it is the same as currently

What's the goal here? To determine best algorithm in terms of performance etc?

Yes, and the best design choices for each algorithm.

The biggest decision is ring size. I don't think we should choose a ring size that causes much slower tx verification than current tx.

UkoeHB: Should I try to do more visualizations? I am somewhat hindered by the fact that I don't understand the meaning of some of the variables.

Rucknium[m]: I think what I have right now will work.

Today I will write an MRL github issue discussing the results.

Ok sounds good

valuable to do regression, try to determine a model?

seems like the bulk of the work is in determining trade-offs

Eh idk if a model would be super useful when the final decision is based on heuristics and eye-balling it.

and id hope there might be more optimizations eventually

is verification a single threaded task?

Afaik you can verify multi-threaded, so long as key-image checks are atomic.

UkoeHB: I think choosing a ring size that approximately equals the current verification time is the best option

thats gonna be like 16

and a 16 seraphis is larger than a 16 clsag :(

If light wallet servers become more of a thing, a bump in verification time isn't the worst thing in the world

well i guess the question is what do we mean by "current verification time", because afaik we're all on board for a ringsize 16 clsag in the next hf

so that'll get us a ringsize 64 seraphis

~~

It might be possible to justify 128 using the squashed variant, which benefits a lot from batching. Needs careful thought.

The danger of small ring sizes is rising. It's a tough call, but I think sacrificing longer verification times for greater privacy is what many users would prefer.

yeah, that plus output tagging is gonna drastically change the UX on the wallet side

64 seems like a chunky increase for a small size/verification increase. Hopefully with OSPEAD, binning and other improvements to the decoy selection we'd end up with a "smarter" 64 which is better than a naive 100+

The thing is, we have these benchmarks for verification times -- they are easy to do and easy to grasp. What we somewhat lack is a sense of the privacy risks that correspond to a given ring size. That's hard to do and maybe hard to grasp (I'm working on it).

i dunno man.... if i have something i wanna hide in a bunch of other things, id pick more other things over less other things, provided those things were picked with same mechanism

:)

Question about RandomX: Could you run it with a scratch space size of like 200gb and get a storage-hard algorithm instead?

sech1 hyc ^

or like RAM-hard

RANDOMX_DATASET_BASE_SIZE is limited to 4 GB, but technically you could increase RANDOMX_DATASET_EXTRA_SIZE to ridiculous values

But as it is now, it will require 200 GB of actual RAM, not SSD

you could mmap the SSD space but it would be incredibly destructive

hyc: But it would have less power use, right?

and chia already has that problem, not sure it's worth retreading the same path

sech1: how so? Couldn't I just mmap 200 GB worth of space?

Chia has additional stuff that makes their PoW algorithm extremely complex though.

you can mmap, but you need 256 GB of memory sticks installed, right?

or it will be 0.1 h/s hashrate :D

👀 Foundations of Transaction Fee Mechanism Design, by Hao Chung & Elaine Shi arxiv.org/pdf/2111.03151.pdf

Damn, they scooped me

See, here's a 50-page CompSci paper!

"3) miner-user side contract proofness (SCP), i.e., no coalition of the miner and one or more user(s) can increase

their joint utility by deviating from the honest behavior. "

^ Coalitions are always tough to grapple with.

I think a lot of the time people like to conceptualize a single attacker against a homogeneous and coordinated pool of "honest" miners

"We prove a new impossibility result: assuming finite block size, no single-parameter, non-trivial, possibly randomized TFM can simultaneously satisfy UIC and 1-SCP."

Well then, infinite block size it is

Done, infinite block size is the way to go. I always knew....

And once we have infinite block size, then there's no reason to stick with a finite number of ring members

And statistical power of the tests asymptotically approaches zero as ring size goes to infinity, right?

Dang, I dunno why we didn't spot this sooner. Easy fix, patch into the next hard fork?

In all seriousness, the result may be different if there is an adjustable block size, and txs are not filling blocks routinely. Don't need quite infinite block sizes, maybe. Just block sizes that aren't a practical constraint.

oh, ok

yea maybe that

I have a preliminary result for PR#8047:

0.8772995% of Monero transactions since the beginning of time have at least one such "collision"

I think. It's preliminary.

Well, nothing to worry about then?

I think we care about all of Monero's children.

1% seems a bit higher than I would like. My guess is that it may be prevalent when large consolidations occur, like pool mining.

Special thanks to neptune for setting me up with a SQL-to-R pipe

isthmus: It's not clear to me, or maybe anyone else, how important this impossibility result is in practice, anyway.

> <@rucknium:monero.social> I have a preliminary result for PR#8047:

> 0.8772995% of Monero transactions since the beginning of time have at least one such "collision"

In the last few months this figure has been around 0.4%

Are these transactions mostly many-input?

I think so. I am writing out some code to disaggregate the results now.

perf discussion: monero-project/research-lab #91

sech1: For txs with 2 or fewer inputs, collisions have occurred in about 0.1% of such txs since the genesis block

More recently, it has occurred in about 0.05% of such txs

Well, I suppose it cannot occur when there is just one input, so keep that in mind with these stats.

Ok, when the number of inputs is exactly 2, then collisions occur in 0.2255876% of all such tx since the genesis block.

Actually, among txs that have a single input, a collision has occurred a total of 4 (four) times in the entire history of Monero. I'm not sure what that's about.

What about collisions within the same ring, irrespective the number of inputs?

sech1: I am told that such collisions are prohibited. jberman , can you confirm?

prohibited at consensus since hf v6: github.com/monero-project/monero/bl…ore/cryptonote_core.cpp#L1277-L1291

I don't think collisions across rings are a big deal either, even if there were a larger number of them. the issue is more significant when you have an entire ring equivalent to another ring

How could you have "an entire ring equivalent to another ring"?

well aside from key image

assume ring size of 2. user owns output ID's N and N+1. User spends both outputs in the same tx. the first ring spending output ID N selects output ID N+1 as a decoy. the second ring spending output ID N+1 selects output ID N as a decoy

both rings would have output ID N and N+1 as decoys

Yes, that could occur, but not reasonably with ring size 11+. It could be an issue with Aeon, though.

yep agreed

jberman: How about communicating your thoughts on the GitHub PR? I will post my empirical findings.

will do