<p​laiwanone:matrix.org> GM

<p​laiwanone:matrix.org> Holy

<p​laiwanone:matrix.org> In

I set and run monerod to be a pruned node, but after reaching 15 GiB, the db stopped growing: is it OK or guide is wrong on db size?

The pruned db should be about 90 GB, very roughly. If it's not growing, you might need to wait some more, it might be slow (it grows in spurts), or might not be finding honest peers above your current height (can happen if all your slots get snagged by asshole nodes), of you might be out of disk space, or there might be a bug.

To see if it's still going correctly at least, restart with --log-level 1. If you see errors, post them to paste.debian.com.

Oh: Before doing that, post the output line from "status" in the monerod console.

I get these 2 lines:

2025-04-14 16:59:41.714 I Monero 'Fluorine Fermi' (v0.18.4.0-release)

Height: 1423028/3390013 (42.0%) on mainnet, not mining, net hash 261.63 MH/s, v6, 24(out)+7(in) connections, uptime 0d 2h 15m 47s

[I recently restarted it exactly for adding 1 on log-level]

[I added the DNS blocklist too and some other options suggested in docs. guide]

Check in half an hour whether the first number in 1423028/3390013 went up. If so, you're good, it's just slow.

If your chain is on a spinning platter disk, that is 99% certain why.

The second number is unimportant, but will almost certainly have increased by a dozen or so.

they are the same, both numbers

moneromooo: I uploaded monero.log --> cloud.disroot.org/s/7t3YEPtd25FSAJ7 (~54 MiB)

[log-level=1 is very more verbose than 0 :)]

it's full of lines like this:

2025-04-14 18:10:29.832 [P2P1] INFO blockchain.db.lmdb src/blockchain_d

b/lmdb/db_lmdb.cpp:86 Error adding spent key image to db transaction: MDB_CORR

UPTED: Located page was wrong type

Then your db is shot, and needs deleting. It cannot sync further due to this. Which platform are you on ?

linux 64bit

how to prevent it to re-happen?

before I had not the dns block list enabled, bad peers could do this?

what to delete? all? just lmdb/*? just data.mdb?

data.mdb is all you need to delete.

done and restarted

<o​frnxmr:xmr.mx> Caused by (usually) system crashes or power failures. After fully synced, s|switch to `--db-sync-mode=safe:sync` to help prevent further crashes

<o​frnxmr:xmr.mx> Further corruptions*

sys nor monerod never crashed

it download it in a single session

[now it's 3.5 GiB]

<o​frnxmr:xmr.mx> Maybe your hard drive is failing?

if it's like that, I'm the worst luck in the world: previous SSD switched in read-only mode and this one has 2 weeks of use

IIRC monerod auto switches to safe after finishing sync.

<o​frnxmr:xmr.mx> Waaat??

<o​frnxmr:xmr.mx> Really??? 🥹

testone: could be bad memory then

i lost a storage array like that

NorrinRadd: bad RAM could do this? a check with memtest-like tools can detect this problem?

so many things need answers: old.reddit.com/r/Monero/comments/1j…o_ask_anything_monday_april_14_2025

<j​effro256:monero.social> gingeropolous: Reddit won't let me log in from Tor and my clearnet IP is blocked altogether, but to answer this this question:

<j​effro256:monero.social> > Is it true that inputs are sorted by amount spent? I mean - if I transferred more XMR, I was probably almost all the time the last (15th) in inputs. If I sent less xmr, i was like 11-14th. I was never on positions 1-7 etc. So considering how safe this is? I mean sending larger amounts. And - they were not that large.

<j​effro256:monero.social> > Thanks for answer.

<j​effro256:monero.social> Transaction inputs in Monero since fork v7 are sorted by key image in reverse lexicographical order; the amount of the input is not taken into account. Since the key image of an input is a function of a cryptographic hash, the order is effectively random from an external observer's viewpoint. Your distribution of orders of amounts in your inputs is purely a matter of chance.

<j​effro256:monero.social> Source: monero-book.cuprate.org/consensus_r…nsactions/inputs.html#sorted-inputs

<j​effro256:monero.social> Source: github.com/monero-project/monero/bl…ryptonote_core/blockchain.cpp#L3435

<j​effro256:monero.social> To be more specific, since the key image is a function of a cryptographic hash *and private key material*, the order is effectively random from an external observer's viewpoint

<r​ucknium:monero.social> jeffro256: Aren't they talking about position in the ring signature? They are just saying "the decoy selection algorithm isn't great".

<j​effro256:monero.social> Oh you're probably right. I wouldn't call each ring member an "input" on its own, but that's probably what he's referring to

<j​effro256:monero.social> But he's comparing *amounts* between "inputs"

<j​effro256:monero.social> Usually a single ring won't contain 2 or more of your own outputs

<r​ucknium:monero.social> I'm not sure, but he/she is probably looking at this: xmrchain.net/tx/be70f70246519a1bfc5…eab9fb9d459a1a55e958ffa2aa4bc9cace0

<r​ucknium:monero.social> > I mean - if I transferred more XMR, I was probably almost all the time the last (15th) in inputs. If I sent less xmr, i was like 11-14th. I was never on positions 1-7 etc.

<j​effro256:monero.social> If I had to guess, either A) it's just bad luck that they're seeing this pattern, or B) they have one large UTXO that gets spent very often due to the necessity to fund a payment, while the smaller ones don't have to get picked up as often since they're not required. Therefore the average spend time of the large amount UTXOs is much shorter than that or the small amount UTXOs

<p​aranoia_machinery:monero.social> x.com/saucy_xmr/status/1911915814460199144