06:29:12 <sxhkskit> twitter.com/hyc_symas/status/1203709575226183683
06:29:12 <sxhkskit> Last time I got an award like that was in a primary school football team. It had three stars too and said that I'm special :')
06:29:12 <sxhkskit> I just binned it though instead of showing it off to naive groupies. What kind of preson takes a group achievement award and presents it as a proof of their individual prowess anyway?
09:07:28 <mj-xmr> crst, My personal experience is, that mining only makes sense on a passively cooled CPU. Otherwise the maintenance costs overwhelm the profits.
09:10:38 <crst> mj-xmr: Thanks so much for that info! The servers are running for a fixed price in a DA anyway. I'm looking for a solution to gently use free CPU and not interfere with the running services.
09:11:49 <mj-xmr> Aha, if you're not responsible for the maintenance, then go for it! I do the same on my server in a data center.
09:12:30 <mj-xmr> Just one tip: run the process with a "nice" prefix, so that if you want to do something serious on the server, the mining software yields.
09:12:53 <mj-xmr> nice -n 15 ./xmr-stak-rx --noTest
09:14:01 <mj-xmr> Don't kill me for the choice of mining software, hahahaha
09:14:52 <crst> Awesome! Was just gonna ask if it's better than the normal xmrig :D
09:17:10 <sech1> it's slower (= not better)
09:30:58 <mj-xmr> I can't say objectively, but xmrig can be used under Rpi4, stak not. OK. -dev. Let's chat somewhere else.
09:31:31 <mj-xmr> -community?
09:32:37 <crst> There's -pools and -otc
09:50:42 <mj-xmr> OK. I joined both.
11:34:36 <mj-xmr> Today I reported so much spam, that GitHub itself considered me a spammer for a while.
11:34:48 <mj-xmr> On my dev branches.
12:18:37 <gingeropolous> lol
12:53:39 <selsta> merge list: 6810 7005 7274 7332 7349 7366 7368 7373 7394 7398 7400 7401 7402
12:53:46 <selsta> (I'm a bot now)
13:04:06 <sethsimmons> lol
13:20:26 <crst> Keep getting `E couldn't query power status from /sys/class/power_supply` here on Ubuntu while running monerod.
13:22:23 <moneromooo> Might not have the right kernel modules up.
13:22:44 <moneromooo> You'll only need this if you want to set up smart mining though.
13:32:15 <woodser> it appears wallets make 5 calls to the daemon when syncing starts and before the first call to get_blocks.bin: get_info, get_version, get_info, get_transaction_pool_hashes.bin, and get_transactions
13:35:27 <woodser> thoughts on reducing this to one call before downloading blocks for performance?
13:36:29 <moneromooo> What's slow ?
13:37:23 <woodser> yeah with a remote node, those 5x calls can go slow before the user sees blocks downloading
13:37:47 <moneromooo> Remote as in not yours ?
13:38:40 <woodser> yes. and for a daemon, that's 5 requests to serve each time a client wallet polls
13:40:07 <moneromooo> I guess you could add a "don't look at txpool" wallet setting...
13:40:31 <moneromooo> get_info is now blocking on a mutex, since fairly recently. This needs fixing.
13:41:28 <woodser> the wallet needs to look at the pool to get quick notification of txs though
13:42:05 <moneromooo> Ah, so you want to have a "GIMME ALL" call ?
13:42:18 <moneromooo> If that's a problem, maybe 0mq would be faster ?
13:42:35 <woodser> yes, I was thinking something like a combined `get_tx_pool` which returns all info from get_info, get_version, get_transaction_pool_hashes.bin, and get_transactions necessary to start syncing
13:42:41 <moneromooo> But if it only annoys those who don't run their own node, I'm not too bothered :)
13:43:31 <moneromooo> There's already a get_txpool. It was replaced by get_transaction_pool_hashes.bin, because slow.
13:43:52 <moneromooo> You don't want to get the whole txpool if you already have most txes.
13:50:01 <gingeropolous> i think it would be for any remote node, whether you control or not?
13:50:16 <woodser> yeah I'm thinking of users of full wallet apps like cake wallet or monerujo who experience a noticeable delay before the wallet even starts syncing which is problematic for in-person payments
13:51:30 <moneromooo> How much time does it take to get txpool contents then ?
13:51:31 <woodser> the client wallet communicates a client_id to the daemon.  perhaps the daemon call can exclude pool transactions already served to the client?
13:52:08 <moneromooo> Define client_id ?
13:52:20 <moneromooo> I don't remember that being a thing.
13:52:35 <moneromooo> Unless you mean for RPC payment ?
13:52:42 <woodser> it depends on the speed of connection, but there can easily be a 20 second startup time if it's slow, I suspect much of which is overhead in just making the hops
13:53:04 <moneromooo> Wow. That's slow. Then use your own node.
13:54:44 <moneromooo> Or speed up whatever is low if you want. Or delay txpool stuff.
13:55:19 <moneromooo> The idea of a "do these unrelated things" RPC is vaguely unpalatable to me, but only vaguely I guess.
13:55:30 <woodser> again the intended use case is for in-person payments for users of full wallet apps, e.g. cake
13:56:04 <woodser> so this call would serve to improve performance in that case
13:56:29 <woodser> I see wallet2 send a "client" field with the call to get_info
13:57:30 <woodser> or perhaps such a field can be used in this call even if not there now
13:57:34 <moneromooo> That's for RPC payment. Most clients won't do that.
14:02:25 <moneromooo> After thinking some more, a RPC for that could be ok. You could probably piggy back on getblocks.bin in fact.
17:06:17 <gingeropolous> <moneromooo> Wow. That's slow. Then use your own node. >>> this is true if its a remote node you own or a public one....
17:06:30 <gingeropolous> the whole slow responsiveness thing. cakewallet and monerujo can both connect to a self-controlled node
17:09:20 <tobtoht> I connect to my own .onion node, latency is an even bigger issue over Tor
17:16:30 <moneromooo> Now that's a really good argument :)
17:16:48 <moneromooo> "The node 839283 other people use is slow" isn't.
18:22:19 <agentpatience> Did you know one of the developers is working on integrating Triptych?!
18:22:19 <agentpatience> Triptych is a zero-knowledge proving system for confidential transactions created by the Monero Research Lab!
19:42:44 <yqjhabypvcin> When Tari finally comes out, will you dump your Monero to buy it? Will others?
21:19:19 <TheCharlatan> need to unsub from the repo if the spam continues like this :(
21:20:49 <mj-xmr> TheCharlatan, The spam has clearly identifiable patterns. I keep reporting this to GitHub. They could apply some automated filters, but you know how it is in large corporations. They need their meetings first...