<r​ucknium:monero.social> I did some testing for this question about the GUI's node pruning behavior: libera.monerologs.net/monero-gui/20240401

<r​ucknium:monero.social> I used latest GUI release on Linux. I changed the name of the .bitmonero directory and the monero-core.conf file between tests.

<r​ucknium:monero.social> When I choose "Simple mode (bootstrap)", there is no screen for configuring the daemon. The monero-core.conf file has pruneBlockchain=true once the wallet is set up. So far, so good.

<r​ucknium:monero.social> When I choose "Advanced mode", the "Daemon settings" screen has a "Prune blockchain" checkbox. It is unchecked by default. When I check it, pruneBlockchain in monero-core.conf changes from false to true.

<r​ucknium:monero.social> If we wanted to encourage pruning by default more, the "Advanced mode" checkbox for pruning could be checked by default.

hmm I thought it is enabled by default

or maybe not will confirm it

<r​ucknium:monero.social> Feel free to double check my tests :)

yes seems I misremembered

but now I'm confused how the current code works

rucknium: we start monerod with the --prune-blockchain flag, how did you find it written into a moneor-core.conf file?

ok seems monero-core.conf is used for persistentsettings, make sense

<r​ucknium:monero.social> I noticed that the GUI kept the simple/bootstrap/advanced mode even if I changed the .bitmonero directory name and changed wallet files. So I looked for a config file and found monero-core.conf

monero-project/monero-gui #4320 that should work but not tested yet

<r​ucknium:monero.social> Thank you :)

<r​ucknium:monero.social> I am writing about different options for increasing the ring size and/or fee to defeat black marble flooding. "Encourage pruning" is one of the options that would reduce the storage impact of larger rings. So now I have something specific to mention about the software instead of just "make memes saying it's ok to prune".

I'm skeptical of inreasing ring size before we fixed performance issues in monerod

we already have issues with nodes falling behind, nodes going out of memory during high tx volume

this is just going to get worse if this isn't fixed before we increase ring sizes

<r​ucknium:monero.social> That is an issue. Do you think it will have to be fixed before FCMP?

I don't know. We need someone to investiage it, xFFFC0000 worked on some lock changes but it's unclear if that improves things

it's difficult to reproduce in the first place

.merge+ 4321

Added