06:05:13 <m-relay> <a​ntilt:we2.ee> @rucknium:monero.social thx (sigh - its not flat!) i actually tried to compare your R code to the source :) that would be a job for an AI bot.
07:59:35 <m-relay> <a​ntilt:we2.ee> implementing a uniform dist for >DEFAULT_UNLOCK_TIME was unfortunate (a simple normal dist would have done better). Anyway, matching real world distributions is a never ending story. Want to emph that adding time-variance to the dist is a critical component in hardening DSA. Doesn't need to match O-day exactly, but it may not be static. Some entropy will do.
12:30:51 <m-relay> <a​ck-j:matrix.org> Eclipse Attacks on Monero’s Peer-to-Peer Network
12:30:52 <m-relay> <a​ck-j:matrix.org> https://www.ndss-symposium.org/wp-content/uploads/2025-95-paper.pdf
12:31:06 <m-relay> <a​ck-j:matrix.org> Rucknium: vtnerd
12:34:31 <m-relay> <s​yntheticbird:monero.social> > In addition, we have ethically reported our investigation to Monero official team.
12:34:43 <m-relay> <s​yntheticbird:monero.social> Another H1 report for the W
14:57:10 <m-relay> <m​arigi:matrix.org> Привіт усім українцям.
14:57:12 <m-relay> <m​arigi:matrix.org> Хочу запропонувати вам послугу по викупу китайських товарів з внутрішніх сайтів Китаю. І доставкою в Україну.
14:57:14 <m-relay> <m​arigi:matrix.org> Вигідна ціна ,пошук товару по фото
14:57:16 <m-relay> <m​arigi:matrix.org> Проходьте в telegram 
14:57:18 <m-relay> <m​arigi:matrix.org> https://t.me/+Ieeop6eb1D5kMDhi
16:37:44 <m-relay> <a​ntilt:we2.ee> implementing a uniform dist for >DEFAULT_UNLOCK_TIME was unfortunate. Anyway, matching real world distributions is a never ending story. Want to emph that adding time-variance to the dist is a critical component in hardening DSA. Doesn't need to match O-day exactly, but it may not be static. Some entropy will do.
21:04:18 <m-relay> <o​frnxmr:monero.social> out_peers 0 and disable_noise on tx-proxy
21:04:44 <m-relay> <o​frnxmr:monero.social> will bypass d++
21:06:04 <m-relay> <o​frnxmr:monero.social> The former will fluff to incoming conn. over clearnet. The latter will fluff to anon peers
21:20:44 <m-relay> <e​longated:matrix.org> Can consumer routers handle 1000s of out connects ?
21:26:53 <m-relay> <s​yntheticbird:monero.social> monerod alone will probably not handle more than 300 out connects on a consumer hardware
21:32:07 <m-relay> <3​21bob321:monero.social> Time to prove wrong
21:48:37 <m-relay> <o​frnxmr:monero.social> It does
21:49:03 <m-relay> <o​frnxmr:monero.social> Old study had a few nodes with 1000+ connections handling a large portion of p2p traffic
21:49:31 <m-relay> <o​frnxmr:monero.social> No, even linux itself limits to 1000 by default iirc (ulimit rules)
21:49:45 <m-relay> <j​ack_ma_blabla:matrix.org> Height: 3364232/3364232 (100.0%) on mainnet, not mining, net hash 4.00 GH/s, v16, 302(out)+66(in) connections, uptime 16d 2h 19m 24s
21:49:46 <m-relay> <j​ack_ma_blabla:matrix.org> on a 9yr old pc with ssd
21:50:59 <m-relay> <o​frnxmr:monero.social> Jack ma.. you might want to lower your outs ........ taking up ppls incoming slots and increasing bandwidth requirements for no reason
21:51:22 <m-relay> <o​frnxmr:monero.social> If anything, increase your ins
22:14:20 <m-relay> <s​yntheticbird:monero.social> I stand corrected 👍️
23:06:19 <m-relay> <k​ayabanerve:matrix.org> jberman Friendly reminder that the hardware the benches are run on shouldn't matter too much due to the use of WASM cycle counting, if that isn't solely used for a preliminary CT check yet also the evaluation itself. WASM cycles are independent of host hardware.
23:07:24 <m-relay> <k​ayabanerve:matrix.org> The consideration would be about how a low WASM cycle count may not equal a low real-world performance as they don't map 1:1 from WASM to the entire spectrum of devices used (x64, ARM, RISC-V, and WASM again).
23:08:15 <m-relay> <k​ayabanerve:matrix.org> I remember discussions on which computer to use for evaluation, such as a 3700x, and only just remembered that was one of the points of using WASM.