<spirobel:kernal.eu> > <@rbrunner7> Ok, might take some work for me to read into everything, but I am optimistic that I will find a good. Man, it's high time we solve Polyseed once and for all as core part of the regular Monero code ...

<spirobel:kernal.eu> another thing is binary cache files. there was a change in bun where they switched from a binary .lock to a json .lock with the reason that there is no point in having it be binary. Its hard to inspect and understand for users and there is no solid reason from a performance standpoint to keep it binary. I saw some cache files [... too long, see mrelay.p2pool.observer/e/qvy0s4ELd2llbEZK ]

<spirobel:kernal.eu> for seedphrase i used bip39. none of the other key derivation standards, like slip10, they seem bloated and derivation paths look confusing and tell the user nothing by directly looking at them.

<spirobel:kernal.eu> xcancel.com/spirobel/status/2053101870768697645 did a short write up there... for me even with cache files with thousands of regtest outputs the cache files never grow as large.... i think it might have to do with anchors / reorg detection that let to large cache files on wallet2.cpp based wallets ...

<spirobel:kernal.eu> in the future it may be best to get rid of the whole syncing issue entirely: xcancel.com/spirobel/status/2020397980818264502