11:13:54 <m-relay> <p​laiwanone:matrix.org> GM
11:13:55 <m-relay> <p​laiwanone:matrix.org> Holy
11:14:12 <m-relay> <p​laiwanone:matrix.org> In
16:09:22 <testone> 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?
16:27:00 <moneromooo> 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.
16:27:56 <moneromooo> 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.
16:28:24 <moneromooo> Oh: Before doing that, post the output line from "status" in the monerod console.
17:00:33 <testone> I get these 2 lines:
17:00:35 <testone> 2025-04-14 16:59:41.714	I Monero 'Fluorine Fermi' (v0.18.4.0-release)
17:00:35 <testone> 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
17:01:24 <testone> [I recently restarted it exactly for adding 1 on log-level]
17:03:02 <testone> [I added the DNS blocklist too and some other options suggested in docs. guide]
17:14:50 <moneromooo> Check in half an hour whether the first number in 1423028/3390013 went up. If so, you're good, it's just slow.
17:15:17 <moneromooo> If your chain is on a spinning platter disk, that is 99% certain why.
17:16:11 <moneromooo> The second number is unimportant, but will almost certainly have increased by a dozen or so.
17:56:40 <testone> they are the same, both numbers
18:09:09 <testone> moneromooo: I uploaded monero.log --> https://cloud.disroot.org/s/7t3YEPtd25FSAJ7 (~54 MiB)
18:09:55 <testone> [log-level=1 is very more verbose than 0 :)]
18:11:49 <testone> it's full of lines like this:
18:11:50 <testone> 2025-04-14 18:10:29.832 [P2P1]  INFO    blockchain.db.lmdb      src/blockchain_d
18:11:50 <testone> b/lmdb/db_lmdb.cpp:86   Error adding spent key image to db transaction: MDB_CORR
18:11:51 <testone> UPTED: Located page was wrong type
18:27:30 <moneromooo> Then your db is shot, and needs deleting. It cannot sync further due to this. Which platform are you on ?
18:28:40 <testone> linux 64bit
18:29:34 <testone> how to prevent it to re-happen?
18:30:12 <testone> before I had not the dns block list enabled, bad peers could do this?
18:32:14 <testone> what to delete? all? just lmdb/*? just data.mdb?
18:52:16 <moneromooo> data.mdb is all you need to delete.
18:53:08 <testone> done and restarted
19:10:22 <m-relay> <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
19:10:31 <m-relay> <o​frnxmr:xmr.mx> Further corruptions*
19:15:37 <testone> sys nor monerod never crashed
19:15:54 <testone> it download it in a single session
19:16:21 <testone> [now it's 3.5 GiB]
19:20:05 <m-relay> <o​frnxmr:xmr.mx> Maybe your hard drive is failing?
19:28:02 <testone> 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
19:44:45 <moneromooo> IIRC monerod auto switches to safe after finishing sync.
19:57:51 <m-relay> <o​frnxmr:xmr.mx> Waaat??
19:58:22 <m-relay> <o​frnxmr:xmr.mx> Really??? 🥹
20:11:10 <NorrinRadd> testone: could be bad memory then 
20:11:20 <NorrinRadd> i lost a storage array like that 
21:26:25 <testone> NorrinRadd: bad RAM could do this? a check with memtest-like tools can detect this problem?
21:49:46 <gingeropolous> so many things need answers: https://old.reddit.com/r/Monero/comments/1jyugt0/maam_monero_ask_anything_monday_april_14_2025/
22:10:34 <m-relay> <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:
22:10:34 <m-relay> <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.
22:10:36 <m-relay> <j​effro256:monero.social> > Thanks for answer.
22:10:38 <m-relay> <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.
22:12:10 <m-relay> <j​effro256:monero.social> Source: https://monero-book.cuprate.org/consensus_rules/transactions/inputs.html#sorted-inputs
22:12:10 <m-relay> <j​effro256:monero.social> Source: https://github.com/monero-project/monero/blob/eac1b86bb2818ac552457380c9dd421fb8935e5b/src/cryptonote_core/blockchain.cpp#L3435
22:17:42 <m-relay> <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
22:19:31 <m-relay> <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".
22:21:16 <m-relay> <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
22:22:00 <m-relay> <j​effro256:monero.social> But he's comparing *amounts* between "inputs"
22:22:29 <m-relay> <j​effro256:monero.social> Usually a single ring won't contain 2 or more of your own outputs
22:23:00 <m-relay> <r​ucknium:monero.social> I'm not sure, but he/she is probably looking at this: https://xmrchain.net/tx/be70f70246519a1bfc56c531ce09feab9fb9d459a1a55e958ffa2aa4bc9cace0
22:23:07 <m-relay> <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.
22:25:29 <m-relay> <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
22:58:44 <m-relay> <p​aranoia_machinery:monero.social> https://x.com/saucy_xmr/status/1911915814460199144