16:54:58 <br-m> <rbrunner7> Meeting in a bit more than 1 hour
18:00:01 <br-m> <rbrunner7> Meeting time. Hello! https://github.com/monero-project/meta/issues/1397
18:00:06 <br-m> <jpk68:matrix.org> Hello
18:00:19 <br-m> <jberman> waves
18:00:21 <br-m> <sneedlewoods_xmr:matrix.org> Hey
18:00:54 <br-m> <vtnerd> hi
18:02:26 <br-m> <rbrunner7> Alright. Let's start with the reports from last week. I continued with Polyseed, where work to implement it in the Wallet RPC Server was quite a bit more than anticipated. But nearing completion now.
18:03:24 <br-m> <sneedlewoods_xmr:matrix.org> still restore height on wallet creation in the GUI and updated wallet-rpc with rebasing and minor fixes https://github.com/monero-project/monero/compare/master...SNeedlewoods:seraphis_wallet:x_remove_wallet2_from_rpc
18:03:25 <br-m> <jpk68:matrix.org> Made some small progress on I2P SAM integration, made a bunch of random patches/fixes, worked with sneedle on adding a --wallet-dir option to simplewallet
18:03:49 <br-m> <jpk68:matrix.org> Looks like I also successfully CBOR-pilled vtnerd ;)
18:04:11 <br-m> <rbrunner7> What is "CBOR"?
18:04:31 <br-m> <jpk68:matrix.org> It's a binary serialization format, used in RPC as an alternative to JSON
18:05:04 <br-m> <rbrunner7> You mean it gets investigated as viable or not now?
18:05:14 <br-m> <jberman> FCMP++ integration audit remediation tasks (can see latest PR's here: https://github.com/j-berman/monero/pulls ), stressnet monitoring
18:05:21 <br-m> <jpk68:matrix.org> @rbrunner7: https://github.com/monero-project/monero/pull/10659
18:05:44 <br-m> <jpk68:matrix.org> It looks like the plan was originally to use MsgPack, but I made the case to use CBOR instead and it looks like that's what's happening now :)
18:06:10 <br-m> <rbrunner7> Ah, there was a need for something there for quite some time already?
18:07:08 <br-m> <rbrunner7> What's the main driver there?
18:07:59 <br-m> <jpk68:matrix.org> I should probably let vtnerd answer this
18:08:59 <br-m> <rbrunner7> I ask because I was wondering that if bytes transferred should happen the main driver, whether it would be possible to simply use HTTP traffic compression ...
18:09:36 <br-m> <rbrunner7> (An idea from some bombastic new wallet announcement recently, which is maybe not even dumb)
18:10:20 <br-m> <jpk68:matrix.org> I'm not too sure whether that would be viable, but generally, JSON will be a lot slower/larger than binary serialization
18:10:41 <br-m> <rbrunner7> Yeah, but very zip-friendly maybe
18:11:02 <br-m> <jpk68:matrix.org> CBOR is somewhat widely-adopted and is nicely standardized
18:11:07 <br-m> <rbrunner7> Just brainstorming, @vtnerd:monero.social is the comms guru :)
18:13:11 <br-m> <jpk68:matrix.org> It's also worth noting that kayabaNerve was also in support of CBOR, it was by no means my doing alone
18:13:31 <br-m> <jpk68:matrix.org> He would (obviously) know better than me
18:13:47 <br-m> <rbrunner7> I see.
18:14:27 <br-m> <rbrunner7> If we are complete with the reports, I did some brainstorming about the FCMP++ release process that I want to share.
18:15:13 <br-m> <rbrunner7> Do I get that right: The plan so far for that monumental FCMP++ plus Carrot hardfork release is to give it the new main release number 19, and fork the release branch from master?
18:15:32 <selsta> the current plan is to have a v0.19.0.0 release early, without any HF
18:15:46 <selsta> this gives us time to test the new guix build system in the wild
18:15:56 <br-m> <rbrunner7> What will that be based on?
18:16:00 <selsta> master
18:16:22 <selsta> and then have a v0.20 or maybe even v1 (doesn't matter) with FCMP++
18:16:30 <br-m> <rbrunner7> Ah, ok, then other people had the same idea that crossed my mind, and I can already rest my case :)
18:17:13 <br-m> <rbrunner7> I was thinking about all those things that accumulated on master during literally years the release branch is separate already, and possible problems if that goes live all at once together with all the really new stuff
18:17:42 <selsta> v0.19 can also contain the Polyseed changes if they are ready
18:18:00 <br-m> <rbrunner7> About what time horizon do we talk here, give or take?
18:18:07 <selsta> 2-3 months
18:18:27 <br-m> <rbrunner7> That could work if I hurry a bit
18:18:41 <selsta> I don't know what the current plan is for FCMP++, but I assume it will need at least another 6 months?
18:19:20 <selsta> see also https://github.com/monero-project/monero/issues/10682
18:19:31 <br-m> <jberman> Hopefully not, and we're currently building on top of master
18:19:53 <selsta> but would that be an issue for v0.19 release?
18:20:21 <br-m> <jberman> nope, v0.20 or v1 would be fine and relatively seamless
18:21:07 <br-m> <rbrunner7> Throwing about bootstrapping should really simplify many things
18:21:35 <br-m> <rbrunner7> No wonder the AIs byte :)
18:22:32 <br-m> <rbrunner7> By the way, that would be Polyseed in the CLI wallet and RPC server - no GUI wallet yet, didn't even start to look into that
18:23:22 <br-m> <rbrunner7> But I guess that could become a relatively painless update along the way without much fuss
18:25:21 <br-m> <sneedlewoods_xmr:matrix.org> sorry for much typing, I don't have that much to say :D
18:25:21 <br-m> <sneedlewoods_xmr:matrix.org> I imagine v19 on master will also simplify many things 
18:26:01 <br-m> <rbrunner7> No problem :) Do we have to discuss something else still today?
18:27:25 <br-m> <vtnerd> Perf. Numbers are in pr. Zmq-pub uses json which is inefficient in size and time, especially given the amount of crypto binary blogs that have to be transferred > <@rbrunner7> What's the main driver there?
18:27:52 <br-m> <vtnerd> *blobs
18:29:34 <br-m> <rbrunner7> Thanks for the hint, vtnerd, didn't scroll down enough to see them. So JSON is also less efficient to generate in the first time?
18:31:57 <br-m> <rbrunner7> Alright, let me close the meeting proper, room stays open of course ... thanks for attending everybody, read you again next week!
18:32:25 <br-m> <sneedlewoods_xmr:matrix.org> thanks everyone
18:39:10 <br-m> <vtnerd> @rbrunner7: A single 2 in/out bulletproof+ tx is like 47% smaller in size and 92% faster to encode
18:40:35 <br-m> <vtnerd> The problem with json is that every integer requires expensive conversion to decimal, compared to a byte swap + memcpy. And every crypto object requires conversion to base16 or base64 vs a memcpy
18:41:30 <br-m> <sundjr:unredacted.org> @vtnerd:monero.social will P2P use OpenSSL 3.5.0>? OpenSSL 3.5.0 introduces support for post-quantum cryptography (PQC). Hybrid handshake
18:44:06 <br-m> <vtnerd> That might be tough to require given our policy on dependencies 
18:46:35 <br-m> <sundjr:unredacted.org> @vtnerd: ack. Debian Trixie minimum
18:50:42 <br-m> <sundjr:unredacted.org> That is bad with all the spy nodes
18:52:44 <br-m> <sundjr:unredacted.org> "Using Nebula, ProbeLab's open-source network crawler, we conducted the first large-scale topological crawl of the Monero network, discovering over 29,000 nodes and successfully handshaking with more than 16,000.
18:52:44 <br-m> <sundjr:unredacted.org> The findings are stark: over 81% of reachable nodes exhibit the peer ID mismatch pattern the Monero Research Lab associates with surveillance infrastructure while every flagged node tracing back to a single provider: Spruce Creek Networks LLC"
18:54:21 <selsta> I don't think P2P SSL would help against these spy nodes 
18:55:30 <selsta> it's against DPI and not spy nodes that participate in the network
18:55:51 <selsta> see https://github.com/monero-project/monero/pull/8028/changes
18:56:24 <br-m> <sundjr:unredacted.org> The whole picture. Spynodes, ISP DPI analytics on the few honest nodes left
18:58:35 <br-m> <sundjr:unredacted.org> Malicious tor exit nodes
19:21:30 <br-m> <sundjr:unredacted.org> @jberman: A smooth first audit. Will Trail of Bits finish the part they had no time for?
19:26:08 <br-m> <syntheticbird> OpenSSL is a disease and monero should give up on it
19:40:00 <br-m> <jpk68:matrix.org> Noise protocol doesn't natively support post-quantum, so you would have to resort to using non-standardized extensions for it
19:40:22 <br-m> <jberman> @sundjr:unredacted.org: we're working on best path forward on that front internally right now
19:48:12 <br-m> <sundjr:unredacted.org> Ok
20:08:34 <br-m> <syntheticbird> @jpk68:matrix.org giving up on OpenSSL do not mean giving up on TLS
20:09:14 <br-m> <jpk68:matrix.org> What then? LibreSSL? rustls?
20:09:23 <br-m> <jpk68:matrix.org> We already use OpenSSL for a bunch of other stuff
20:09:41 <br-m> <jpk68:matrix.org> SSL/TLS sucks regardless
20:13:55 <br-m> <syntheticbird> @jpk68:matrix.org: wolfssl, mbedtls, aws-lc (tho this one is low level)
20:14:18 <br-m> <syntheticbird> @jpk68:matrix.org: agree we shouldn't be ashamed of designing new communication protocol
20:15:36 <br-m> <syntheticbird> no offense to your work @vtnerd:monero.social of course, you choosed TLS for the maintenance and viability of its approach to integrate into monero. I just want to express my disdain on the Monero Project relying on one of the worst cryptographic library in existence.
20:19:32 <br-m> <jpk68:matrix.org> @syntheticbird: If you want PQ encryption for P2P traffic, you can't even use a framework like Noise because it doesn't support that. The only good option is making our own entirely from scratch
20:20:54 <br-m> <boog900> Fwiw Bitcoin went with a custom protocol for encryption
20:21:53 <br-m> <jpk68:matrix.org> I don't think OpenSSL is that big of a deal, and it can't hurt to be pragmatic about it (for now, at least). Users have been waiting far too long for this already, and having to design/pioneer a new protocol and then get it audited is just asking to wait even longer
20:22:22 <br-m> <vtnerd> Just use ssl
20:22:29 <br-m> <syntheticbird> I mean I consider the p2p encryption topic to be entirely independent of FCMP++
20:22:54 <br-m> <jpk68:matrix.org> BIP 324 is also not even post-quantum, and IMO putting out P2P encryption support that is only secure in a classical sense is surely a mistake at this point.
20:23:23 <br-m> <jpk68:matrix.org> SSL (or at least the version of it we're using) is less big of a deal in that regard, because it can be upgraded quite easily