Monero Research Lab Meeting - Wed 12 June 2024, 17:00 UTC

Logs

< rucknium:monero.social > Meeting time! https://github.com/monero-project/meta/issues/1022

< rucknium:monero.social > 1) Greetings

< xmrack:monero.social > Hi

< articmine:monero.social > Hi

< chaser:monero.social > hello

< vtnerd:monero.social > Hi

< spackle > hello

< rbrunner > Hello

< jeffro256:monero.social > Howdy

< rucknium:monero.social > 2) Updates. What is everyone working on?

< jberman:monero.social > Continuing fcmp tree work, continuing the trim algorithm

< syntheticbird:monero.social > Hi

< xmrack:monero.social > Starting work on stressnet

< syntheticbird:monero.social > I've been working on a proposal for traffic pattern obfuscation and mitigation against automated firewall active probing. Tho I have received concern over the complexity of such mitigation than I'm trying to address

< vtnerd:monero.social > Me: still stress testing the LWS remote scan feature, and found some bugs in the process

< articmine:monero.social > Continuing work on scaling after my presentation at MoneroKon

< rucknium:monero.social > me: Helping set up the stressnet. Started on a simple Shiny app for visualizing the fee/ring size tradeoff for black marble defense, suggested by xmrack . I made by MoneroKon presentation "Hard Data on Banking the Unbanked", but I submitted it way too late, so it will be a presentation for Monerotopia in November 😅

< spackle > misc. stressnet tasks

< rucknium:monero.social > xmrack: Do we have Emanuele here?

< rucknium:monero.social > Thanks for contacting them

< xmrack:monero.social > Im not sure. I could ping him over email

< rucknium:monero.social > I didn't see any new people joining the Matrix room. If he shows up later in the meeting, we can have the agenda item then

< rucknium:monero.social > 3) Stress testing monerod https://github.com/monero-project/monero/issues/9348

< spackle > The stressnet release is published: https://github.com/spackle-xmr/monero/releases/tag/v250.18.3.3.1

< spackle > Everything is running smoothly with 9 nodes at the last count, and flooding wallets are prepared. Public announcement is set for tomorrow; stressing begins 15:00 UTC June 19th. In short, the stage has been set.

< xmrack:monero.social > Rucknium: did you want to share the Shiny app or are you working on it more?

< rucknium:monero.social > We have a stressnet block explorer running: http://explorer.stressnet.net:8081

< rucknium:monero.social > xmrack: Not sure. I may share in the next agenda item

< rbrunner > Fantastic progress.

< syntheticbird:monero.social > Have the stressnet nodes already caused system crash or memory exhaustion yet on some host ?

< rucknium:monero.social > The SSL cert for https will be added soon. We have an onion hidden service too: http://xmrstrss5d6fii5mku5glfxp3g73unofae2yh4cndfxgvbexbifhguyd.onion/

< rucknium:monero.social > You can see in the block explorer that we are not stressing the network right now

< spackle > I have observed excessive memory use on a test machine, up to 71.7GB for one instance of monerod

< rucknium:monero.social > spackle had very high RAM usage on the node that was receiving the spam for the wallet, recently

< spackle > The machine had 128GB RAM available, so no OOM crash occurred.

< rucknium:monero.social > I mean spam from the wallet

< rucknium:monero.social > Anyone is welcome to join the stressnet. It may take more than 24 hours for initial sync. Here are instructions: https://github.com/spackle-xmr/monero/blob/master/README.md

< jeffro256:monero.social > Me: finishing first draft of Jamtis-RCT library

< rucknium:monero.social > Right now I am working on saving and displaying ephemeral data for the stressnet like txpool size, RAM and CPPU usage, peer connection data, etc.

< rucknium:monero.social > Thanks again to selsta and plowsof for helping with the release binaries workflow on GitHub.

< articmine:monero.social > When considering CPU usage is this per thread?

< rucknium:monero.social > I have just made code to save the CPU and MEM output of top for monerod

< rucknium:monero.social > Maybe there is a way to get more detail.

< rucknium:monero.social > AFAIK we will set log levels and categories for different nodes to capture some types of data, too. We don't know exactly what will be useful. 0xfffc will help decide that.

< articmine:monero.social > It is a good start. Thread count and CPU specs will be very helpful.

< syntheticbird:monero.social > Rucknium tho harder you'll likely find more and accurate informations in /proc/PID directory

< rucknium:monero.social > Thanks. I will try to get info from there.

< rucknium:monero.social > More comments or questions on stressnet?

< rucknium:monero.social > 4) Potential measures against a black marble attack. https://github.com/monero-project/research-lab/issues/119

< rucknium:monero.social > I have an extremely basic Shiny app that reproduces the table and plot from my paper: https://black-marble-defense-params.redteam.cash/

< articmine:monero.social > My one comment on this is that the next changes to scaling will likely include a reduction of the ML surge factor from 50 to 16. When combined with the full ratio of the current penalty free zone this effectively places hard and soft limits on black marble.

< rucknium:monero.social > The paper is https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-optimal-fee-ring-size.pdf

< rucknium:monero.social > You can change the parameters in the Shiny app. Then the server will recompute the plot and add the solution to the table.

