-
gingeropolous_
Guest68, please try #monero-pools
-
m-relay
<rucknium:monero.social> MRL meeting in this room in about two hours.
-
m-relay
<rucknium:monero.social> Meeting time!
monero-project/meta #1025
-
m-relay
<rucknium:monero.social> 1) Greetings
-
isthmus
Heya
-
rbrunner
Hello
-
m-relay
<kayabanerve:monero.social> 👋
-
vtnerd
hi
-
m-relay
<rucknium:monero.social> 2) Updates. What is everyone working on?
-
spackle
hi
-
isthmus
I did some more work on/with my library for detecting a particular anomaly created by some non-wallet2 codebase that caches decoys and reuses them (across hundreds or thousands of transactions)
pypi.org/project/ringxor
-
m-relay
<rucknium:monero.social> me: Mostly Stressnet things. I wrote a Shiny app to collect and display stressnet data at
monitor.stressnet.net . Set up a stressnet explorer at
explorer.stressnet.net . Wrote a transaction spamming script ( + tested jeffro256 's new feature to make "outputs pay for fees" in a tx).
-
jberman
me: continued the fcmp trim_tree algo implementation
-
m-relay
<kayabanerve:matrix.org> I presented at Monerokon and have an update on Veridise.
-
rbrunner
Hmm, that stressnet explorer gives me "502 Bad Gateway" right now. Already spammed to death? :)
-
m-relay
<rucknium:monero.social> 3) Stress testing `monerod`
monero-project/monero #9348
-
spackle
testing is in progress
-
vtnerd
I finished stress testing LWS remote scanning. Everything looked as expected except for one outstanding bug report (unrelated to remote scanning). Still waiting to hear back on that
-
m-relay
<rucknium:monero.social> The node died earlier. Maybe the explorer is dead too. `xmrblocks uses more RAM and CPU than I expected.
-
vtnerd
also working on updating the serialization code again, will probably reduce the one PR a bit so that hopefully some more reviews (other than jeffro, thanks!) will come in
-
m-relay
<emsczkp:matrix.org> Hi everyone, I hope my message gets through. I'm Emanuele Ph.D, I worked on the implementation of the compressed sigma-ipa and compared it with bp ipa
-
m-relay
<rucknium:monero.social> We already got reliable reproduction of out-of-memory error when a stressnet node has lots of connections:
monero-project/monero #9348#issuecomment-2170629015
-
m-relay
<rucknium:monero.social> By boog900
-
m-relay
<rucknium:monero.social> emsczkp: Hi! Do you want to bring up a topic at this meeting again? More discussion from you is welcome :) Maybe you can discuss at the FCMP agenda item
-
m-relay
<rucknium:monero.social> Any Monero protocol developers who want to test performance patches can sync a node to stressnet. It's a good time now to test. AFAIK we want to run stressnet for about two months. Discussion happens in #monero-stressnet:monero.social and ##monero-stressnet on IRC
-
m-relay
<0xfffc:monero.social> ( hi )
-
m-relay
<emsczkp:matrix.org> thanks you rucknium, i'll discuss at point FCMP
-
rbrunner
Is the traffic on stressnet now "at maximum" already?
-
m-relay
<rucknium:monero.social> No. I don't know where the maximum will be, but spackle is still sending out txs
-
rbrunner
Or all there plans to make happenings like "Now all we all spam together"?
-
rbrunner
Alright, will follow the Matrix room to learn more!
-
m-relay
<rucknium:monero.social> AFAIK, the spam timing will be loosely coordinated. Probably spackle can spam enough all by himself, but others can add more.
-
rbrunner
Don't want to complain, but a single source of transactions is probably ... not very typical :) Except if we have a spam wave, that is
-
m-relay
<rucknium:monero.social> That is true. I have 50,000 outputs ready to go into a spamming cycle. That would be about 75MB of txs in the txpool. The stressnet spamming started about two hours ago. I think we will see how things go and adjust.
-
m-relay
<rucknium:monero.social> 4) Potential measures against a black marble attack
monero-project/research-lab #119
-
m-relay
<rucknium:monero.social> I don't really have anything to add to this agenda item right now. I think I will have the update that gives Alice a budget constraint by next meeting.
-
m-relay
<rucknium:monero.social> 5) Research Pre-Seraphis Full-Chain Membership Proofs.
getmonero.org/2024/04/27/fcmps.html
-
m-relay
<rucknium:monero.social> kayabanerve: , emsczkp
-
m-relay
<kayabanerve:monero.social> Veridise has completed a proof of the divisor technique. Their proof does force modifications to my R1CS gadget yet nothing notable here. I hope to, by next meeting, have a quote for the review of the proofs.
-
m-relay
<aaron:cypherstack.com> Is this publicly available?
-
m-relay
<rucknium:monero.social> Fantastic!
-
m-relay
<kayabanerve:monero.social> Review of the R1CS gadget, as a specification, may or may not fit into the allocated hours. It may require an extension, say +5h (of 24h allocated) which would incur a further cost.
-
m-relay
<kayabanerve:monero.social> The R1CS gadget, which needs updates, accordingly may be done on a distinct contract OR the work there will continue next week on the current SoW, once I do my updates. We're seeing what's best now.
-
m-relay
<emsczkp:matrix.org> I just wanted to say that my implementation shows a 50% optimization on verification times compared to the BP's IPA
-
m-relay
<kayabanerve:matrix.org> Aaron Feickert: Not yet. I asked for them to clarify some ambiguous notation. It's not breaking, it's just a bit wonky to read. Once I have that final PDF, or at least their confirmation that the one thus far shared is okay to publish (not an internal preprint), I'll share it. Ideally a day or two.
-
m-relay
<kayabanerve:matrix.org> emsczkp: Would you please share a link and clarify if you're delaying the verification to a final multiexp or not?
-
m-relay
<kayabanerve:matrix.org> (to the implementation. I'd be shocked if saving the inversions was so impactful)
-
m-relay
<emsczkp:matrix.org> I can share the repositories. Just a second, I'll make it public. I haven't implemented the multi-exp version yet and I'm working on it
-
m-relay
<kayabanerve:matrix.org> I'll further clarify I'm holding off on soliciting quotes for further review until I do have the PDF to be shared, as necessary to get quotes. So ideally, in a day or two I can solicit quotes, and ideally we have them Monday for the meeting Wednesday? That somewhat applies weekend quotes, so the review quotes may be up to the wire on the meeting :/ Apologies.
-
m-relay
<rucknium:monero.social> kayabanerve: That sounds good to me. Thanks for doing all the coordination.
-
m-relay
<emsczkp:matrix.org> this is the repo
github.com/EmanueleSc/IV-IPA , the name is misleading because it would be the final idea... meanwhile "inner-sigma" i.e., the compressed sigma-ipa, and "inner" i.e., the BP IPA are implemented. I can share screenshots of benchmarks
-
m-relay
<aaron:cypherstack.com> Is this approach formalized anywhere?
-
m-relay
<kayabanerve:monero.social> I'm also soliciting review of the GBP proofs, and have been for a week or so. There's one candidate in mind so I'm hoping that works out. Else, it'll be another candidate spread, likely Goodell and one or two other groups.
-
m-relay
<rucknium:monero.social> Aaron Feickert: Scala, E., & Mostarda, L. 2024, Efficient inner-product argument from compressed $sigma$-protocols and applications. Paper presented at International Conference on Advanced Information Networking and Applications.
moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=221
-
m-relay
-
m-relay
<kayabanerve:monero.social> With GBP proof review, we can move to auditing. With the divisor gadget also signed off on, we can move to its entire circuit?
-
m-relay
<rucknium:monero.social> ^ I think that's the paper
-
m-relay
<kayabanerve:monero.social> So progress being made on a few ends there.
-
m-relay
<kayabanerve:matrix.org> I'll ask Aaron Feickert, who is welcome to reply privately, if
-
m-relay
<kayabanerve:matrix.org> 1) They're happy with the notation in their proofs and are fine with me sending them off as-is. I assume so yet will double check.
-
m-relay
<kayabanerve:matrix.org> 2) They reached out to the original authors (_and_ specifically noted the H_i extraction)
-
m-relay
<kayabanerve:matrix.org> Oh, and 3) If they can confirm again (I did ask back in the day), the cross-product issue preventing more efficient H_i extraction is non-trivial and we should move forward with the protocol as-is.
-
m-relay
<aaron:cypherstack.com> 1. The report made available at the CS repository should be fine for review by anyone interested.
-
m-relay
<aaron:cypherstack.com> 2. We did reach out to the original authors (in early May), but did not hear back.
-
m-relay
<aaron:cypherstack.com> 3. Correct, but I would be thrilled if someone found a way around this limitation :D
-
m-relay
<kayabanerve:matrix.org> In that case, I won't push it and will move forward with review as-is.
-
m-relay
<aaron:cypherstack.com> That being said, I'd be shocked if there weren't typos in the notation somewhere...
-
m-relay
<aaron:cypherstack.com> (but there are none I know of)
-
m-relay
<kayabanerve:matrix.org> I want to personally try out the above IP A, as an experiment on the verification times, as it'd save a few inversions. The claims of saving verifier scalings/50% are presumed notational artifacts at this time and not expected IRL.
-
m-relay
<kayabanerve:matrix.org> I literally implemented it off your notation >:(
-
m-relay
<kayabanerve:matrix.org> That implies correctness
-
m-relay
<kayabanerve:matrix.org> Or dyslexia on my end.
-
m-relay
<aaron:cypherstack.com> Heh, I mean typos in general. Sorry, didn't mean to imply more!
-
m-relay
<emsczkp:matrix.org> kayabanerve explains so will you test the solution?
-
m-relay
<emsczkp:matrix.org> sorry but I always have the "federation problem" on the server and it's difficult to follow the chat perfectly
-
m-relay
-
m-relay
<kayabanerve:matrix.org> Refresh that every minute or so, as a workaround
-
m-relay
<kayabanerve:matrix.org> I will try it out with FCMPs specifically, as an experiment. If it saves a sufficiently notable amount of time, I'd likely request quotes as necessary to evaluate if we have the bandwidth to also move forward with it.
-
m-relay
<emsczkp:matrix.org> ok thanks for the effort, I'm waiting for news and I hope that my contribution is the one expected in order to move forward
-
m-relay
<rucknium:monero.social> We can end the meeting here. Thanks everyone.
-
m-relay
<kayabanerve:matrix.org> I'd likely need to see those inversions save 5-10+%. The inversions are expensive, yet I'm not convinced they sufficiently weigh considering the amount of scalar matrix muls we currently face.
-
m-relay
<kayabanerve:matrix.org> That's off the total proof, not just the IPA.
-
m-relay
<rucknium:monero.social> Discussion can continue of course :)
-
m-relay
<emsczkp:matrix.org> kayabanerve: Do you have a formal specification I can refer to? I would like to know more
-
m-relay
<emsczkp:matrix.org> I know you have implemented bp+ , and are addressing GBP. I would like to have some material if possible
-
m-relay
<aaron:cypherstack.com> You mean IPA challenge inversions? Those can also be batched, so as to replace multiple inversions with a single inversion and sequence of multiplications
-
m-relay
<aaron:cypherstack.com> (assuming this is what you meant)
-
m-relay
<kayabanerve:monero.social> My looking into spending the time and effort on this, which expends limited bandwidth, would likely have the aforementioned reward necessary. The current IPA proof itself is available at
-
m-relay
-
m-relay
<kayabanerve:matrix.org> I'm pulling up the benchmark command, one moment...
-
m-relay
<kayabanerve:matrix.org> Sorry, I became quite distracted. I sent on monero.social the link to the current IPA (see logs). The benchmarks can be run with `cargo test --all-features -p full-chain-membership-proofs -- --nocapture` from
github.com/kayabaNerve/fcmp-plus-plus.
-
m-relay
<kayabanerve:matrix.org> emsczkp:
-
m-relay
<emsczkp:matrix.org> Thank you for the repo, i'll do some experiments on the ipa
-
m-relay
<kayabanerve:matrix.org> *--release
-
m-relay
<kayabanerve:matrix.org> One should also benchmark with the `--release` flag, added after `test` in the above command.