12:02:39 <br-m> <emsczkp:matrix.org> Really happy to share BP*:  https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626
12:27:33 <CjS77> Hey all -- unfortunately I won't be able to make the MRL meeting later today due to existing commitments at that time. I believe that the Grease CCS is on the agenda. Is there anything you want to know ahead of time that I can answer now?
12:28:38 <CjS77> Otherwise, I'll keep this session open and answer any questions tomorrow.
13:09:17 <br-m> <kayabanerve:matrix.org> CjS77: I asked some questions in monero-community (after you left, unfortunately) about how a 'private blockchain' could form the key escrow service. AFAICT, none of your cited candidates would be so usable.
13:10:31 <br-m> <kayabanerve:matrix.org> If there aren't viable plans to decentralize past a trusted third party, I believe that limits the potential ideation and consideration for the idea.
13:42:04 <br-m> <plowsof:matrix.org> kayabanerve a reply was left on gitlab here: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651#note_35329
13:43:11 <br-m> <kayabanerve:matrix.org> Ah, thank you, plowsof ♥
13:44:24 <br-m> <kayabanerve:matrix.org> > I wouldn't say impossible, but it definitely be trickier and involve some sort of MPC ceremony at least. I'd need to think about it a bit and circle back to this.
13:44:24 <br-m> <kayabanerve:matrix.org> > 
13:44:24 <br-m> <kayabanerve:matrix.org> > The other option is to go for a KES running on a TEE -- the benefit of decentralisation was more for code immutability as a protection against collusion than anything else.
13:44:24 <br-m> <kayabanerve:matrix.org> is the most relevant subset of the response, IMO.
15:04:34 <br-m> <rucknium> MRL meeting in this room in two hours.
17:00:27 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1359
17:00:33 <br-m> <rucknium> 1. Greetings
17:00:54 <UkoeHB> Hi
17:01:11 <br-m> <jberman> waves
17:01:31 <rbrunner> Hello
17:01:36 <br-m> <vtnerd> hi
17:02:39 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:03:21 <br-m> <vtnerd> me: working on some monerod bug fixes, and a bunch of docker stuff for monero-lws (primarily for use in the docs/tutorials website)
17:03:58 <br-m> <iamnew117:matrix.org> hello
17:04:15 <br-m> <jberman> me: progressing FCMP++ integration audit, continuing on a fix for a hanging shutdown in monerod (PR should be ready today)
17:04:58 <UkoeHB> me: to start reviewing carrot_core today.
17:05:54 <br-m> <rucknium> 3. FCMP code integration audit overview (https://github.com/seraphis-migration/monero/issues/294).
17:08:29 <br-m> <jberman> Received a quote from Cypher Stack, and with the help of @sgp_:monero.social planning to reach out to some more firms to get additional quotes. Would prefer to keep the CS quote private until we have all quotes & estimates
17:09:57 <br-m> <rucknium> I need to start bringing out some auction theory for these audit bidding processes 😉
17:10:29 <br-m> <jberman> Heh
17:11:21 <br-m> <rucknium> Anything else on this agenda item?
17:12:28 <br-m> <rucknium> 4. FCMP beta stressnet (https://github.com/seraphis-migration/monero/issues/166).
17:14:32 <br-m> <jberman> Have gotten word from kayaba, progress on the major blocking item for beta (GBP changes in response to audit) is expected
17:14:55 <br-m> <rucknium> Great!
17:15:30 <rbrunner> "progess is expected" sounds cautious, but certainly going into the right direction :)
17:17:34 <br-m> <rucknium> 5. Grease Payment Channels (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651).
17:18:28 <br-m> <rucknium> This is a CCS proposal for the first operational payment channel implementation for Monero.
17:19:25 <br-m> <rucknium> Total requested budget is 516.9 XMR.
17:20:49 <br-m> <rucknium> The Bitcoin Lightning Network is a network of many payment channels linked together. IIRC, the Grease team wants to focus on one-to-one or small networks instead of trying to implement a Monero Lightning Network.
17:20:53 <plowsof> CJS77 can not make it today, kayaba responded to a comment on gitlab earlier here https://libera.monerologs.net/monero-research-lab/20260325#c663230
17:21:38 <rbrunner> Quite some stuff to read, that CCS text is very detailed
17:21:42 <br-m> <jberman> Seems like @kayabanerve:matrix.org raised a good point. In line with that point, it doesn't seem like it should be marketed as a trustless solution when it relies on a solution not yet fleshed out / explained
17:21:53 <br-m> <rucknium> After the meeting, CjS77 can answer any quested posted during the meeting.
17:23:16 <br-m> <rucknium> I'm a skeptic on Payment Channel Networks as a 2nd layer payment system, but not a skeptic on small-scale payment channels, FWIW.
17:23:35 <br-m> <jberman> and also the core innovation of payment channels was/is the trustless factor, so I think it's extremely critical that that is fleshed out
17:24:32 <rbrunner> It seems it's altogether easy to underestimate what is needeed for "just connect two people" ...
17:24:32 <br-m> <articmine> This is a very exciting proposal. I find the focus on one to one or small networks particularly appealing. My comment is that this is not a substitute for scaling.
17:24:40 <br-m> <rucknium> IMHO, Payment Channel Networks (PCNs) have problems with user adoption, reliability, and privacy.
17:25:31 <br-m> <articmine> @rucknium: I agree for large scale network attempts
17:26:01 <br-m> <rucknium> Lightning has improved its privacy characteristics in recent years AFAIK, but I don't think privacy issues in PCNs can be eliminated completely.
17:26:06 <br-m> <rucknium> Tang, Wang, Fanti, & Oh (2020) "Privacy-Utility Tradeoffs in Routing Cryptocurrency over Payment Channel Networks" https://arxiv.org/abs/1909.02717
17:26:08 <br-m> <articmine> One to one or very small is a different matter .
17:26:10 <br-m> <rucknium> > However, in deployed PCNs [payment channel networks], channel balances (i.e., edge weights are not revealed to users for privacy reasons; users know only the initial weights at time 0. Hence, when routing transactions, users first guess a path, then check if it supports the transaction. This guess-and-check process dramatica [... too long, see https://mrelay.p2pool.observer/e/zpee_PIKLW1fbFNV ]
17:26:35 <br-m> <rucknium> One of that paper's authors, Fanti, is the lead author of the Dandelion++ paper.
17:27:39 <br-m> <articmine> I am especially interested in one to one.
17:27:46 <rbrunner> So this probably also shows nicely how complexity can explode if you from connecting two parties to networks?
17:27:54 <rbrunner> *if you go
17:29:01 <br-m> <rucknium> I think payment channels could be useful for xmrchat.com , for example. Instant payments for the lie super chat messages and you would never have the 10 block lock problem if you wanted to send a lot of messages in a short time. Of course, having a service-side "wallet" that you deposit XMR credits to would have similar characteristics, but would not be trustless.
17:29:50 <rbrunner> Using XMR like a micropayment system
17:30:57 <br-m> <rucknium> rbrunner: IIRC, a paper showed that Lightning routing was NP-hard. But there are heuristics that can get you routing with acceptable reliability. I will try to find the paper.
17:33:07 <rbrunner> Might not take long only people start to bet over such channels ...
17:34:01 <br-m> <articmine> Micro payments is a possible application; however I see XMR funded centralized ledgers as very viable for micro payments. The funding of such a ledger could in itself be a use case for payment channels 
17:34:25 <br-m> <rucknium> I think this is the paper: Pickhardt & Richter (2021) "Optimally Reliable & Cheap Payment Flows on the Lightning Network" https://arxiv.org/abs/2107.05322
17:34:47 <br-m> <rucknium> > We observe that finding the cheapest multi-part payments is an NP-hard problem considering the current fee structure and propose dropping the base fee to make it a linear min-cost flow problem. Finally, we discuss possibilities for maximizing the probability while at the same time minimizing the fees of a flow. While this tu [... too long, see https://mrelay.p2pool.observer/e/gfW9_PIKTlNqNHZ3 ]
17:35:11 <br-m> <rucknium> Pickhardt has done a lot of work on Lightning routing.
17:36:07 <rbrunner> As far as I know it's quite some time since the last time LN really made waves. Maybe struggles to grow?
17:36:21 <br-m> <rucknium> Back to the Key Escrow Service (KES). That does seem like a significant problem with Grease at the moment.
17:36:38 <rbrunner> But I don't think that this really means something for our XMR based proposal now.
17:37:55 <br-m> <rucknium> rbrunner: Merchant data suggests that Lightning adoption is low. And Lightning has an additional big incentive for users that Grease would not have. On-chain BTC fees are much higher than XMR fees are or will be.
17:38:54 <rbrunner> I see
17:38:54 <br-m> <jberman> As I understand it, the existence of the KES implies a reduction in security of the protocol compared to payment channels as implemented on Bitcoin
17:40:25 <br-m> <jeffro256> @rucknium: True, though on the flip side, as was previously mentioned, the 10 block lock is a "push" force 
17:40:50 <br-m> <rucknium> KES serves a purpose similar to the Hash Time Locked Contract (HTLC) + watchtower system in Lightning, right? Except Lightning users can go without a third-party watchtower if their own Lightning node has reliable uptime. With Grease, the KES is mandatory for trustlessness, right?
17:41:40 <br-m> <jberman> That's how I understand it @rucknium:monero.social
17:41:44 <br-m> <jeffro256> @rucknium: That's how I understand it 
17:41:52 <br-m> <jeffro256> Jinx 
17:42:34 <br-m> <rucknium> It's how we understand it :P
17:44:16 <br-m> <rucknium> FWIW, Grease isn't the only proposed Monero payment channel systems. I think there are at least 4 papers total. But Grease, based on Monet, is the only one that has much, if any, code written.
17:45:37 <br-m> <rucknium> ■ (https://eprint.iacr.org/2022/117); ■ (https://eprint.iacr.org/2021/1445); ■ (https://eprint.iacr.org/2020/1441); ■ (https://eprint.iacr.org/2022/744); ■ (https://ieeexplore.ieee.org/abstract/document/10371398)
17:46:09 <br-m> <rucknium> ^ Each of the squares is a Monero Payment Channel paper. From https://github.com/monero-project/research-lab/issues/94
17:47:12 <br-m> <rucknium> More discussion on Grease for now? It will probably appear on next week's agenda too.
17:47:52 <br-m> <rucknium> @emsczkp:matrix.org: Is @emsczkp:matrix.org  here?
17:48:13 <br-m> <emsczkp:matrix.org> here i am
17:49:07 <br-m> <jberman> congrats @emsczkp:matrix.org :)
17:49:09 <br-m> <emsczkp:matrix.org> just to say thank you and i hope you appreciate little BP*. it's already an amazing experience. Looking foreward to see your comments
17:51:14 <br-m> <rucknium> One more thing on PCNs for Monero: IMHO, you have a privacy issue with PCNs even with FCMP because a single Monero tx output start to accumulate "history" if you use it for PCNs. The info is transmitted through the network. But Grease, at present, would mostly avoid that since it's use case is one-to-one and/or small network.
17:51:36 <br-m> <rucknium> 6. Bulletproofs*: Verifier-Efficient Arithmetic Circuit Proofs via Folding (https://eprint.iacr.org/2026/586). CCS update (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626#note_35351).
17:51:59 <br-m> <rucknium> @emsczkp:matrix.org: Could you summarize what your paper has accomplished?
17:55:38 <br-m> <rucknium> Typo: * its use case
17:56:17 <br-m> <emsczkp:matrix.org> In a very summary. This is the first folding scheme, in my knowledge, for BP. Following the ProtoStar compiler, here the name BP*. This toward enabling a best verification across many (folded) proofs and folding scheme are a promising approach
17:56:45 <br-m> <emsczkp:matrix.org> as this result shows
17:57:06 <br-m> <rucknium> Could you explain section 6 of the paper, especially equation 10?
17:58:06 <br-m> <rucknium> And when does the asymptote kick in? :)
17:59:02 <br-m> <rucknium> I know usually you cannot really say when an asymptote kicks in, but I want to check how practical the performance improvement is.
17:59:49 <br-m> <rucknium> Or if the "small/negligible terms" would actually dominate in practical applications.
18:00:12 <br-m> <rucknium> Or if you don't know yet, that is ok.
18:01:07 <br-m> <emsczkp:matrix.org> yes this is an estimate of the resulting IVC verifier execution time, after the folding-to-IVC compilation (as pointed by ProtoStar), and exactily follows a TH of Protostar to show up these estimates
18:02:05 <br-m> <rucknium> I don't know how to interpret expression (10). Maybe in the future you could create a table with example numbers.
18:02:32 <br-m> <rucknium> With comparison to previous implementations.
18:05:25 <br-m> <emsczkp:matrix.org> certainly, concrete implemetation and evaluations are left as future work. but, is in the nature of folding to appreciate such improvements, and we can do such a theoretical enstimation, or otherwise the scheme will be trivial
18:05:38 <br-m> <jberman> IIUC the scheme requires knowledge of the witness to construct the folded proof, right? I.e. not anyone can take 100 random proofs constructed by others and fold them with this scheme
18:05:54 <br-m> <jberman> Requiring knowledge of the witness is what was orginally postulated / expected from BP* (e.g. to make it more efficient to verify huge input proofs), so that would be expected
18:06:10 <br-m> <jberman> to verify huge input txs*
18:08:14 <br-m> <emsczkp:matrix.org> @jberman: what is folded are NARK proofs
18:09:04 <br-m> <emsczkp:matrix.org> @jberman: do you mean a monolithic BP ?
18:10:23 <br-m> <emsczkp:matrix.org> ah no, you said BP*
18:11:06 <br-m> <jberman> so the idea behind BP* is to take n NARK proofs and fold them. Is my understanding incorrect in that the BP* scheme requires the original prover of the NARK proofs to construct the BP*, since the original prover has knowledge of the witness used to construct each NARK proof?
18:13:13 <br-m> <emsczkp:matrix.org> oh yes, the folding prover folds on the witness
18:13:57 <br-m> <emsczkp:matrix.org> oh my god no, sorry i'm bit tired
18:14:41 <br-m> <jberman> no worries :)
18:14:42 <br-m> <emsczkp:matrix.org> i mean, the secret witnesses of the arithmetic circuit preserve zero-knowledge
18:14:59 <br-m> <rucknium> @emsczkp:matrix.org: The conversation can continue once you've had rest, if you want.
18:15:27 <br-m> <emsczkp:matrix.org> sure, thanks!
18:16:02 <br-m> <rucknium> 7. CCS proposal: I2P SAMv3 support (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/650).
18:16:40 <br-m> <rucknium> This has been discussed at a few MRL meetings. More comments or questions for @jpk68:matrix.org  ?
18:17:14 <br-m> <jpk68:matrix.org> Apologies for being late, I am here :)
18:17:29 <br-m> <ofrnxmr> imo SAMv3 is a perfectly sane endeavor, but i don't support adding more money via ccs, as there is much more xmr available at this bounty https://bounties.monero.social/posts/32/140-204m-i2p-baked-into-the-monero-gui
18:17:38 <br-m> <rucknium> @jpk68:matrix.org: I think you're on time :)
18:18:23 <br-m> <jpk68:matrix.org> @ofrnxmr: Not sure if you've seen it yet, but I responded directly to this, in a comment under the CCS
18:18:27 <br-m> <ofrnxmr> @ofrnxmr: jpk responded to this concern on the ccs, but my stance remains the same: just claim the bounty
18:18:38 <br-m> <ofrnxmr> @jpk68:matrix.org: I did :)
18:19:54 <br-m> <jpk68:matrix.org> As I said, this can hardly be considered a 'bounty' sort of job, considering it includes research, testing, several different milestones (which have to do with different tasks), etc.
18:20:04 <br-m> <jpk68:matrix.org> In my opinion, at least
18:20:36 <br-m> <ofrnxmr> Other attempts were incomplete or not reviewed favorably. If you're confident that youll complete the ccs, then the bounty should more than (3x) cover your troubles
18:21:42 <br-m> <jpk68:matrix.org> Dedicating several months' worth of effort to this without any sort of structured plan with milestones wouldn't be very ideal
18:22:07 <br-m> <jpk68:matrix.org> I could do this without the CCS, but it would take far longer as I can't really just commit to a bounty like that
18:22:49 <br-m> <jpk68:matrix.org> Also, I am not the only one that is confident about the proposal, it is endorsed by I2P devs as I stated before
18:23:21 <br-m> <rucknium> And bounties aren't "reserved" for anyone. It's first-complete, first-paid, within reason. CCS has a informal exclusivity period before the CCS can be completed by anyone.
18:24:20 <br-m> <ofrnxmr> they are, like me, in favor of the endeavor. I am not in favor of adding more money to this. Everodd or the other persons who have attempted thr bounty could have opened ccs's and we'd have just beem throwing money away
18:24:20 <br-m> <rucknium> "completed by anyone" = "completed by someone who is not the original proposer"
18:24:51 <br-m> <jpk68:matrix.org> Yes, as explained in my comment, I really want to make sure the proper approach is taken with this task
18:25:16 <br-m> <jpk68:matrix.org> @ofrnxmr: I don't think anyone has attempted this with the actual plan to do this with SAM support in the daemon
18:25:27 <br-m> <jpk68:matrix.org> Besides the I2P devs' original CCS, of course
18:25:40 <br-m> <jpk68:matrix.org> Luigi suggested it could be taken up by someone else; I have taken up this offer
18:25:41 <br-m> <ofrnxmr> Essentially, what im saying is since this bounty is essentially dead, we should just earmark it for the ccs
18:26:02 <br-m> <jpk68:matrix.org> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/454#note_25233
18:26:05 <br-m> <rucknium> AFAIK, there is no precedent for "transferring" XMR from bounties to the CCS. But it could be done in theory.
18:26:10 <br-m> <ofrnxmr> Not raise more money and still leave the bounty open
18:26:46 <br-m> <jpk68:matrix.org> Just to add, StormyCloud has already offered to fund the proposal (in full)
18:27:05 <br-m> <jpk68:matrix.org> It's a registered US nonprofit which sponsors the I2P project
18:28:09 <br-m> <ofrnxmr> @jpk68:matrix.org: So why need the ccs? Just accept the funding directly
18:28:56 <br-m> <jpk68:matrix.org> Because it's a joint effort between both communities, and was directly suggested by Luigi
18:29:23 <br-m> <jpk68:matrix.org> Also, from a legal standpoint, a nonprofit sending a large amount of cryptocurrency directly to an anonymous developer would likely be extremely problematic
18:30:12 <br-m> <rucknium> You could also consider https://donate.magicgrants.org/monero/apply
18:30:22 <br-m> <rucknium> It would be nonprofit to nonprofit.
18:30:48 <br-m> <jpk68:matrix.org> That's possible, I suppose
18:30:58 <br-m> <rucknium> But MAGIC would require some KYC from you.
18:31:14 <br-m> <jpk68:matrix.org> Yes, my point exactly :)
18:31:46 <br-m> <jpk68:matrix.org> I don't really see why the CCS is a bad option here. Again, it was suggested by Luigi - has he gone back on his statement about this, or do others disagree with him?
18:31:51 <br-m> <ofrnxmr> The ccs is not a legal org or corp. Sending money to ccs is no diff than sending it to an anonymous stranger > <@jpk68:matrix.org> Also, from a legal standpoint, a nonprofit sending a large amount of cryptocurrency directly to an anonymous developer would likely be extremely problematic
18:31:52 <br-m> <jpk68:matrix.org> I'm simply just curious
18:31:59 <br-m> <rucknium> We are thirty minutes past the hour. I will end the meeting here. Discussion can continue of course.
18:32:41 <br-m> <ofrnxmr> Thanks ruck
18:33:38 <br-m> <jpk68:matrix.org> @ofrnxmr: I would have to disagree with this. StormyCloud sending money to the CCS or general fund can easily be seen as a donation to an open-source project, similar to how they themselves receive anonymous donations
18:33:43 <plowsof> well the bounty will be changed to meet the the approved scope/method from the CCS as the alternatives are seemingly privacy foot guns e.g. temporary anonymity network usage . to secure funding jpk could be promised 33% as a reviewer whilst keeping within the bounties site ideals  
18:34:11 <br-m> <jpk68:matrix.org> As the CCS/project is not a legal entity, as you have said, they do not need to do any KYC or complicated tax-related stuff
18:34:33 <plowsof> promising of funding is not used to put things on the CCS, not a good precedent and promotes schemers and grifters 
18:34:53 <plowsof> the CCS has a 100% funding rate currently 
18:35:10 <br-m> <jpk68:matrix.org> plowsof: What do you mean, as a reviewer? Reviewing others' submissions?
18:36:36 <br-m> <jpk68:matrix.org> I don't really understand your first sentence, sorry
18:36:56 <plowsof> yes ' this submission is ai slop, im continuing with my own, when im finished ill claim the entire bounty or 50~ what i had asked for from the ccs to review/improve a genuine submission'
18:38:38 <plowsof> people can send monero anon btw , also, i dont like the "luigi, has he gone back on his statement" what
18:39:21 <br-m> <jpk68:matrix.org> I'm simply asking why there's a disagreement. It's not supposed to be finger-pointing/innuendo
18:39:35 <br-m> <jpk68:matrix.org> It seems Luigi said he is in favour of a CCS being done for this, and others seem to disagree
18:40:17 <br-m> <jpk68:matrix.org> plowsof: Apologies again, I really don't understand what this means. Do you mean the CCS should be asked to review bounty submissions in this situation or something?
18:45:30 <br-m> <sgp_> @rucknium: Just echoing this. MAGIC Grants needs to know who we send money to. If that's all workable, then the proposal seems within our mission based on my skimming
18:45:46 <CjS77> Hey all, I've read through the convo on Grease -- thanks for the feedback; I think the sentiment on the value prop aligns with mine -- I'm not interested in creating a payment channel network; I 100% believe that there's enough utility in "simple" biparty channels. And as we went into the weeds on Monet, we found that even this is far from simple,
18:45:47 <CjS77> hence the quotes. On the topic of trustlessness on the KES; I have some ideas brewing, & I like working collaboratively. Is this group open to me posting (half-baked) ideas here to try  and iterate and throw out the doomed ideas? I'd still like to keep the KES *implementation* out of scope for this proposal, but if we know that trustlessness is
18:45:47 <CjS77> achievable on the KES, I would suggest that's good enough.
18:46:51 <br-m> <jeffro256> CjS77: I have posted many a half-baked idea in #monero-research-lounge:monero.social ;)
18:47:22 <br-m> <jpk68:matrix.org> @sgp_: I really appreciate your offer, thank you. I'll have to do some thinking about this, but my first thought is that it wouldn't be super feasible for me to do KYC right now
18:47:59 <br-m> <emsczkp:matrix.org> @jberman: Just to not leave this unclear, the orginal NARK prover has knowledge of the (secret) witness. this should not be confused with the accumulator witness
18:48:01 <br-m> <jpk68:matrix.org> Okay, how about this: the bounty money can go wherever, it doesn't matter to me. I will just submit the CCS and that's all.
18:48:31 <br-m> <jpk68:matrix.org> If plowsof decides I should receive the bounty, that's fine, but if not, I don't care
18:48:33 <CjS77> @jeffro256: Cool. erm, is that this room? (I'm going to have to get a proper IRC client methinks)
18:49:14 <br-m> <jpk68:matrix.org> What would be useful to me here is assurance I will be compensated, not the amount of money. The 50 XMR from the CCS is more than enough for me.
18:49:17 <br-m> <jpk68:matrix.org> Sorry for burying you messages, jeffro/CJ :)
18:50:21 <br-m> <jeffro256> CjS77: Yes, it is a room. You can join over IRC on Libera, or over Matrix on monero.social 
18:52:26 <br-m> <jberman> @emsczkp:matrix.org: Does the accumulator (AFAIU this is the one "folding" the many proofs into one folded proof) need to have knowledge of the original NARK prover's secret witness?
18:53:27 <CjS77> @jeffro256: #monero-research-lounge:monero.social is empty, so just checking that it's the right place
18:54:46 <br-m> <emsczkp:matrix.org> @jberman: it depends on your design :)
18:54:58 <br-m> <emsczkp:matrix.org> application *
18:55:20 <br-m> <emsczkp:matrix.org> that said, i'm going to rest, we can continue offline
19:09:43 <br-m> <jpk68:matrix.org> I have updated my proposal with a statement regarding the bounty funds. If anyone is willing to provide feedback on this, that would be great. Thanks :)
19:10:28 <br-m> <rucknium> CjS77: #monero-research-lounge on Libera IRC network shouldn't be empty.
19:10:58 <br-m> <rucknium> Did you add the :monero.social suffix? Don't add it for IRC.
19:20:06 <br-m> <jeffro256> @rucknium: ^^^
19:20:07 <br-m> <jeffro256> oops he left 
19:47:11 <plowsof> Rucknium ofrnxmr jpk68 do note this bounty: https://bounties.monero.social/posts/76/4-214m-research-overseer-attack-countermeasures
19:50:25 <plowsof> also note distribution of bounty funds to reviewers/testers: https://github.com/monero-project/monero/pull/8619#issuecomment-3283393492
19:52:04 <br-m> <jpk68:matrix.org> Thanks. And again, the CCS can be funded by StormyCloud without any taken from the bounty
20:00:18 <br-m> <stormycloud:i2p.net> We would like to involve the community with a CCS. Since its a community effort.