15:04:08 <Rucknium> MRL meeting in this room in two hours.
17:01:52 <Rucknium> Meeting time! https://github.com/monero-project/meta/issues/910
17:02:00 <Rucknium> 1) Greetings
17:02:19 <rbrunner> Hello
17:02:21 <m-relay> <v​tnerd:monero.social> Hi
17:03:31 <m-relay> <j​effro256:monero.social> Howdy
17:04:10 <Rucknium> 2) Updates. What is everyone working on?
17:05:42 <m-relay> <j​effro256:monero.social> I put a PR out to modify decoy selection https://github.com/monero-project/monero/pull/9023
17:06:14 <Rucknium> me: Reported nonstandard fee privacy issue to Exodus. They fixed it in the Desktop wallet. Mobile fix still being worked on: https://www.reddit.com/r/Monero/comments/176e1zr/privacy_advisory_exodus_desktop_users_update_to/ . Reviewing jeffro256's guide to wallet2's decoy selection algorithm and converting it to math formulas.
17:07:53 <m-relay> <j​effro256:monero.social> How did you initially find out that it was Exodus with the nonstandard fees?
17:08:09 <m-relay> <j​effro256:monero.social> B/c they're close source, right?
17:09:02 <m-relay> <j​effro256:monero.social> Was it wrong enough that you could just see it just by eyeballing it?
17:09:36 <Rucknium> I suspected it was exodus since they released their first working Monero version after the August 2022 hard fork at about the same date that the txs with the specific fee values started to appear.
17:09:59 <Rucknium> Then I sent some transactions with the wallet.
17:11:06 <Rucknium> I think they just had the wrong tx size. The UI showed tx size about 12 Kb for 1in/2out. If you used that incorrect size to calculate fees, then it would have used 20 nanoneros per byte, which is the standard minimum fee.
17:11:37 <m-relay> <j​effro256:monero.social> Oh okay nice
17:11:56 <m-relay> <v​tnerd:monero.social> Me: mostly subaddressses, but also answering questions for someone doing a 10k account stress test on LWS.
17:12:29 <m-relay> <v​tnerd:monero.social> LWS will be enterprise ready in the not distant future it looks like
17:13:07 <m-relay> <j​effro256:monero.social> That's awesome to hear !
17:13:20 <m-relay> <j​effro256:monero.social> So the stress test went well?
17:15:52 <m-relay> <j​effro256:monero.social> also btw @vtnerd did you have questions about https://github.com/monero-project/monero/pull/9023? I saw you commented on it the other day. Also, I have to apologize for sidelining my review of the serialization read interface; it's next on my list
17:17:05 <m-relay> <v​tnerd:monero.social> No, it failed lol. But they didn't know if was the frontend or backend yet. But we'll find out over the next month or so, and have it fixed
17:17:57 <m-relay> <v​tnerd:monero.social> Worse case it's in some LWS<->monerod interaction
17:20:51 <Rucknium> 3) Discussion. What do we want to discuss?
17:22:19 <m-relay> <o​frnxmr:monero.social> ```
17:22:19 <m-relay> <o​frnxmr:monero.social> any follow up questions/issues for CypherStack regarding the new scope for the bp++ peer review? : https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/413/diffs
17:22:20 <m-relay> <o​frnxmr:monero.social> ```
17:22:20 <m-relay> <o​frnxmr:monero.social> from plowsof
17:24:15 <rbrunner> Do I get it that this is waiting for word from Core?
17:24:27 <m-relay> <o​frnxmr:monero.social> From mrl
17:25:04 <rbrunner> Ah, you mean about the modified scope
17:25:16 <m-relay> <o​frnxmr:monero.social> Yes sir
17:25:20 <rbrunner> Not about the financing
17:25:45 <m-relay> <o​frnxmr:monero.social> Right
17:26:09 <rbrunner> In this case I am on the same side as you: No clue, not being a cryptographer ...
17:26:54 <Rucknium> As a non-cryptographer, the scope changes sound fine to me, except I don't know how important "Optimized binary range proofs" is. Is that a major part of what BP++ uses to get space and verification time savings?
17:27:24 <plowsof> ive also shared feedback from zksecurity with koe/jberman - exploratory work on seraphis papers. $10k/week for 2 months (80k) - "deliverables" hard to define but they are open to discussion / setting up a scope of work 
17:29:55 <Rucknium> Doing a quick search in the paper: "However, while this motivating example provides an intuition for why a norm relation can be preferable over an inner product relation, it turns out that in practice, it is almost always more efficient to use a BP++ reciprocal range proof instead of a BP++ binary range proof."
17:30:17 <Rucknium> So would Monero use a BP++ reciprocal range proof?
17:32:24 <Rucknium> "For most ranges, the reciprocal range proof is substantially more efficient for the prover and the verifier than a binary range proof. However for some small ranges with B − A < 28, a binary range proof can be more efficient."
17:33:06 <Rucknium> "28" should be 2^8
17:36:23 <Rucknium> kayabaNerve, would Monero use a binary range proof or a reciprocal range proof? Is it OK that the security proof of the binary range proof for BP++ won't be reviewed by CypherStack?
17:39:51 <Rucknium> I plotted the number of transactions that fit the Exodus Desktop fee pattern for the last 8 weeks: https://github.com/Rucknium/misc-research/blob/main/Monero-Nonstandard-Fees/images/Exodus-txs-after-fix-release.png
17:41:04 <Rucknium> The fixed Exodus Desktop wallet version was released on October 10. A week later, txs with the Exodus fee have been cut by about 50%. From 600 per day to 300 per day.
17:42:27 <rbrunner> Probably getting better of time. Funny how the number of transactions vary predictably over the week. Monday is especially busy, it seems :)
17:42:30 <rbrunner> *over time
17:42:40 <Rucknium> 1. This is pretty conclusive evidence that it was Exodus Desktop wallets creating those transactions. 2. This is the first statistical analysis on the amount of time it takes for users to update their Monero wallets. Obviously, users of other wallets would update at a different pace.
17:43:30 <m-relay> <j​effro256:monero.social> Does the exodus desktop app auto-update ?
17:43:44 <Rucknium> The lower tx volume for Saturday-Sunday in the Exodus plot is similar to the tx volume for the whole blockchain.
17:44:17 <Rucknium> I think the update behavior depends on OS. Different for Windows/Mac/Linux
17:45:12 <Rucknium> Exodus releases a new version every two weeks on a schedule.
17:47:59 <Rucknium> If wallet2 is updated, there are two steps: 1) Wallet developers who use wallet2 update to the new wallet2 code. 2) Users update their wallets.
17:48:22 <Rucknium> Users who use the GUI or CLI wallet would update "directly" to wallet2
17:48:49 <Rucknium> Anything else to discuss?
17:51:03 <m-relay> <j​effro256:monero.social> That CCS is to review the paper only right?
17:51:14 <m-relay> <j​effro256:monero.social> (This is my first time looking at the CCS)
17:52:26 <Rucknium> Yes. It is to review the paper's mathematics.
17:52:36 <m-relay> <j​effro256:monero.social> vtnerd, you've already done play implementations of bp++ yeah?
17:53:07 <m-relay> <j​effro256:monero.social> vtnerd, you've already done PoC implementations of bp++ yeah?
17:54:21 <m-relay> <j​effro256:monero.social> I wonder if we should leave out batch verification from the scope ....
17:56:19 <m-relay> <v​tnerd:monero.social> no it was unfinished unfortunately, I didn't know how to do the last part. I was hoping the newer paper would clarify some things. Or I could just do a port from the secp code
17:56:21 <Rucknium> The CCS proposal is supposed to review what exists in the paper, not create new mathematics. Doing batch verification would require new mathematics I think.
17:57:38 <m-relay> <j​effro256:monero.social> > To improve verifier performance, the BP
17:57:38 <m-relay> <j​effro256:monero.social> paper suggests a few optimizations, such as using a single multi-exponentiation, batch verification, and an
17:57:39 <m-relay> <j​effro256:monero.social> efficient method to compute scalars. The first two optimizations can be directly translated to BP++, but
17:57:39 <m-relay> <j​effro256:monero.social> the method to compute scalars has to be slightly adapted from BP’s inner product argument to BP++’s
17:57:40 <m-relay> <j​effro256:monero.social> norm linear argument. All three optimizations have been implemented in the benchmarked code.
17:58:02 <m-relay> <j​effro256:monero.social> It seems that there is an analagous, already-implemented way to do batch verification in bp++
17:58:28 <m-relay> <j​effro256:monero.social> Even if not explicitly mentioned how in the paper
17:58:39 <m-relay> <j​effro256:monero.social> Does Cypherstack do code reviews as well or just maths?
17:59:14 <Rucknium> They have done code reviews before.
17:59:53 <Rucknium> Maybe the question is "does BP++ batch verification have a security proof?"
18:00:25 <Rucknium> Does the original BP paper have a security proof for batch verification?
18:00:45 <m-relay> <v​tnerd:monero.social> I dont recall any, but I wasn't looking for it either
18:01:24 <m-relay> <j​effro256:monero.social> is the newer paper the one that is linked here ? https://eprint.iacr.org/archive/2022/510/20230717:163509
18:01:37 <m-relay> <j​effro256:monero.social> Or is that the older one ?
18:01:59 <m-relay> <j​effro256:monero.social> There's been one revision on this entry
18:03:08 <Rucknium> That's the latest version on the IACR website: https://eprint.iacr.org/archive/versions/2022/510
18:04:39 <Rucknium> We will end the meeting here. Discussions on the BP++ review CCS can continue.
18:07:27 <m-relay> <j​effro256:monero.social> Looking thru the BP paper, there's no security proof per se, but a rather simple algebraic argument
18:09:25 <m-relay> <j​effro256:monero.social> If that really can be extended as easily to BP++, then it may not put much burden on the reviewers as compared to verifiying everything else
18:11:43 <m-relay> <j​effro256:monero.social> To be more precise, someone could formally write down the analogous argument for why batch verification is the same algebraically, with "high probability", as verifying each individually, and then we could increase the scope from the paper to the paper plus the batch verification argument
18:13:25 <m-relay> <j​effro256:monero.social> I wish the original authors of the paper had expanded upon that in the paper, or else cited the previous work in that case, but I can't be too picky
19:08:40 <m-relay> <k​ayabanerve:matrix.org> Rucknium @rucknium:monero.social: the reciprocal range proof, I believe, letting us skip the binary range proof proof so long as it isn't the basis of the reciprocal proof's proof.
19:10:46 <m-relay> <k​ayabanerve:matrix.org> Batch verification is trivial.
19:10:46 <m-relay> <k​ayabanerve:matrix.org> For any protocol which defines it's verification as group element G1 == G2, redefinition to G1 - G2 == 0 is possible.
19:10:46 <m-relay> <k​ayabanerve:matrix.org> Batch verification is just, for a list of G1 and G2s, selecting random scalars to weight the G1s and G2s so they can't mingle.
19:11:42 <m-relay> <k​ayabanerve:matrix.org> The performance benefit is that you don't have G1/G2. You have terms summing to them. Multi-scalar multiplications produce summed results far faster than individual components can be calculated.
19:22:14 <Rucknium> That sounds like "The revised BP++ review scope is OK"