<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.

<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.

<a​ck-j:matrix.org> Eclipse Attacks on Monero’s Peer-to-Peer Network

<a​ck-j:matrix.org> ndss-symposium.org/wp-content/uploads/2025-95-paper.pdf

<a​ck-j:matrix.org> Rucknium: vtnerd

<s​yntheticbird:monero.social> > In addition, we have ethically reported our investigation to Monero official team.

<s​yntheticbird:monero.social> Another H1 report for the W

<m​arigi:matrix.org> Привіт усім українцям.

<m​arigi:matrix.org> Хочу запропонувати вам послугу по викупу китайських товарів з внутрішніх сайтів Китаю. І доставкою в Україну.

<m​arigi:matrix.org> Вигідна ціна ,пошук товару по фото

<m​arigi:matrix.org> Проходьте в telegram

<m​arigi:matrix.org> t.me/+Ieeop6eb1D5kMDhi

<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.

<o​frnxmr:monero.social> out_peers 0 and disable_noise on tx-proxy

<o​frnxmr:monero.social> will bypass d++

<o​frnxmr:monero.social> The former will fluff to incoming conn. over clearnet. The latter will fluff to anon peers

<e​longated:matrix.org> Can consumer routers handle 1000s of out connects ?

<s​yntheticbird:monero.social> monerod alone will probably not handle more than 300 out connects on a consumer hardware

<3​21bob321:monero.social> Time to prove wrong

<o​frnxmr:monero.social> It does

<o​frnxmr:monero.social> Old study had a few nodes with 1000+ connections handling a large portion of p2p traffic

<o​frnxmr:monero.social> No, even linux itself limits to 1000 by default iirc (ulimit rules)

<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

<j​ack_ma_blabla:matrix.org> on a 9yr old pc with ssd

<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

<o​frnxmr:monero.social> If anything, increase your ins

<s​yntheticbird:monero.social> I stand corrected 👍️

<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.

<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).

<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.