02:22:37 <ArticMine> sarang Do you have tx sizes for 2 in 2 out for CLSAG mixin 11 and also increasing the mixin to 13, and 17. I am looking at reducing the reference tx size from 3000 bytes to 2500 bytes Thanks for
02:23:00 <ArticMine> this in advance
02:27:07 <ArticMine> From reading the paper verification efficiency starts to fall above 16 so for C
02:28:40 <ArticMine> CLSAG 17 mixin si maybe as high as we should go
02:29:43 <ArticMine> is
04:05:07 <grubles> /buffer 11
14:00:09 <sarang> ArticMine: a 2-in-2-out 11-MLSAG transaction is about 2544 bytes currently
14:00:17 <sarang> With 11-CLSAG, it becomes 1904 bytes
14:00:23 <sarang> With 13-CLSAG, it becomes 2032 bytes
14:00:29 <sarang> With 17-CLSAG, it becomes 2288 bytes
14:00:53 <sarang> (does not account for varint representations of ring member offsets)
14:02:57 <moneromooo> ~2 bytes per index. So 2*2*(17-11).
14:04:18 <sarang> moneromooo: cslashm tells me that the ledger code PR to my `clsag-device` branch (https://github.com/SarangNoether/monero/pull/1) is ready to go, but untested without testnet
14:05:13 <moneromooo> As long as testnet is on v13, it should be the same as mainnet will be.
14:07:01 <sarang> Unclear how much local testing they were able to do
17:42:16 <sarang> Hooray, one preprint submitted to PoPETs
17:42:30 <sarang> another one is making TeX very angry :/
18:16:58 <ArticMine> Thanks sarang moneroooo From the figures 2500 bytes for the reference tx is appropriate if we plan a phased increase of the mixin to 17. On the other hand if the consensus is no increase in mixin from the current 11 then 2100 bytes is appropriate
18:19:26 <sarang> I assume by "mixing" you mean "total fixed ring size"
18:19:30 <sarang> s/mixing/mixin
18:19:30 <monerobux> sarang meant to say: I assume by "mixin" you mean "total fixed ring size"
18:23:04 <ArticMine> Yes currently at 11
18:24:13 <ArticMine> and there has been discussion of an increase to 13 and  or 17
18:24:57 <sarang> Keep in mind that my estimates suggest that 13-CLSAG and 11-MLSAG would have approximately the same verification time
18:26:02 <ArticMine> With an increase in verification time for 17
18:26:42 <sarang> Yes
18:26:54 <sarang> N-CLSAG for N > 13 will exceed verification time for 11-MLSAG
18:27:15 <sarang> These are approximations; I'd need to check again after some optimizations that have been made to both verification routines
18:27:22 <sarang> but they should still be reasonably accurate
18:58:03 <ArticMine> Comparing 17-CLSAG with 11-MLSAG for verification time would be useful to see if the increase in verification tie is worth it
18:58:47 <ArticMine> time
18:59:36 <sarang> I'm building some new tests to check this
19:07:49 <ArticMine> Thanks
19:09:38 <sarang> The new verification tests do a better job of consistently handling commitment offsets, so the numbers should be better and more up-to-date
19:29:55 <sarang> ArticMine: https://paste.debian.net/hidden/2927ed9d/
19:46:28 <ArticMine> Thanks. So a 29.3% increase in verification time for the median. From 12.444 ms to 16.091 ms
19:49:13 <sarang> yep
19:52:09 <ArticMine> vs a 17.2% decrease if we just stay at a mixin of 11 (10.302 ms)
19:53:53 <ArticMine> I take this is without any batching
19:55:21 <ArticMine> Still from a scaling perspective this is significant
19:56:17 <sarang> MLSAG and CLSAG signature verification does not benefit from batching
19:56:36 <sarang> Batching will apply only to bulletproofs, which are not included in these numbers
20:04:55 <ArticMine> Still even when we add the bulletproofs another 10.86 ms it is still significant
20:15:21 <sarang> And on a larger scale, the average verification per transaction approaches the sum of a single signature verification and the non-marginal bulletproof verification
20:21:36 <ArticMine> So for example for a batch of say 1000 2in 2out transactions at CLSAG-11 what are we looking at in verification time?
20:22:56 <sarang> At that point it's essentially just a small few ms extra per tx
20:23:06 <sarang> and that number is constant between MLSAG and CLSAG anyway
20:23:13 <sarang> nothing about range proofs changes
20:23:29 <sarang> FWIW batching is done per-block currently
20:23:50 <sarang> and overall verification is not changed very much by expanding that, in my tests
20:32:25 <ArticMine> The way I see this per block is the critical parameter. Quantifying the incremental verification per tx is very useful to get a handle on the potential limits of the network
20:46:38 <dEBRUYNE> Perhaps it would be prudent to keep verification time low until we can upgrade to Triptych
20:48:50 <ArticMine> This is very much my thought. Keep the mixin at 11 and pass all the benefits CLSAG in verification time and size along
20:48:53 <sarang> I don't see a particularly compelling reason for a marginal increase with CLSAG
20:51:01 <dEBRUYNE> A marginal increase in ring size that is?
20:52:14 <sarang> Yeah
20:52:59 <ArticMine> I was considering 13 or 17; however the figures for verification time make a compelling case against an increase
20:56:29 <dEBRUYNE> sarang: Do you have a table somewhere that compares the current verification time against that of the sublinear ring sig schemes?
20:56:47 <dEBRUYNE> I remember one that compared the different schemes, but not sure if it included the *current* scheme
20:57:45 <sarang> I have code that will run that data
20:57:52 <UkoeHB_> Yeah I'd be interested too
20:58:03 <sarang> I didn't include the current constructions in the Triptych-2 plot since it wasn't useful
20:58:11 <sarang> (the goal there was to compare against other state-of-the-art approaches)
20:58:34 <sarang> it also runs the data that will produce the Triptych-2 plots
21:01:13 <sarang> Script to get size/time estimates: https://github.com/SarangNoether/skunkworks/blob/sublinear/estimate.py
21:01:28 <sarang> Data (v8 onwards) used: https://github.com/noncesense-research-lab/monero_transaction_io/tree/master/data
21:01:38 <sarang> It's pretty slow
21:01:44 <sarang> but it gets the job done
21:02:01 <sarang> (data courtesy of n3ptune and friends)
21:02:45 <sarang> This accounts for the overall chain distribution, so I think it provides a better estimate of the full effects of different constructions
21:03:21 * sarang afk
21:07:07 <dEBRUYNE> sarang: Thanks, will have a look tomorrow
21:32:56 <derpy_bridge> <Leo Cornelius [AIO]#9160>: If I send a txn eith mixin 0 on a fork that allows 0 mixin txns would the explorer show who sent it?
21:33:19 <derpy_bridge> <Leo Cornelius [AIO]#9160>: What if a fork set the max mixin to 0? Would it be like bitcoins explorer where you can see a rich list?
21:48:58 <sarang> Who sent it = the one time key, not the wallet address
21:49:11 <sarang> Wallet addresses are never on chain
21:51:00 <sarang> Also, amounts are represented by commitments and are not in the clear
22:13:51 <derpy_bridge> <Leo Cornelius [AIO]#9160>: So... no?
22:22:53 <sarang> If "who" means "wallet addresses", then the answer to both questions is no
22:23:10 <sarang> However, you could try to build heuristics based on spend patterns and external information
22:24:18 <sarang> But you could not do a simple "look for this address and tally the amounts" like in transparent assets
22:36:27 <UkoeHB_> you could trace from coinbase outputs and always know the total sum in closed sets
22:36:58 <sarang> Yup
22:36:58 <UkoeHB_> and if you know some of those explicitly, then you can know a reduced sum for the remainder
22:37:04 <sarang> Yup