05:37:08 <br-m> <thomasbuilds:matrix.org> trying to create an account on https://repo.getmonero.org
05:37:08 <br-m> <thomasbuilds:matrix.org> I get
05:37:08 <br-m> <thomasbuilds:matrix.org> > Your account is pending approval from your GitLab administrator and hence blocked. Please contact your GitLab administrator if you think this is an error.
08:43:05 <tobtoht> Is the polyseed library (in the context of #10765) understood to be a "contribution to the project source code"?
08:43:30 <tobtoht> From the CoC: All contributions to the project source code ("patches") MUST use the same license as the project.
08:43:39 <tobtoht> Polyseed is licensed under the LGPLv3, as is mx25519.
08:44:04 <tobtoht> There is precedent that we do not allow GPL code. RandomX was relicensed from GPL to BSD-3: https://github.com/tevador/RandomX/commits/master/LICENSE
08:44:16 <tobtoht> tevador was aware of this incompatibility: "It's been updated to the 3-clause BSD license, which should be compatible with Monero."
08:44:24 <tobtoht> https://github.com/monero-project/monero/pull/5549#issuecomment-493747266
09:40:08 <tobtoht> (I checked all rust crates that are added in 10359 and all of them use permissive licenses)
12:10:34 <sech1> Is the next point release v0.19.0.0? Should we make release PRs to release-v0.19 branch now?
12:11:37 <br-m> <ofrnxmr:xmr.mx> the next is 18.5.3, then 19
12:11:41 <tobtoht> against master until v0.18.5.3 is out
12:12:41 <br-m> <ofrnxmr:xmr.mx> to echo selsta and tob, dont open prs against 0.19 until after 18.5.3 is tagged
12:14:51 <sech1> so master and release-v0.18. I guess release-v0.19 will get merges from master at some point?
12:15:31 <br-m> <ofrnxmr:xmr.mx> yeah, theres a backport pr that tob is cherrypicking master commits onto 
12:15:45 <br-m> <ofrnxmr:xmr.mx> https://github.com/monero-project/monero/pull/11015
16:28:07 <selsta> .merge+ 10997 11004
16:28:07 <xmr-pr> Added
18:13:21 <br-m> <jpk68:matrix.org> https://github.com/monero-project/monero-gui/issues/4517#issuecomment-5195075835
18:13:39 <br-m> <jpk68:matrix.org> ^ Regarding THP support
19:30:50 <xmr-pr> jpk68 opened pull request #11051: rpc: make thread count configurable, use better default value
19:30:51 <xmr-pr> > https://github.com/monero-project/monero/pull/11051
20:15:50 <xmr-pr> jpk68 opened issue #11052: `TCP_NODELAY` is disabled for RPC connections
20:15:51 <xmr-pr> > https://github.com/monero-project/monero/issues/11052
20:30:50 <xmr-pr> jpk68 opened pull request #11053: epee: disable tcp_nodelay for rpc connections
20:30:51 <xmr-pr> > https://github.com/monero-project/monero/pull/11053
21:02:48 <br-m> <jpk68:matrix.org> Continuing a discussion from the Cuprate room: a lot of performance gains for wallet sync could seemingly be made without removing the recursive mutex in blockchain.h
21:03:39 <br-m> <jpk68:matrix.org> The easiest route would likely be to shrink the critical section on hot read paths
21:05:40 <br-m> <jpk68:matrix.org> As in, some parts can be restructured to release m_blockchain_lock right after the read transaction is opened, and then do the get_blocks_from call from outside the lock
21:08:09 <br-m> <jpk68:matrix.org> You could also bypass the locks entirely for pure-DB reads (relying on the MVCC in LMDB itself)
23:20:08 <br-m> <@TheFuzzStone:matrix.org> https://xcancel.com/callebtc/status/2085024458012586286
23:20:08 <br-m> <@TheFuzzStone:matrix.org> Did you see that? Does the Monero developer community have any plans to do something like this?
23:21:17 <br-m> <jpk68:matrix.org> People have been doing codebase audits, LLM-assisted and otherwise, for quite a while
23:21:31 <br-m> <slowbeardigger:matrix.org> yeah i think that been announced
23:21:36 <br-m> <slowbeardigger:matrix.org> Even heavy use of AI
23:21:42 <br-m> <slowbeardigger:matrix.org> if they don’t, bad actors will
23:21:47 <br-m> <slowbeardigger:matrix.org> so...
23:22:59 <br-m> <ofrnxmr:xmr.mx> mrl started doing it publicly weeks ago, but weve been doing it privately for months
23:33:08 <br-m> <@TheFuzzStone:matrix.org> @ofrnxmr:xmr.mx: Which model/-s?
23:33:32 <br-m> <slowbeardigger:matrix.org> wasnt it opus 4.8? or tht was long before?
23:34:16 <br-m> <jpk68:matrix.org> A couple people (like sech1) got access to Fable from MAGIC Grants
23:34:24 <br-m> <jpk68:matrix.org> Not sure if it was actually effective, though
23:35:11 <br-m> <ofrnxmr:xmr.mx> pretty sure he already had it, he just got a discount thru magic
23:35:23 <br-m> <ofrnxmr:xmr.mx> but fable guard rails are a little heavy handed
23:36:03 <br-m> <slowbeardigger:matrix.org> @ofrnxmr:xmr.mx: it is unusable
23:36:07 <br-m> <ofrnxmr:xmr.mx> opus, codex, chapgpt, im sure someone is using kimi
23:36:08 <br-m> <@TheFuzzStone:matrix.org> @ofrnxmr:xmr.mx: accpet Kimi K3 as the savior
23:36:22 <br-m> <ofrnxmr:xmr.mx> but a lot of the readteaming is done in private
23:36:25 <br-m> <slowbeardigger:matrix.org> Better get creative
23:37:00 <br-m> <ofrnxmr:xmr.mx> i use ofrnAI, its not as good.
23:38:15 <br-m> <ofrnxmr:xmr.mx> i dont want to drag on here, but it also hallucinates vulns a lot > <@ofrnxmr:xmr.mx> but fable guard rails are a little heavy handed
23:38:51 <br-m> <slowbeardigger:matrix.org> @ofrnxmr:xmr.mx: it is horrible/unusable, i’ve found way more valid shit with Grok
23:38:58 <br-m> <ofrnxmr:xmr.mx> this is a better discussion for monero-research-lounge
23:39:28 <br-m> <ofrnxmr:xmr.mx> i cant tag the room for some reason
23:39:39 <br-m> <ofrnxmr:xmr.mx> #monero-research-lounge:monero.social
23:40:08 <br-m> <slowbeardigger:matrix.org> ty
23:40:20 <br-m> <ofrnxmr:xmr.mx> #monero-research-lounge:monero.social
23:41:00 <br-m> <@TheFuzzStone:matrix.org> I managed to find some issues with the Cake, Monfluo, and Cashu.me wallets using Kimi K3.
23:41:00 <br-m> <@TheFuzzStone:matrix.org> I sent a disclosure to everyone. From here on out, it's up to the developers. I noticed that Cashu.me has fixed some of the issues I found.
23:41:00 <br-m> <@TheFuzzStone:matrix.org> Is there anything I can do to help the team currently conducting the audit? Is there a chat group for coordinating efforts?
23:41:24 <br-m> <ofrnxmr:xmr.mx> the one linked above
23:41:53 <br-m> <jpk68:matrix.org> @TheFuzzStone:matrix.org: It might be worth checking if the issues are actually worth privately disclosing before doing so :)
23:42:07 <br-m> <jpk68:matrix.org> Many issues that aren't critical are better opened as an issue or patch
23:42:11 <br-m> <ofrnxmr:xmr.mx> but the audits are done by contracted parties, they arent public
23:42:30 <br-m> <jpk68:matrix.org> Thank you for your efforts, though @TheFuzzStone:matrix.org
23:42:59 <br-m> <ofrnxmr:xmr.mx> if youre talking about AI auditing, yes, you can discuss etc in the room above. just remember that everything is public and logged
23:43:25 <br-m> <@TheFuzzStone:matrix.org> @jpk68:matrix.org: I tested the most critical/high issues manually on an Android emulator to see the problems for myself.
23:45:02 <br-m> <@TheFuzzStone:matrix.org> @ofrnxmr:xmr.mx: But will they eventually be made public, or what are the terms?
23:46:14 <br-m> <slowbeardigger:matrix.org> i might start auditing by myself too
23:46:14 <br-m> <slowbeardigger:matrix.org> i feel confident now
23:46:16 <br-m> <ofrnxmr:xmr.mx> yes, they are made public when completed