09:00:42 <m-relay> <y​pavtv97lx:matrix.org> Where can I find Dynamic Block Size documentation used by Monero ?
09:08:26 <m-relay> <y​pavtv97lx:matrix.org> ok found it
09:08:59 <m-relay> <j​effro256:monero.social> PDF Scaling Definitions Proposed Scaling Definitions (May 2021 update) 1 ...
09:09:11 <m-relay> <j​effro256:monero.social> https://raw.githubusercontent.com/ArticMine/Monero-Documents/master/MoneroScaling2021-02.pdf
12:51:37 <m-relay> <x​mrack:monero.social> I’ve been in contact with Emanuele, one of the authors from the constant size range proof paper.
12:51:38 <m-relay> <x​mrack:monero.social> https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=178&browserTabID=
12:51:40 <m-relay> <x​mrack:monero.social> He sent me the following regarding getting funding to continue their research. 
12:51:42 <m-relay> <x​mrack:monero.social> “””
12:51:44 <m-relay> <x​mrack:monero.social> Constant RP is taking two directions in parallel.
12:51:46 <m-relay> <x​mrack:monero.social> One is a transparent version (long-term direction) and the second is a trustless IP but optimized in verification time (short-term direction and from our conference https://link.springer.com/chapter/10.1007/978-3-031-57916-5_28).
12:51:48 <m-relay> <x​mrack:monero.social> We would ask if it is possible to get some help from the monero community, e.g., crowdfounding, to develop the extended version of the second (improved comparison with BP+ and BP++, finding some interactions, and so on ...).
12:51:50 <m-relay> <x​mrack:monero.social> Best regards,
12:51:52 <m-relay> <x​mrack:monero.social> Emanuele
12:51:54 <m-relay> <x​mrack:monero.social> “””
12:52:25 <m-relay> <x​mrack:monero.social> I’ve uploaded their paper to Monero Research 
12:52:26 <m-relay> <x​mrack:monero.social> https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=221&success=attachAdd&browserTabID=
12:56:43 <m-relay> <k​ayabanerve:matrix.org> https://eprint.iacr.org/2024/921.pdf would offer a ring of 32 for the same size as our current rings, and from there solely increase by 64 bytes per doubling of ring size. The issue is their model isn't inclusive of Pedersen commitments, solely keys.
13:03:56 <m-relay> <a​aron:cypherstack.com> Hm, wonder if it's feasible to extend from an LRS to a `d`-LRS (since RingCT requires a 2-LRS)
13:04:33 <m-relay> <k​ayabanerve:matrix.org> We could rush the FCMP work alternatively, if we actually wanted to discuss this.
13:04:59 <m-relay> <k​ayabanerve:matrix.org> A single layer FCMP would also use a GBP, and not need any tree infrastructure.
13:05:50 <m-relay> <k​ayabanerve:matrix.org> *would also use a (G)BP(+), which this uses to achieve a log proof.
14:44:01 <m-relay> <x​mrack:monero.social> Emanuele will be joining the MRL meeting today to discuss their research progress and discuss funding for future work.
14:44:47 <m-relay> <r​ucknium:monero.social> Are MRL people who would be helpful in that conversation coming to the meeting?
15:06:30 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in two hours.
15:25:32 <xFFFC0000> ( my apologies in advance. I will not be able to participate in today’s meeting because of emergency, and will be off for few hours )
16:09:59 <m-relay> <c​haser:monero.social> all the best with whatever you're facing, xFFFC.
16:58:01 <m-relay> <j​berman:monero.social> Apologies as well for the late heads up, won't be in a good spot for today's meeting. Will participate as able
17:01:03 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/1022
17:01:12 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:01:18 <m-relay> <x​mrack:monero.social> Hi
17:01:25 <m-relay> <a​rticmine:monero.social> Hi
17:01:26 <m-relay> <c​haser:monero.social> hello
17:01:31 <m-relay> <v​tnerd:monero.social> Hi
17:01:33 <spackle> hello
17:01:35 <rbrunner> Hello
17:01:48 <m-relay> <j​effro256:monero.social> Howdy
17:03:06 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:03:39 <m-relay> <j​berman:monero.social> Continuing fcmp tree work, continuing the trim algorithm
17:03:55 <m-relay> <s​yntheticbird:monero.social> Hi
17:04:15 <m-relay> <x​mrack:monero.social> Starting work on stressnet
17:04:34 <m-relay> <s​yntheticbird: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
17:04:42 <m-relay> <v​tnerd:monero.social> Me: still stress testing the LWS remote scan feature, and found some bugs in the process
17:05:04 <m-relay> <a​rticmine:monero.social> Continuing work on scaling after my presentation at MoneroKon
17:05:12 <m-relay> <r​ucknium: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 😅
17:05:41 <spackle> misc. stressnet tasks
17:06:02 <m-relay> <r​ucknium:monero.social> xmrack: Do we have Emanuele here?
17:07:39 <m-relay> <r​ucknium:monero.social> Thanks for contacting them
17:07:43 <m-relay> <x​mrack:monero.social> Im not sure. I could ping him over email
17:08:22 <m-relay> <r​ucknium: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
17:08:38 <m-relay> <r​ucknium:monero.social> 3) Stress testing `monerod` https://github.com/monero-project/monero/issues/9348
17:08:52 <spackle> The stressnet release is published: https://github.com/spackle-xmr/monero/releases/tag/v250.18.3.3.1
17:08:57 <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.
17:09:32 <m-relay> <x​mrack:monero.social> Rucknium: did you want to share the Shiny app or are you working on it more?
17:09:37 <m-relay> <r​ucknium:monero.social> We have a stressnet block explorer running: http://explorer.stressnet.net:8081
17:10:08 <m-relay> <r​ucknium:monero.social> xmrack: Not sure. I may share in the next agenda item
17:10:16 <rbrunner> Fantastic progress.
17:10:33 <m-relay> <s​yntheticbird:monero.social> Have the stressnet nodes already caused system crash or memory exhaustion yet on some host ?
17:10:54 <m-relay> <r​ucknium:monero.social> The SSL cert for https will be added soon. We have an onion hidden service too: http://xmrstrss5d6fii5mku5glfxp3g73unofae2yh4cndfxgvbexbifhguyd.onion/
17:11:19 <m-relay> <r​ucknium:monero.social> You can see in the block explorer that we are not stressing the network right now
17:11:43 <spackle> I have observed excessive memory use on a test machine, up to 71.7GB for one instance of monerod
17:11:49 <m-relay> <r​ucknium:monero.social> spackle had very high RAM usage on the node that was receiving the spam for the wallet, recently
17:12:07 <spackle> The machine had 128GB RAM available, so no OOM crash occurred.
17:12:16 <m-relay> <r​ucknium:monero.social> I mean spam _from_ the wallet
17:13:58 <m-relay> <r​ucknium: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
17:14:03 <m-relay> <j​effro256:monero.social> Me: finishing first draft of Jamtis-RCT library
17:15:22 <m-relay> <r​ucknium: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.
17:16:00 <m-relay> <r​ucknium:monero.social> Thanks again to selsta and plowsof for helping with the release binaries workflow on GitHub.
17:16:20 <m-relay> <a​rticmine:monero.social> When considering CPU usage is this per thread?
17:16:55 <m-relay> <r​ucknium:monero.social> I have just made code to save the CPU and MEM output of `top` for monerod
17:17:14 <m-relay> <r​ucknium:monero.social> Maybe there is a way to get more detail.
17:18:20 <m-relay> <r​ucknium: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.
17:18:58 <m-relay> <a​rticmine:monero.social> It is a good start. Thread count and CPU specs will be very helpful.
17:20:18 <m-relay> <s​yntheticbird:monero.social> Rucknium tho harder you'll likely find more and accurate informations in `/proc/PID` directory
17:21:03 <m-relay> <r​ucknium:monero.social> Thanks. I will try to get info from there.
17:22:29 <m-relay> <r​ucknium:monero.social> More comments or questions on stressnet?
17:24:02 <m-relay> <r​ucknium:monero.social> 4) Potential measures against a black marble attack. https://github.com/monero-project/research-lab/issues/119
17:28:21 <m-relay> <r​ucknium: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/
17:28:25 <m-relay> <a​rticmine: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.
17:28:28 <m-relay> <r​ucknium: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
17:29:23 <m-relay> <r​ucknium: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.
17:29:29 <m-relay> <x​mrack:monero.social> I need to leave but emanuele is having issues making a monero.social account. He’s actively trying to join
17:29:54 <m-relay> <j​effro256:monero.social> What kind of issues ?
17:32:08 <m-relay> <c​haser:monero.social> this is very useful, thanks!
17:32:39 <m-relay> <j​effro256: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
17:33:05 <m-relay> <r​ucknium:monero.social> I am going to add the two other solution types I discussed last meeting and add explanatory text
17:34:07 <m-relay> <a​rticmine:monero.social> I can do this
17:34:41 <m-relay> <j​effro256:monero.social> Nice! It would be nice to see actual numbers, especially for full decoy removal
17:34:55 <m-relay> <r​ucknium:monero.social> Maybe we can combine my analysis with the surge factor analysis
17:35:05 <m-relay> <a​rticmine:monero.social> Yes
17:35:08 <m-relay> <r​ucknium:monero.social> I think we got emsczkp
17:35:39 <m-relay> <r​ucknium:monero.social> Ok we will finish discussion of this agenda item, then put emsczkp  next
17:35:54 <m-relay> <s​yntheticbird:monero.social> be aware emsczkp is on matrix.org
17:36:48 <m-relay> <s​omeoneelse495495: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
17:36:50 <m-relay> <r​ucknium:monero.social> Ok. He will have to look at https://libera.monerologs.net/monero-research-lab/20240612
17:37:27 <m-relay> <e​msczkp:matrix.org> Ok thanks, i will try
17:37:54 <m-relay> <j​effro256:monero.social> Welcome
17:37:57 <m-relay> <r​ucknium:monero.social> Dan Miller: Any progress figuring out what the federation issues with matrix.org are?
17:37:58 <m-relay> <s​omeoneelse495495:matrix.org> Sorry this is a reccurent issue. Be sure participants do see your messages tho
17:38:17 <m-relay> <s​omeoneelse495495:matrix.org> Sorry this is a reccurent issue. You can be sure participants do see your messages tho
17:38:56 <m-relay> <r​ucknium:monero.social> is kayabanerve  / kayabanerve  here?
17:39:48 <m-relay> <r​ucknium:monero.social> emsczkp: Welcome! Could you introduce yourself, explain your recent work, and your interest in improving the Monero protocol?
17:40:32 <m-relay> <e​msczkp:matrix.org> so I write in this chat and view the replies here monerologs.net?
17:40:40 <m-relay> <s​omeoneelse495495:matrix.org> Yes
17:40:45 <m-relay> <s​omeoneelse495495:matrix.org> Don't forget to resfresh monerologs.net
17:43:13 <m-relay> <e​msczkp:matrix.org> thanks you all, I will introduce my self and explain my research objectives
17:51:44 <m-relay> <e​msczkp: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<clipped message>
17:51:46 <m-relay> <e​msczkp: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<clipped message>
17:51:48 <m-relay> <e​msczkp:matrix.org> cement is the field with BP+ and BP++
17:52:49 <m-relay> <r​ucknium:monero.social> Wonderful
17:54:01 <m-relay> <a​rticmine:monero.social> I have a question. How would this research impact the proposed FCMP in Monero.?
17:54:36 <m-relay> <a​rticmine:monero.social> Full Chain Membership Proofs
17:55:15 <m-relay> <r​ucknium: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
17:55:34 <m-relay> <a​rticmine:monero.social> I am very excited about reductions in transaction size and verification time
17:55:44 <m-relay> <e​msczkp:matrix.org> thank you for the question, what is FCMP exactly ?
17:56:06 <m-relay> <k​ayabanerve:monero.social> full-chain membership proofs
17:56:11 <m-relay> <r​ucknium:monero.social> FCMP is an adaption of Curve Trees to Monero, AFAIK
17:56:56 <m-relay> <r​ucknium:monero.social> Basically using nested Bullletproofs to form the anonymity set of Monero instead of ring signatures
17:57:05 <rbrunner> They have something like BP somewhere inside, yes? GBP or how they are called.
17:58:06 <m-relay> <k​ayabanerve:monero.social> sorry, that was replying to emsczkp. My messages are out of order so I'm unsure that was in context
17:59:23 <m-relay> <e​msczkp:matrix.org> The Inner-product argument is used in the Monero range proof/membership proof system, in the original BP version
17:59:53 <m-relay> <j​effro256: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
18:00:08 <m-relay> <r​ucknium:monero.social> How much of the total BP verification time is spent on the IPA?
18:00:10 <m-relay> <e​msczkp:matrix.org> by improving the inner-product argument, the overall system will benefit
18:01:04 <m-relay> <k​ayabanerve:monero.social> 1) jeffro256: Please link to Aaron's specification and proofs, it's more comprehensive.
18:01:04 <m-relay> <k​ayabanerve:monero.social> 2) We need an IPA which enables an arithmetic circuit proof which can open Pedersen Vector Commitments.
18:01:46 <m-relay> <k​ayabanerve: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.
18:02:44 <m-relay> <k​ayabanerve: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.
18:03:38 <m-relay> <k​ayabanerve: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.
18:07:05 <m-relay> <e​msczkp: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.
18:08:36 <m-relay> <k​ayabanerve: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?
18:09:25 <m-relay> <k​ayabanerve: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.
18:09:55 <m-relay> <k​ayabanerve:monero.social> please, correct me if I'm wrong. I'm just starting to read through this and am stating my initial thoughts.
18:10:38 <m-relay> <k​ayabanerve:monero.social> *This is also SHVZK.
18:11:39 <m-relay> <r​ucknium: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/
18:15:03 <m-relay> <k​ayabanerve: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?
18:15:44 <m-relay> <k​ayabanerve:monero.social> Or are you referring to scalar exponentiations, the powers of y/z and so on?
18:23:02 <m-relay> <r​ucknium:monero.social> We can end the official meeting time here and discussion can continue :)
18:24:55 <m-relay> <e​msczkp:matrix.org> The statement of the Compressed Sigma-IPA is 1:1 with the BP's IPA
18:25:49 <m-relay> <e​msczkp:matrix.org> It can be combined well with the AC proofs
18:28:42 <m-relay> <k​ayabanerve:monero.social> The statement just prior to section 4, marked `(1)` is not. It places the c in the exponent.
18:28:58 <m-relay> <k​ayabanerve:monero.social> Argh. I'm stupid.
18:29:23 <m-relay> <k​ayabanerve:monero.social> Sorry, you're right. You follow describing c in the exponent and Bulletproofs immediately makes the same mutation.
18:29:31 <m-relay> <k​ayabanerve:monero.social> That's my misunderstanding and my bad, sorry again.
18:30:18 <m-relay> <k​ayabanerve: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.
18:31:52 <m-relay> <k​ayabanerve: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).
18:32:34 <m-relay> <e​msczkp: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
18:32:57 <m-relay> <k​ayabanerve:monero.social> Right. Bulletproofs doesn't actually incur that.
18:33:15 <m-relay> <k​ayabanerve:monero.social> You can delay the entire multiexponentation to the end *if the verifier*.
18:33:34 <m-relay> <e​msczkp:matrix.org> inversions are related to the operations for computing the folded vectors A and B
18:33:51 <m-relay> <k​ayabanerve:monero.social> The per-round aspect is exclusively prover/notational.
18:35:39 <m-relay> <k​ayabanerve:monero.social> That does still leave a faster prover, faster verifier re: no inversions, The communication is the same?
18:36:52 <m-relay> <e​msczkp: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
18:37:22 <m-relay> <k​ayabanerve: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.
18:37:52 <m-relay> <k​ayabanerve:monero.social> (if one optimizes their impl, the claims do hold as-notated)
18:38:23 <m-relay> <e​msczkp:matrix.org> The security of the Compressed Sigma-IPA is based on the multi-round special soundness notion, which implies the WEE
18:38:53 <m-relay> <j​effro256:monero.social> WEE?
18:39:01 <m-relay> <k​ayabanerve: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.
18:39:10 <m-relay> <k​ayabanerve:monero.social> witness extended emulation
18:39:35 <m-relay> <e​msczkp:matrix.org> communication is still the same as in BP
18:43:14 <m-relay> <k​ayabanerve: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.
18:43:16 <m-relay> <k​ayabanerve: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.
18:43:30 <m-relay> <k​ayabanerve:monero.social> Er, sorry. ~30 inversions.
18:44:20 <m-relay> <e​msczkp: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
18:44:58 <m-relay> <e​msczkp:matrix.org> Thank you all for your time, i'm truly grateful to be able to contribute to monero
18:45:21 <m-relay> <k​ayabanerve:monero.social> I do appreciate improvements and apologize if that's blunt. I am happy to consider this further on my end re: FCMPs :)
18:46:33 <m-relay> <k​ayabanerve: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...