07:37:45 <spoke0_> Is it possible that an rpc call to rescan_spent will delete the destination field of all past outgoing transaction?
07:43:43 <selsta> IIRC yes
07:47:34 <spoke0_> Is it also possible that this happens during importing keyimages/outputs?
10:09:51 <snackoverflow> is monero a bitcoin fork?
10:10:28 <aqua42> no
10:15:53 <tryphe> monero, it's got what plants crave!
10:26:01 <aqua42> ring signatures?
10:27:17 <asymptotically> privacy! plants don't like to grow while you're watching
10:45:48 <aqua42> 🌵👀
11:38:52 <asymptotically> is there a way to start a new private testnet/stagenet from the latest fork or block version?
12:19:48 <moneromooo> spoke0_: no
14:17:51 <newyearday> hello
17:30:21 <eddyH> anyone managed to recover from a coredump when running monerod. managed to get 50% blockchain download yesterday, today it just core dumps.
17:30:57 <selsta> you most likely have to sync from scratch
17:31:11 <eddyH> start over again ?
17:31:14 <selsta> core dump usually means that your computer crashed / didn’t shut down properly
17:31:29 <moneromooo> Yeah, that db is annoying, it's fast as it saves the "links" data directly, but it means segfaults and bus errors when it's bad :/
17:31:51 <moneromooo> It's supposed to never corrupt, but in practice it can't avoid it.
17:31:55 <eddyH> so shall i start over and run in safe mode ?
17:32:01 <moneromooo> Could be a bug in monero too though.
17:32:25 <eddyH> i raised it on github, but log file says nothing, where is core dump nowadays
17:33:04 <moneromooo> You can try running once with --db-salvage, might help.
17:33:17 <eddyH> tried that :)
17:33:22 <eddyH> no luck
17:33:58 <moneromooo> Then nothing left but re-download.
17:34:20 <eddyH> ok
17:35:06 <moneromooo> If you're on crashy/windows, I guess you can exit from time to time and backup the partly synced db, then restart from that next time you run into this :)
17:37:41 <eddyH> im on ubuntu. i noticed when i control D the terminal it seemed to hang.
17:37:56 <eddyH> no smooth closedown
17:38:54 <selsta> does ctrl + c work?
17:39:08 <eddyH> same with that as well, hangs
17:39:38 <moneromooo> An all thread stack trace would be helpful if that happens again.
17:40:06 <eddyH> ok, see if i can get one of those.
17:41:27 <moneromooo> (thread apply all bt full)
18:06:41 <Adriel> If I am running in rpc mode, how do I see the hash rate of all my workers?
18:06:57 <Adriel> in monerod
18:08:59 <Adriel> is there any documentation that explains how the rpc daemon mode works besides the api documentation?  I searched but could not find anything.
18:09:41 <nioc> Adriel: there is also #monero-pools for a possible answer
18:10:28 <nioc> Much off topic and trolling along with knowledge :)
18:10:39 <Adriel> ?
18:10:56 <Adriel> what is off topic and trolling?
18:15:46 <lza_menace> Adriel: he means your question might be better suited in #monero-pools channel but that they go off topic a lot and occasionally troll
18:15:54 <Adriel> ohhh ok
18:16:06 <Adriel> they said it cant be done
18:16:13 <Adriel> monerod just doesnt do it
18:17:11 <lza_menace> yeah, it depends on the mining software you're using ,really
18:17:18 <lza_menace> i'll carry the convo in the other channel
18:20:53 <fuwa> Adriel: https://web.getmonero.org/resources/developer-guides/daemon-rpc.html#mining_status
18:23:18 <Adriel> yea that just shows the status of the internal miner
18:23:28 <Adriel> not any rpc clients that are mining through the daemon
18:23:45 <fuwa> daemon couldn't possibly know that
18:24:11 <Adriel> yea the workaround that sounds best is to use a proxy and have that connect to the daemon
18:24:16 <Adriel> then I can get full stats at the proxy
18:24:42 <fuwa> right
18:24:51 <Adriel> anyway I think I have enough to go on now, thanks very much for the recommendation for the other channel :)
18:25:52 <nioc> meow
20:02:53 <azy2> monerod: W Failed to commit a transaction to the db: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid, E Exception in cleanup_handle_incoming_blocks: Failed to commit a transaction to the db: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid
20:03:38 <moneromooo> OS crash or power loss ?
20:07:04 <azy2> i put it to sleep/hibernate regularly
20:12:48 <moneromooo> I think that should be fine (unless buggy).
20:13:36 <selsta> azy2: self compiled or release binaries?
20:13:52 <azy2> release
20:14:02 <moneromooo> Or it could be that odd bug with some error message scribbling over the db.
20:14:14 <marmulak> I always compile
20:14:30 <selsta> I think you can send the DB to hyc (if he has time)
20:14:35 <moneromooo> And with what version of libunbound ?
20:15:18 <moneromooo> Not that I know which one is suspected anyway :P
20:15:33 <azy2> how would i find that out?
20:16:07 <selsta> release binaries should have ok unbound
20:16:25 <fuwa> yeah
20:16:28 <selsta> though no idea if unbound even is / was the problem
21:00:33 <xmrpow> Hey, guys might it be possible that monerod cant run stable on 2gb ram without the swap activated?
21:01:18 <xmrpow> Im running my monerod on 4gb ram machine that is always in sync for some days but then it suddenly stops
21:01:34 <xmrpow> With memory allocation failed
21:01:48 <xmrpow> Should be a ram problem,right?
21:14:07 <hyc> given that the corruption we saw consisted of libunbound debug msgs that normally go to stderr, it's quite certain that the offending data came from libunbound
21:14:17 <hyc> whether it was libunbound or something else that messed up stderr, dunno
21:15:09 <selsta> updating unbound to the latest release would probably be a good idea
21:15:18 <selsta> they had an audit and fixed a lot of bugs
21:15:57 <hyc> yeah, I guess we ought to do that before v0.15.1
21:17:00 <selsta> yep