09:15:36 > <@ofrnxmr:xmr.mx> you mean, like hackerone bounties? 09:15:36 I guess this would be sort of similar, but not entirely. More leaning towards outsourcing in a more official capacity audits of older parts of Monero code, hopefully on a consistent basis if everything goes well. Or yes, developing tools for fuzzing. I realize CCS requests are open and technically anyone can create one, but th [... too long, see https://mrelay.p2pool.observer/e/jO6DqJ4LbTNPSjU1 ] 09:16:05 > older parts of Monero code 09:16:17 infinite money generator 09:18:51 @syntheticbird: It is significantly better than the infinite money generator of an inflation bug from code that hasn't had any official review in years. 09:20:06 Again, not my forte. You probably know better than me. It just seems like something could come out of this that ends up improving overall security. 14:10:36 @absinthium:4d2.org: An inflation bug is not going to be hiding in old parts of the code 14:11:54 This is exactly why the LLM-assisted audits from sech1 et al. focus on src/ringct/ (for the most part) 14:32:24 @jpk68:matrix.org: They could be anywhere, a lot of the new stuff has been audited where a lot of the old has not 14:33:27 @boog900: "battle-tested" 14:35:45 @boog900: What I mean is, you're not going to find an inflation bug in epee HTTP server 14:36:16 ah sure 15:30:59

@absinthium:4d2.org: The MAGIC Monero Fund has been running constant security audits of monerod and other software in the monero ecosystem with good results. We will continue doing this as models get better. No need to raise dedicated funds 15:31:52

But if you’re inclined to donate to our separate fuzzing project, that would be appreciated 16:24:24 https://eprint.iacr.org/2026/1591 18:30:01 I'm trying to understand tx relay logs under tx-relay v1 and v2. 18:30:12 To record the txs received from a peer in v1, I first notice 18:30:12 [IP:PORT INC/OUT] Received NOTIFY_NEW_TRANSACTIONS (N txes) 18:30:12 Then I get each tx after the NOTIFY, minding the thread, e.g. [P2P3], of the log messages: 18:30:12 [IP:PORT INC/OUT] Including tx 18:30:32 The v1 function (https://github.com/monero-project/monero/blob/c48c51ddd9202019ffcaf1ee8ff9456fa1c673ad/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L901) looks like it sends the same info to the log file regardless of whether the inbound tx(s) is a stem phase or a fluff phase tx(s). Is that correct? 18:30:57 Under v2, fluff-phase txs write this to the log: 18:30:57 [IP:PORT INC/OUT] Received NOTIFY_TX_POOL_HASH (N txes) 18:30:57 If I already have a given tx, this goes to the log: 18:30:57 No requests for tx 18:30:57 If I don't have the tx, this is written to the log:[... more lines follow, see https://mrelay.p2pool.observer/e/7tf1t54LOVFSNjB1 ] 18:31:09 Stem-phase tx under v2 are treated the same as under v1. There is a NOTIFY_NEW_TRANSACTIONS for them. 18:31:16 Anything wrong with my understanding? 20:24:22 @kayabanerve:matrix.org: is the plan to keep plain Blake2b (without the Monero personalization string, as done for https://github.com/monero-oxide/monero-oxide/pull/182) for helioselene crate/curves and others? It is used on hash_to_F https://github.com/monero-oxide/monero-oxide/blob/fcmp%2B%2B/crypto/helioselene/src/ciphersuite.rs#L32 20:24:22 also used on generalized-bulletproofs Transcript/VerifierTranscript Challenge https://github.com/monero-oxide/monero-oxide/blob/fcmp%2B%2B/crypto/generalized-bulletproofs/src/transcript.rs#L70 20:24:22 also used on fcmps folder https://github.com/monero-oxide/monero-oxide/blob/fcmp%2B%2B/crypto/fcmps/src/lib.rs#L310