<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 mrelay.p2pool.observer/e/xYDDqNIKNnpuOGlK ]

wen web wallet.

<elongated:matrix.org> dukenukem: Never

<spirobel:kernal.eu> soon. made a shitload of progess last week

<spirobel:kernal.eu> mrelay.p2pool.observer/m/kernal.eu/IGPoKRomFbNBbsNUvHBhffDO.png (image.png)

<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

<spirobel:kernal.eu> it seems to store all block hashes ... + a dequeue ... unclear why that is necessary ... to be persisted

Block hashes are used to detect and process reorgs. IIRC it's only the last N though.

<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

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

<elongated:matrix.org> Browser extension ? > <@spirobel:kernal.eu> soon. made a shitload of progess last week

<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 😀👍️

<spirobel:kernal.eu> mrelay.p2pool.observer/m/kernal.eu/FeOZUgUwmApicbFBYCPpOUsm.png (image.png)

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

^ like monero was already attacked in the past

elongated why never? :(

spirobel what difference are you talking about? I never talk to your bitchass.

precisely because of bs comments like these... "I am happy to support users with limited digital literacy to use Monero as well 😀👍️

"

<basses:matrix.org> keymaterial.net/2025/12/13/a-very-u…-security-of-various-pqc-algorithms

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

> <spirobel:kernal.eu> or maybe the culprit is something else

I was decoding wallet caches the other day and yeah, most of the size is block hashes

<elongated:matrix.org> Web wallet like mymonero, makes phishing attacks easier > <dukenukem> elongated why never? :(

<elongated:matrix.org> Extensions are fine

nioc: ah, ok. who are you and where are my aunts?

elongated right, right. roger.

<basses:matrix.org> @elongated:matrix.org: anything in browser will have a much higher attack surface than desktop apps.

<basses:matrix.org> johndcook.com/blog/2025/12/08/dandelion

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