04:09:59 <koe000[m]> I spent some time in Excel with my perf test data. This is probably the most important high-level-view plot.
04:10:09 * koe000[m] uploaded an image: (58KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/gRhiSqnWiGEXhaPhrgKVcYkc/mock_tx_perf_z2a_2_refset_vercost.png >
04:11:49 <koe000[m]> Basically, my take-away is we will probably have to accept 64-member rings. Note that BOTH axes are log-2.
04:13:59 <koe000[m]> Since I know people will ask... here is tx size.
04:14:09 * koe000[m] uploaded an image: (58KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/HCnkPGxKovvXLEeGkVtevhtL/mock_tx_perf_z2a_2_refset_txsize.png >
04:14:27 <koe000[m]> These are 2-in/2-out transactions.
04:16:00 <Rucknium[m]> koe000: What is the significance of decomp.n and decomp.m? They have a big effect on verification times
04:16:12 <Rucknium[m]> From what I see in the data
04:16:30 <UkoeHB> It is how reference sets are handled by grootle proofs. n^m = ref set size
04:17:09 <UkoeHB> I found that 3-series was slightly better than 2-series, and >3 was either equal to or worse than 2.
04:17:47 <UkoeHB> For transaction size*, verification costs were independent of decomposition base.
04:19:21 <gingeropolous[m]> wow, so sizewise a 128 ringmember seraphis is the same size as a 32 ringmember triptych. 
04:19:24 <koe000[m]> Rucknium
04:19:34 * koe000[m] uploaded an image: (104KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/OFktSssPkeCaoYhtwUbzinQC/mock_tx_perf_z2a_2_decomp.png >
04:20:58 <gingeropolous[m]> and squashed a 128 is about 16 msec?
04:21:14 <koe000[m]> I like this combined view better.
04:21:26 * koe000[m] uploaded an image: (106KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/HZbdBgaGLXdQpSUNYAtxBrIM/mock_tx_perf_z2a_2_refset.png >
04:22:27 <UkoeHB> gingeropolous[m]: more like 18msec
04:22:38 <UkoeHB> 17.6*
04:23:19 <gingeropolous[m]> and a current clsag ringsize 11 is like 9msec?
04:23:24 <UkoeHB> gingeropolous[m]: I really like how clean this data is :) thanks to your nice machine
04:23:46 <gingeropolous[m]> glad it worked out!
04:24:01 <UkoeHB> yeah about 9msec in this poc
04:24:20 <gingeropolous[m]> though, should we get #s on different processors etc?
04:25:02 <UkoeHB> right, but they should still be 'relatively' the same (proportionally)
04:25:43 <gingeropolous[m]> yeah
04:27:39 * Rucknium[m] uploaded an image: (75KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/ngrKwtieAUZswiKsRawaFIot/verif-times-by-decomp.png >
04:27:48 <UkoeHB> With batching, squashed can shave off another ~2ms I think.
04:28:05 <Rucknium[m]> I'm not sure how useful that ^ is.
04:29:16 <Rucknium[m]> <UkoeHB> "For transaction size*, verificat..." <- What do you mean by this?
04:30:07 <UkoeHB> Check my 'decomp' image. The verification lines all match, while tx sizes don't line up.
04:34:33 <Rucknium[m]> 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.
04:37:05 <UkoeHB> 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.
04:38:27 <Rucknium[m]> So, no "interaction effect" between ref set size and decomp.n
04:38:59 <UkoeHB> I guess?
04:42:26 <Rucknium[m]> verif.time = beta_1 * ref.set.size + beta_2 * decomp.n + beta_3 * ref.set.size*decomp.n + error
04:42:37 <Rucknium[m]> Then beta_3 = 0
04:42:53 <Rucknium[m]> There is no combined effect, I think we are trying to say
04:44:08 <Rucknium[m]> 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.
13:28:44 <sethsimmons> <koe000[m]> "mock_tx_perf_z2a_2_refset.png" <- koe000: mind if I share this on Twitter, or too early for that?
13:30:03 <sethsimmons> Also, thank you all for producing such clean charts/data this early on! Extremely useful for the non-statisticians among us 🙂
13:54:23 <UkoeHB> sethsimmons: it is a bit early, I want to clean up the charts a bit
13:54:59 <sethsimmons> UkoeHB: Definitely understand, will put it in the backlog 🙂
13:55:09 <sethsimmons> Thanks for all your work on Seraphis! Looking very exciting.
15:57:45 <boogerlad[m]> UkoeHB: does seraphis reduce or increase the number of communication rounds necessary for multisig compared to monero today?
15:58:11 <boogerlad[m]> I know triptych increased the number
15:59:45 <UkoeHB> boogerlad[m]: it is the same as currently
16:27:29 <yanmaani> What's the goal here? To determine best algorithm in terms of performance etc?
16:30:28 <UkoeHB> Yes, and the best design choices for each algorithm.
16:32:39 <UkoeHB> 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.
16:34:01 <Rucknium[m]> 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.
16:34:56 <UkoeHB> Rucknium[m]: I think what I have right now will work.
16:35:16 <UkoeHB> Today I will write an MRL github issue discussing the results.
16:35:47 <Rucknium[m]> Ok sounds good
17:32:18 <yanmaani> valuable to do regression, try to determine a model?
17:32:28 <yanmaani> seems like the bulk of the work is in determining trade-offs
17:34:23 <UkoeHB> Eh idk if a model would be super useful when the final decision is based on heuristics and eye-balling it.
17:35:58 <gingeropolous> and id hope there might be more optimizations eventually
17:43:50 <boogerlad[m]> is verification a single threaded task?
17:47:03 <UkoeHB> Afaik you can verify multi-threaded, so long as key-image checks are atomic.
17:48:47 <dEBRUYNE> UkoeHB: I think choosing a ring size that approximately equals the current verification time is the best option
17:49:52 <gingeropolous> thats gonna be like 16
17:50:52 <gingeropolous> and a 16 seraphis is larger than a 16 clsag :(
17:53:48 <carrington[m]> If light wallet servers become more of a thing, a bump in verification time isn't the worst thing in the world
17:55:10 <gingeropolous> 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
17:55:25 <gingeropolous> so that'll get us a ringsize 64 seraphis
17:55:29 <gingeropolous> ~~
17:56:52 <UkoeHB> It might be possible to justify 128 using the squashed variant, which benefits a lot from batching. Needs careful thought.
17:57:12 <Rucknium[m]> 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.
17:57:58 <gingeropolous> yeah, that plus output tagging is gonna drastically change the UX on the wallet side
17:58:08 <carrington[m]> 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+
17:59:09 <Rucknium[m]> 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).
18:01:54 <gingeropolous> 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
18:02:09 <gingeropolous> :)
18:55:53 <yanmaani> Question about RandomX: Could you run it with a scratch space size of like 200gb and get a storage-hard algorithm instead?
18:58:44 <UkoeHB> sech1 hyc ^
19:01:19 <yanmaani> or like RAM-hard
19:06:40 <sech1> RANDOMX_DATASET_BASE_SIZE is limited to 4 GB, but technically you could increase RANDOMX_DATASET_EXTRA_SIZE to ridiculous values
19:07:16 <sech1> But as it is now, it will require 200 GB of actual RAM, not SSD
19:09:23 <hyc> you could mmap the SSD space but it would be incredibly destructive
19:09:47 <yanmaani> hyc: But it would have less power use, right?
19:10:01 <hyc> and chia already has that problem, not sure it's worth retreading the same path
19:10:06 <yanmaani> sech1: how so? Couldn't I just mmap 200 GB worth of space?
19:10:17 <yanmaani> Chia has additional stuff that makes their PoW algorithm extremely complex though.
19:12:22 <sech1> you can mmap, but you need 256 GB of memory sticks installed, right?
19:12:33 <sech1> or it will be 0.1 h/s hashrate :D
19:20:59 <isthmus> 👀 Foundations of Transaction Fee Mechanism Design, by Hao Chung & Elaine Shi https://arxiv.org/pdf/2111.03151.pdf
19:28:28 <Rucknium[m]> Damn, they scooped me
19:31:11 <Rucknium[m]> See, here's a 50-page CompSci paper!
19:32:16 <Rucknium[m]> "3) miner-user side contract proofness (SCP), i.e., no coalition of the miner and one or more user(s) can increase
19:32:16 <Rucknium[m]> their joint utility by deviating from the honest behavior. "
19:32:33 <Rucknium[m]> ^ Coalitions are always tough to grapple with.
19:34:59 <isthmus> I think a lot of the time people like to conceptualize a single attacker against a homogeneous and coordinated pool of "honest" miners
19:35:14 <Rucknium[m]> "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."
19:36:08 <isthmus> Well then, infinite block size it is
19:36:51 <Rucknium[m]> Done, infinite block size is the way to go. I always knew....
19:38:10 <isthmus> And once we have infinite block size, then there's no reason to stick with a finite number of ring members
19:38:23 <isthmus> And statistical power of the tests asymptotically approaches zero as ring size goes to infinity, right?
19:38:34 <isthmus> Dang, I dunno why we didn't spot this sooner. Easy fix, patch into the next hard fork?
19:44:50 <Rucknium[m]> 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.
19:49:24 * isthmus pauses halfway through deleting every IF/THEN block that seems to check block size or transaction size
19:49:27 <isthmus> oh, ok
19:49:31 <isthmus> yea maybe that
19:52:43 <Rucknium[m]> I have a preliminary result for PR#8047:
19:52:43 <Rucknium[m]> 0.8772995% of Monero transactions since the beginning of time have at least one such "collision"
19:52:45 <Rucknium[m]> I think. It's preliminary.
19:52:46 <carrington[m]> Well, nothing to worry about then?
19:52:50 <Rucknium[m]> I think we care about all of Monero's children.
19:52:56 <Rucknium[m]> 1% seems a bit higher than I would like. My guess is that it may be prevalent when large consolidations occur, like pool mining.
19:54:05 <Rucknium[m]> Special thanks to neptune  for setting me up with a SQL-to-R pipe
19:55:38 <Rucknium[m]> isthmus: It's not clear to me, or maybe anyone else, how important this impossibility result is in practice, anyway.
20:20:54 <Rucknium[m]> > <@rucknium:monero.social> I have a preliminary result for PR#8047:
20:20:54 <Rucknium[m]> > 0.8772995% of Monero transactions since the beginning of time have at least one such "collision"
20:20:54 <Rucknium[m]> In the last few months this figure has been around 0.4%
20:34:39 <sech1> Are these transactions mostly many-input?
20:35:46 <Rucknium[m]> I think so. I am writing out some code to disaggregate the results now.
20:36:55 <UkoeHB> perf discussion: https://github.com/monero-project/research-lab/issues/91
21:20:11 <Rucknium[m]> sech1: For txs with 2 or fewer inputs, collisions have occurred in about 0.1% of such txs since the genesis block
21:20:44 <Rucknium[m]> More recently, it has occurred in about 0.05% of such txs
21:22:50 <Rucknium[m]> Well, I suppose it cannot occur when there is just one input, so keep that in mind with these stats.
21:24:57 <Rucknium[m]> Ok, when the number of inputs is exactly 2, then collisions occur in 0.2255876% of all such tx since the genesis block.
21:28:38 <Rucknium[m]> 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.
21:41:49 <sech1> What about collisions within the same ring, irrespective the number of inputs?
21:45:36 <Rucknium[m]> sech1: I am told that such collisions are prohibited. jberman , can you confirm?
21:57:01 <jberman[m]> prohibited at consensus since hf v6: https://github.com/monero-project/monero/blob/298c9a357f6e57eccf28db1f3e734eb6da080d9a/src/cryptonote_core/cryptonote_core.cpp#L1277-L1291
21:59:07 <jberman[m]> 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
21:59:40 <Rucknium[m]> How could you have "an entire ring equivalent to another ring"?
21:59:58 <jberman[m]> well aside from key image
22:02:10 <jberman[m]> 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
22:03:20 <jberman[m]> both rings would have output ID N and N+1 as decoys
22:11:47 <Rucknium[m]> Yes, that could occur, but not reasonably with ring size 11+. It could be an issue with Aeon, though.
22:11:54 <jberman[m]> yep agreed
22:12:00 <Rucknium[m]> jberman: How about communicating your thoughts on the GitHub PR? I will post my empirical findings.
22:12:08 <jberman[m]> will do