< xmrack:monero.social > I need to leave but emanuele is having issues making a monero.social account. He’s actively trying to join

< jeffro256:monero.social > What kind of issues ?

< chaser:monero.social > this is very useful, thanks!

< jeffro256:monero.social > ArticMine: do you have a formal analysis of how decreasing the surge factor limits how much damage a short term attacker can do with black marble flooding? I know the general idea is that reducing the surge factor to something comparable to the ring size will make "drive by" black marbling less effective

< rucknium:monero.social > I am going to add the two other solution types I discussed last meeting and add explanatory text

< articmine:monero.social > I can do this

< jeffro256:monero.social > Nice! It would be nice to see actual numbers, especially for full decoy removal

< rucknium:monero.social > Maybe we can combine my analysis with the surge factor analysis

< articmine:monero.social > Yes

< rucknium:monero.social > I think we got emsczkp

< rucknium:monero.social > Ok we will finish discussion of this agenda item, then put emsczkp next

< syntheticbird:monero.social > be aware emsczkp is on matrix.org

< someoneelse495495:matrix.org > emsczkp Please follow meetings on monerologs.net. There are federation issues between monero.social and matrix.org. You'll likely be unable to see messages from the meeting in real time

< rucknium:monero.social > Ok. He will have to look at https://libera.monerologs.net/monero-research-lab/20240612

< emsczkp:matrix.org > Ok thanks, i will try

< jeffro256:monero.social > Welcome

< rucknium:monero.social > Dan Miller: Any progress figuring out what the federation issues with matrix.org are?

< someoneelse495495:matrix.org > Sorry this is a reccurent issue. Be sure participants do see your messages tho

< someoneelse495495:matrix.org > Sorry this is a reccurent issue. You can be sure participants do see your messages tho

< rucknium:monero.social > is kayabanerve / kayabanerve here?

< rucknium:monero.social > emsczkp: Welcome! Could you introduce yourself, explain your recent work, and your interest in improving the Monero protocol?

< emsczkp:matrix.org > so I write in this chat and view the replies here monerologs.net?

< someoneelse495495:matrix.org > Yes

< someoneelse495495:matrix.org > Don't forget to resfresh monerologs.net

< emsczkp:matrix.org > thanks you all, I will introduce my self and explain my research objectives

< emsczkp:matrix.org > I am PhD and I conducted reaserch in zero-knowledge proofs (ZKPs). In particular, I started with argument systems like Bulletproofs (BP). I experimented with BP in the public blockchain protocols, so i delved the BP as well as other trustless ZKP. From my experiments, i highlighted that BP's Inner-Product Argument (IPA) subroutine is expensive in computational terms. So i'm trying

< emsczkp:matrix.org > to reduce the computational costs of the IPA. To this end, I landed on the theory of Compressed Sigma-Protocols and tried to reconcile this theory with the IPA. My last conference shows improvements in proving and verifying costs as well as proved security in standard DLOG assumption. Now, i would like to extend this research direction in a Journal, also considering recent advan

< emsczkp:matrix.org > cement is the field with BP+ and BP++

< rucknium:monero.social > Wonderful

< articmine:monero.social > I have a question. How would this research impact the proposed FCMP in Monero.?

< articmine:monero.social > Full Chain Membership Proofs

< rucknium:monero.social > The abstract of https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=221 says that the proving and verification time reduces to 1/2 of the original time, with your reearch

< articmine:monero.social > I am very excited about reductions in transaction size and verification time

< emsczkp:matrix.org > thank you for the question, what is FCMP exactly ?

< kayabanerve:monero.social > full-chain membership proofs

< rucknium:monero.social > FCMP is an adaption of Curve Trees to Monero, AFAIK

< rucknium:monero.social > Basically using nested Bullletproofs to form the anonymity set of Monero instead of ring signatures

< rbrunner > They have something like BP somewhere inside, yes? GBP or how they are called.

< kayabanerve:monero.social > sorry, that was replying to emsczkp. My messages are out of order so I'm unsure that was in context

< emsczkp:matrix.org > The Inner-product argument is used in the Monero range proof/membership proof system, in the original BP version

< jeffro256:monero.social > In practice for FCMPs, we were planning on using another variant of bulletproofs called "Generalized Bulletproofs" : https://github.com/simonkamp/curve-trees/blob/main/bulletproofs/generalized-bulletproofs.md

< rucknium:monero.social > How much of the total BP verification time is spent on the IPA?

< emsczkp:matrix.org > by improving the inner-product argument, the overall system will benefit

< kayabanerve:monero.social > 1) jeffro256: Please link to Aaron's specification and proofs, it's more comprehensive.

< kayabanerve:monero.social > 2) We need an IPA which enables an arithmetic circuit proof which can open Pedersen Vector Commitments.

< kayabanerve:monero.social > If any new IPA is proposed, if it's pure multiplicative constraints and lincombs, or even also PCs, that's insufficient unless it's ~10x faster.

< kayabanerve:monero.social > I'd have to check the numbers exactly. The divisors work does get us close to efficient enough to consider a binary tree (optimal if without PVCs), yet then we'd add another few KB to the proof.

