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

this in advance

From reading the paper verification efficiency starts to fall above 16 so for C

CLSAG 17 mixin si maybe as high as we should go

is

/buffer 11

ArticMine: a 2-in-2-out 11-MLSAG transaction is about 2544 bytes currently

With 11-CLSAG, it becomes 1904 bytes

With 13-CLSAG, it becomes 2032 bytes

With 17-CLSAG, it becomes 2288 bytes

(does not account for varint representations of ring member offsets)

~2 bytes per index. So 2*2*(17-11).

moneromooo: cslashm tells me that the ledger code PR to my `clsag-device` branch (SarangNoether/monero #1) is ready to go, but untested without testnet

As long as testnet is on v13, it should be the same as mainnet will be.

Unclear how much local testing they were able to do

Hooray, one preprint submitted to PoPETs

another one is making TeX very angry :/

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

I assume by "mixing" you mean "total fixed ring size"

s/mixing/mixin

Yes currently at 11

and there has been discussion of an increase to 13 and or 17

Keep in mind that my estimates suggest that 13-CLSAG and 11-MLSAG would have approximately the same verification time

With an increase in verification time for 17

Yes

N-CLSAG for N > 13 will exceed verification time for 11-MLSAG

These are approximations; I'd need to check again after some optimizations that have been made to both verification routines

but they should still be reasonably accurate

Comparing 17-CLSAG with 11-MLSAG for verification time would be useful to see if the increase in verification tie is worth it

time

I'm building some new tests to check this

Thanks

The new verification tests do a better job of consistently handling commitment offsets, so the numbers should be better and more up-to-date

ArticMine: paste.debian.net/hidden/2927ed9d

Thanks. So a 29.3% increase in verification time for the median. From 12.444 ms to 16.091 ms

yep

vs a 17.2% decrease if we just stay at a mixin of 11 (10.302 ms)

I take this is without any batching

Still from a scaling perspective this is significant

MLSAG and CLSAG signature verification does not benefit from batching

Batching will apply only to bulletproofs, which are not included in these numbers

Still even when we add the bulletproofs another 10.86 ms it is still significant

And on a larger scale, the average verification per transaction approaches the sum of a single signature verification and the non-marginal bulletproof verification

So for example for a batch of say 1000 2in 2out transactions at CLSAG-11 what are we looking at in verification time?

At that point it's essentially just a small few ms extra per tx

and that number is constant between MLSAG and CLSAG anyway

nothing about range proofs changes

FWIW batching is done per-block currently

and overall verification is not changed very much by expanding that, in my tests

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

Perhaps it would be prudent to keep verification time low until we can upgrade to Triptych

This is very much my thought. Keep the mixin at 11 and pass all the benefits CLSAG in verification time and size along

I don't see a particularly compelling reason for a marginal increase with CLSAG

A marginal increase in ring size that is?

Yeah

I was considering 13 or 17; however the figures for verification time make a compelling case against an increase

sarang: Do you have a table somewhere that compares the current verification time against that of the sublinear ring sig schemes?

I remember one that compared the different schemes, but not sure if it included the *current* scheme

I have code that will run that data

Yeah I'd be interested too

I didn't include the current constructions in the Triptych-2 plot since it wasn't useful

(the goal there was to compare against other state-of-the-art approaches)

it also runs the data that will produce the Triptych-2 plots

Script to get size/time estimates: github.com/SarangNoether/skunkworks/blob/sublinear/estimate.py

Data (v8 onwards) used: github.com/noncesense-research-lab/…ero_transaction_io/tree/master/data

It's pretty slow

but it gets the job done

(data courtesy of n3ptune and friends)

This accounts for the overall chain distribution, so I think it provides a better estimate of the full effects of different constructions

sarang: Thanks, will have a look tomorrow

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

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

Who sent it = the one time key, not the wallet address

Wallet addresses are never on chain

Also, amounts are represented by commitments and are not in the clear

<Leo Cornelius [AIO]#9160>: So... no?

If "who" means "wallet addresses", then the answer to both questions is no

However, you could try to build heuristics based on spend patterns and external information

But you could not do a simple "look for this address and tally the amounts" like in transparent assets

you could trace from coinbase outputs and always know the total sum in closed sets

Yup

and if you know some of those explicitly, then you can know a reduced sum for the remainder

Yup