01:00:24 So . . . I know this isn't a Monero question, but . . . are Litecoin addresses from the same wallet identifiable via the blockchain as linked addresses? 01:00:43 1. This is Monero-relevant, but I'm not telling you why. 01:01:20 if it's anything like Bitcoin, they shouldn't be 01:01:55 2. The #litecoin channel seems to have a small, inactive user base, as opposed to this channel's large, inactive userbase. 01:02:08 are you talking about mweb testnet addresses? 01:02:10 (unless of course you later spend outputs from both addresses in 1 tx) 01:02:13 ndorf: I think Litecoin was basically a Bitcoin fork, so yeah, that's what I thought. 01:02:45 ocb: No, I'm talking about actual live network stuff involving Litecoin. 01:04:01 I wonder whether there's anything like coinjoin for Litecoin. 01:04:18 probably not 01:04:34 ^ had that idea for a while 01:04:46 but as you said, user base is pretty small 01:05:11 from my ltc electrumx servers i can see somebody is pumping transactions intentionally from time to time 01:06:43 peeling an onion from a big utxo with minimal changes. i believe ltc is pretty much driven on a small user base with hypes on various implementations like segwit was, and now mweb is. but thats only me. 01:08:00 "uptime": "24d 10h 56m", "txs sent": 8585, "request total": 73802327 01:08:48 9 months ago it barely had 20-30, not sure what exactly changed. be careful. 01:09:00 but that's offtopic, won't spam anymore 01:11:25 is there a way or a list to publish an onion address of a monero remote rpc port. 01:12:07 s/port/service/ 01:17:57 ocb, monero.fail 01:20:37 thank you 04:01:05 advertising spiel: "Monero: Giving You Reasons To Celebrate Private Transactions But Not Being Able To Share The Joy Because That Would Deanonymize You" 04:01:13 What do you think? Is it a winner? 04:02:57 you choose who to share the joy with 04:08:36 way to ruin a joke 04:10:23 I know not what I do 04:10:38 I need brain as a service 16:20:15 your node is 7.6 years behind. 7.6 years. wow 16:50:51 why does syncing take forever recently? 16:52:34 it says 3 days for 2000 blocks and shows SYNCHRONIZATION started every 5 minutes 16:59:56 haZ: is it HDD or SSD 17:00:21 also try turning it off and on again, no joke 17:00:40 just "exit" and restart 17:01:13 there are some recent blocks that are very resource intensive 17:11:47 nioc: its hdd but it's never been this slow 17:13:46 haZ: someone was combining many many outputs up to the max allowable per tx, I think 194 outputs which is what makes some of the more recent blocks difficult 17:13:55 there were many such txs 17:15:05 they are also cpu intensive 17:16:17 that may be it 17:19:55 nioc: ok thanks, have tried restarting it 18:05:41 ringct txs can only have 16 outputs max 18:15:33 15 and change address 18:15:41 er output 19:20:41 my pruned node took approximately 15-18 hours to sync (40G) 19:22:44 on SSD ..although dont understand why it matters that. does monerod access heavily that data while writing it ? 19:44:38 about syncing. I do notice that syncing takes hours if host is months out of date, and it seems like there is a re-scan of the entire chain. has anyone else seen this? 20:05:52 hyc: yes, I meant inputs :) 20:06:32 AIUI those are limited by size relative to the blocksize 20:10:13 3 fit in the default blocksize 20:57:55 cornfeedhobo: if you start after months the node doesn't have any fast sync checkpoints 21:24:21 that makes sense. thank you. 21:33:18 cornfeedhobo: so basically if you didn't start for months check first if updates are available 21:33:28 if yes, it will contain new checkpoints and syncing will be faster