< kayabanerve:monero.social > I'm opening the PDF now, I just wanted to be clear on context. if this is a 1:1 with the BP IPA statement, offering the same AC proof construction over it, I'd be quite interested.

< emsczkp:matrix.org > I just saw the GBP which is based on R1CS, I had no knowledge of it. We could see if my approach is applicable in the folding argument.

< kayabanerve:monero.social > This seems equivalent to the BP+ IPA statement, which places the inner-product in the exponent. I'd assume we can apply the BP AC over it? I'd have to spend a few more minutes checking?

< kayabanerve:monero.social > But re: range proofs, which currently use BP+, this work would presumably inherit the BP+ range proof construction (if this doesn't posit its own range proof -> IPA conversion) if it maintains the ZK property.

< kayabanerve:monero.social > please, correct me if I'm wrong. I'm just starting to read through this and am stating my initial thoughts.

< kayabanerve:monero.social > *This is also SHVZK.

< rucknium:monero.social > xmrack said you were interesting if research funding is available. "Yes", but the process can be unconventional. There are two main ones: The Community Crowdfunding System: https://ccs.getmonero.org/ and the MAGIC Monero Fund: https://monerofund.org/

< kayabanerve:monero.social > emsczkp: Can you clarify the numbers re: exponentiations? Bulletproofs doing 2n exponentiations is referring to how each round does point scalings for the intermediates?

< kayabanerve:monero.social > Or are you referring to scalar exponentiations, the powers of y/z and so on?

< rucknium:monero.social > We can end the official meeting time here and discussion can continue :)

< emsczkp:matrix.org > The statement of the Compressed Sigma-IPA is 1:1 with the BP's IPA

< emsczkp:matrix.org > It can be combined well with the AC proofs

< kayabanerve:monero.social > The statement just prior to section 4, marked (1) is not. It places the c in the exponent.

< kayabanerve:monero.social > Argh. I'm stupid.

< kayabanerve:monero.social > Sorry, you're right. You follow describing c in the exponent and Bulletproofs immediately makes the same mutation.

< kayabanerve:monero.social > That's my misunderstanding and my bad, sorry again.

< kayabanerve:monero.social > *Also, you work clarifies itself as not necessarily SHVZK, which I assume means this IPA should not be considered so. Sorry, another misreading of mine. My head is two places right now.

< kayabanerve:monero.social > Apologies again for the misremembering/poor initial skim. This would be usable as a replacement for the BP IPA, if correct, and facilitate faster FCMPs/range proofs (if correct there as well). My current question is on the "exponentiations" (point scalings or scalar exponentiations).

< emsczkp:matrix.org > In the efficiency analysis, for exponentiations i mean the multi-exponentiation for computing the new generators G and H in each folding round

< kayabanerve:monero.social > Right. Bulletproofs doesn't actually incur that.

< kayabanerve:monero.social > You can delay the entire multiexponentation to the end if the verifier.

< emsczkp:matrix.org > inversions are related to the operations for computing the folded vectors A and B

< kayabanerve:monero.social > The per-round aspect is exclusively prover/notational.

< kayabanerve:monero.social > That does still leave a faster prover, faster verifier re: no inversions, The communication is the same?

< emsczkp:matrix.org > we could delay also the entire multi-exp in a single multi-exp in the verifier , but this is not shown in the paper

< kayabanerve:monero.social > I presumed so and wasn't trying to claim BP potentially faster, solely note the performance claims don't hold for the verifier.

< kayabanerve:monero.social > (if one optimizes their impl, the claims do hold as-notated)

< emsczkp:matrix.org > The security of the Compressed Sigma-IPA is based on the multi-round special soundness notion, which implies the WEE

< jeffro256:monero.social > WEE?

< kayabanerve:monero.social > I actually am interested in this. I'd be happy to replace the proof in FCMPs and see how they do comparatively. If performance does end up non-negligible, we could discuss review.

< kayabanerve:monero.social > witness extended emulation

< emsczkp:matrix.org > communication is still the same as in BP

< kayabanerve:monero.social > To be extremely honest, saving... 22 inversions? Will probably end up as negligible. The faster prover time, while pleasant, isn't dominated by the IPA proof AFAIK. My guess is our usage of divisors does.

< kayabanerve:monero.social > If this does end up a ms or so faster (~10%), I would love to ask for Aaron's feedback and consider schedule availability though.

< kayabanerve:monero.social > Er, sorry. ~30 inversions.

< emsczkp:matrix.org > I will go more in detail also in FCMP because it sounds interesting to me... sorry guys but now i have to leave

< emsczkp:matrix.org > Thank you all for your time, i'm truly grateful to be able to contribute to monero

< kayabanerve:monero.social > I do appreciate improvements and apologize if that's blunt. I am happy to consider this further on my end re: FCMPs :)

< kayabanerve:monero.social > Re: range proofs, it'd add 32 bytes and may decrease verification time a bit, which BP+ also did. That may eke out a victory, especially in a batch verification content...

monero-project / meta

Monero Research Lab Meeting - Wed 12 June 2024, 17:00 UTC #1022

1020