07:38:12 <sech1> gpt 5.5 codex (xhigh) audit: https://github.com/SChernykh/ringct-bulletproofs-plus-review-claude/blob/main/RINGCT_SECURITY_REVIEW_gpt_5.5_xhigh.md
07:38:21 <sech1> didn't find anything as well
07:38:36 <sech1> only a few issues not related to ringct
08:02:22 <br-m> <yushanren:matrix.org> You can ask codex to generate harness for auditing monero, then use it to audit monero.
08:29:08 <br-m> <quicksilver:4d2.org> > <@jberman> I had it look for mathematical flaws in the CLSAG and BP+ papers (since that has happened in the past e.g. Zcash's other hidden inflation vulnerability in Sprout). Then I had it go through Monero's code starting from handle_block_to_main_chain, and dig deep into every section, with emphasis on crypto functio [... too long, see https://mrelay.p2pool.observer/e/773j_ooLTmhmUVZ6 ]
08:29:08 <br-m> <quicksilver:4d2.org> > told it to assume there was a flaw somewhere and find it.
08:29:08 <br-m> <quicksilver:4d2.org> I like this idea. ragebaiting the ai
08:36:09 <sech1> codex xhigh is very heavy on token, I had to buy extra credits for 40 euro just to finish that one audit. So not going to touch it again anytime soon
17:03:50 <br-m> <kiersten5821:matrix.org> are you using the pro plan? credits are not worth it
17:04:16 <br-m> <kiersten5821:matrix.org> credits are charged at roughly the api cost, the plan is charged at 1/20th the api cost
19:57:37 <br-m> <handpickencounter:matrix.org> Will the FCMP++ upgrade make Monero's privacy zero-information (information theoretically secure; proof against CRQC) just how TornadoCash and zcash and a generic centralized blind signature scheme are right now (CRQC allows coin forging but not privacy violation)?
20:24:32 <jeffro256> Yes iff the adversary knows only on-chain information. No if the adversary knows your Monero address 
20:26:48 <br-m> <handpickencounter:matrix.org> jeffro256: but wouldn't that be resolved by having a secondary wallet where only you know the address? and if so, why not make it automatic that every transaction sends to a private wallet-only address?
20:28:09 <br-m> <handpickencounter:matrix.org> I suppose a wallet will have this functionality built in? current;y sweeping hurts your privacy but with FCMP++ it ought not to?
20:29:42 <jeffro256> That's essentially what the new key hierarchy in the CARROT paper does but with better performance 
20:33:19 <br-m> <handpickencounter:matrix.org> what are the implications of knowing the Monero address? assuming an adversary has a CRQC what will they know about that address?
20:35:03 <jeffro256> They can extract the private view key, and sometimes calculate key images of incoming enotes 
20:36:45 <br-m> <handpickencounter:matrix.org> but if you then immediately send coin from that address to one that never becomes known, there is no longer any information (zero knowledge) about where the coins went?
20:38:15 <jeffro256> Yes 
20:39:13 <jeffro256> There may be information that the coins were spent in a specific input of the churn tx, but the trail goes cold after that 
20:45:45 <br-m> <handpickencounter:matrix.org> so if two addresses are known, a CRQC will be able to determine if one sent coin to the other. but if there is just one intermediary between them no determination can be made? no probability estimate at all (anonymity set & timing information notwithstanding)?
20:48:13 <jeffro256> There is still amount information b/c the QA can view amounts on either side, but yeah no direct or indirect transaction graph information 
20:49:24 <jeffro256> But if you receive 93734484.34639043 XMR, sweep that to an intermediate wallet, then sweep that to your destination, the QA can see 93734484.34639043 XMR - fees show up on the other side and make an educated guess 
20:50:04 <jeffro256> It's the same mistakes hackers make when they dump 3 mil into XMR then wait 30 minutes and try to sell it all for fiat 
21:57:40 <br-m> <handpickencounter:matrix.org> but that's all after FCMP++. a QA will be able to break privacy of all monero transactions up to now right?
22:11:19 <jeffro256> They will be able to see the transaction graph deterministically, but not see amounts 
22:13:29 <jeffro256> This GH issue may interest you: https://github.com/monero-project/research-lab/issues/151
22:13:50 <jeffro256> It's also been an agenda topic in MRL meetings the last several weeks 
22:44:36 <br-m> <handpickencounter:matrix.org> jeffro256: this mentions PQ public key encryption scheme. is the transaction graph in FCMP++ zero knowledge or just PQC?
22:45:34 <br-m> <jpk68:matrix.org> FCMP++ is not post-quantum; it depends on what you consider "zero-knowledge"
22:45:54 <br-m> <handpickencounter:matrix.org> for example, RSA blind signatures (unwieldy and unworkable in a blockchain setting) are zero knowledge; no amount of breakthrough will also you to link transactions.
22:46:46 <br-m> <jpk68:matrix.org> RingCT is arguably a zero-knowledge proof already. The link above is general PQ research/discussion, which FCMP++ is somewhat unrelated to
22:47:21 <br-m> <jpk68:matrix.org> The FCMP++ hardfork will ship with Carrot, though, which is a new key hierarchy/addressing protocol that has some PQ forward-secrecy benefits
22:48:19 <br-m> <handpickencounter:matrix.org> also afaik zcash/tornado is also zero knowledge, they use nullifiers. so the only way to link transactions would be to crack cryptographic hashes.
22:50:00 <br-m> <jpk68:matrix.org> Monero uses key images as nullifiers for double-spend protection, FWIW