<absinthium:4d2.org> > <@ofrnxmr:xmr.mx> you mean, like hackerone bounties?

<absinthium:4d2.org> 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 mrelay.p2pool.observer/e/jO6DqJ4LbTNPSjU1 ]

<syntheticbird> > older parts of Monero code

<syntheticbird> infinite money generator

<absinthium:4d2.org> @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.

<absinthium:4d2.org> 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.

<jpk68:matrix.org> @absinthium:4d2.org: An inflation bug is not going to be hiding in old parts of the code

<jpk68:matrix.org> This is exactly why the LLM-assisted audits from sech1 et al. focus on src/ringct/ (for the most part)

<boog900> @jpk68:matrix.org: They could be anywhere, a lot of the new stuff has been audited where a lot of the old has not

<syntheticbird> @boog900: "battle-tested"

<jpk68:matrix.org> @boog900: What I mean is, you're not going to find an inflation bug in epee HTTP server

<boog900> ah sure

<ack-j:matrix.org> @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

<ack-j:matrix.org> But if you’re inclined to donate to our separate fuzzing project, that would be appreciated

<sgp_> eprint.iacr.org/2026/1591

<rucknium> I'm trying to understand tx relay logs under tx-relay v1 and v2.

<rucknium> To record the txs received from a peer in v1, I first notice

<rucknium> [IP:PORT INC/OUT] Received NOTIFY_NEW_TRANSACTIONS (N txes)

<rucknium> Then I get each tx after the NOTIFY, minding the thread, e.g. [P2P3], of the log messages:

<rucknium> [IP:PORT INC/OUT] Including tx <TXID>

<rucknium> The v1 function (github.com/monero-project/monero/bl…ryptonote_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?

<rucknium> Under v2, fluff-phase txs write this to the log:

<rucknium> [IP:PORT INC/OUT] Received NOTIFY_TX_POOL_HASH (N txes)

<rucknium> If I already have a given tx, this goes to the log:

<rucknium> No requests for tx <TXID>

<rucknium> If I don't have the tx, this is written to the log:[... more lines follow, see mrelay.p2pool.observer/e/7tf1t54LOVFSNjB1 ]

<rucknium> Stem-phase tx under v2 are treated the same as under v1. There is a NOTIFY_NEW_TRANSACTIONS for them.

<rucknium> Anything wrong with my understanding?

@kayabanerve:matrix.org: is the plan to keep plain Blake2b (without the Monero personalization string, as done for monero-oxide/monero-oxide #182) for helioselene crate/curves and others? It is used on hash_to_F github.com/monero-oxide/monero-oxid…/helioselene/src/ciphersuite.rs#L32

also used on generalized-bulletproofs Transcript/VerifierTranscript Challenge github.com/monero-oxide/monero-oxid…-bulletproofs/src/transcript.rs#L70

also used on fcmps folder github.com/monero-oxide/monero-oxid…%2B%2B/crypto/fcmps/src/lib.rs#L310