06:34:17
spirobel:kernal.eu:
Arctic has a point with the concern about temporary not being temporary. Blocksize shouldnt even be a constant that is defined on its own. You want to define constants in a way so you dont have data duplication. Blocksize is downstream from LEVIN_DEFAULT_MAX_PACKET_SIZE so it should be defined in relation to that value. That [... too long, see https://mrelay.p2pool.observer/e/xYDDqNIKNnpuOGlK ]
08:08:51
dukenukem:
wen web wallet.
08:18:31
elongated:matrix.org:
dukenukem: Never
09:08:13
spirobel:kernal.eu:
soon. made a shitload of progess last week
09:11:22
spirobel:kernal.eu:
https://mrelay.p2pool.observer/m/kernal.eu/IGPoKRomFbNBbsNUvHBhffDO.png (image.png)
09:13:03
spirobel:kernal.eu:
btw i pondered something ... why do wallet2.cpp cache files get so big ... i noticed 47mb on a testwallet on stagenet with a dozen transactions
09:14:07
spirobel:kernal.eu:
it seems to store all block hashes ... + a dequeue ... unclear why that is necessary ... to be persisted
09:18:41
moneromoooo:
Block hashes are used to detect and process reorgs. IIRC it's only the last N though.
09:19:41
spirobel:kernal.eu:
moneromoooo: yeah it should be. but it seems it doesn't clean up older ones and that is why we end up at 47 mb
09:21:41
spirobel:kernal.eu:
or maybe the culprit is something else. that is the only thing i could think of. I looked at the cache debug view in featherwallet and also didnt see that many blockhashes that would justify 47mb (but still more than would be necessary to detect a reorg)
09:52:02
elongated:matrix.org:
Browser extension ? > <@spirobel:kernal.eu> soon. made a shitload of progess last week
12:58:28
spirobel:kernal.eu:
@elongated:matrix.org: i explained the difference to him before, but it seems like it was in vain. Anyway I am glad rotten is hyped too and I am happy to support users with limited digital literacy to use Monero as well 😀👍️
12:58:33
spirobel:kernal.eu:
https://mrelay.p2pool.observer/m/kernal.eu/FeOZUgUwmApicbFBYCPpOUsm.png (image.png)
15:28:34
ack-j:matrix.org:
Regarding block size limits: One thing to consider is that an attacker does not need to sustain large blocks indefinitely. Once a well resources adversary reach large enough blocks for a moment, nodes will crash or fall behind and there is limited community recourse besides optimizing the daemon or emergency forking.
15:36:44
DataHoarder:
^ like monero was already attacked in the past
15:59:52
dukenukem:
elongated why never? :(
16:00:47
dukenukem:
spirobel what difference are you talking about? I never talk to your bitchass.
16:01:03
dukenukem:
precisely because of bs comments like these... "I am happy to support users with limited digital literacy to use Monero as well 😀👍️
16:01:06
dukenukem:
"
17:07:18
basses:matrix.org:
https://keymaterial.net/2025/12/13/a-very-unscientific-guide-to-the-security-of-various-pqc-algorithms/
17:16:28
nioc:
dukenukem: they are talking about the difference between a web wallet which is not being worked on and a browser extension which is what is being worked on. So yeah web wallet = never
17:20:43
DataHoarder:
> <spirobel:kernal.eu> or maybe the culprit is something else
17:20:44
DataHoarder:
I was decoding wallet caches the other day and yeah, most of the size is block hashes
17:32:18
elongated:matrix.org:
Web wallet like mymonero, makes phishing attacks easier > <dukenukem> elongated why never? :(
17:32:18
elongated:matrix.org:
Extensions are fine
17:42:14
dukenukem:
nioc: ah, ok. who are you and where are my aunts?
17:42:39
dukenukem:
elongated right, right. roger.
18:20:38
basses:matrix.org:
@elongated:matrix.org: anything in browser will have a much higher attack surface than desktop apps.
18:21:54
basses:matrix.org:
https://www.johndcook.com/blog/2025/12/08/dandelion/
19:48:04
kayabanerve:matrix.org:
Block size _shouldn't_ be downstream from the packet size though, and the packet size probably _should_ be decreased because it's laughably large now. Decoupling them will improve the block size and safety of the P2P layer.