04:47:16 <fsg> hyc: would you say the config from xmrig enable_1g_pages.sh would suit both p2pool and xmrig randomx tasks on the same host?
05:26:32 <gingeropolous> i know i ask this every random n period, but why is it a bad idea to run a p2pool over tor / i2p?
05:27:07 <gingeropolous> is there some tuning of uncles and target blocktime that would allow the inherent latencies in those networks to sorta wash out?
07:07:42 <mechanic41turk[m> OK. Now I have monerod and p2pool up and running and they both are synced.
07:07:50 <mechanic41turk[m> Now I have downloaded the latest release of xmrig.
07:08:05 <mechanic41turk[m> Do I have to change any of the lines in the config.json for the xmrig?
07:08:42 <mechanic41turk[m> Like, do I have change the line 65, "algo": null ?
07:29:56 <mechanic41turk[m> or the line below that, "algo": null
08:33:35 <mechanic41turk[m> Ok. I changed the pool specification on config.json (on my miner laptop) to my raspi's local IP, 192.168.1.43:3333 and my miner laptop seems to have magically connected to my raspi.
08:36:10 <merope> <gingeropolous> "i know i ask this every random n..." <- I don't know about tor, but the latencies of i2p and the instability of its connections are definitely not suitable for p2pool and its 10 second target block time
08:39:59 <mechanic41turk[m> ```
08:40:06 * mechanic41turk[m sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/5761cdb057ff77ebf4bddcc71f68b87b09d638eb
08:40:11 <mechanic41turk[m> Is this normal? My monerod reporting this.
08:42:19 <mechanic41turk[m> Also, I am getting this on p2pool:
08:42:34 * mechanic41turk[m sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/f4dacd25771330cff2281ec6c9d56797954cc053
08:42:52 <mechanic41turk[m> Isn't it weird that p2pool is reporting my hashrate as 0 H/s ?
08:43:23 <mechanic41turk[m> Here is what my xmrig reports on my laptop:
08:43:33 * mechanic41turk[m sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/851dc6633b243ea54cf5b6ab136020508aab16e6
08:49:51 <ruek0293308600[m> Probably your difficulty https://p2pool.io/#faq
08:50:46 <merope> P2pool can only estimate your hashrate based on the valid shares you submit
08:51:18 <merope> And since the target difficulty is quite high, it will take you quite a while to find one
08:52:20 <mechanic41turk[m> So this is not similar to cryptonote.social pool, in which, I get constantly valid hash submissions
08:53:26 <mechanic41turk[m> ruek0293308600[m]: This might explain my issue.
08:53:53 <mechanic41turk[m> However I don't know what is a good custom fixed difficulty for me
08:54:35 <mechanic41turk[m> I don't know why I am even allowed to set a custom difficulty, as from bitcoin I know that the difficulty is decided by the network as a whole, not by a singular miner.
08:55:13 <ruek0293308600[m> I usually set is so that I get results around 30 seconds 
08:56:10 <mechanic41turk[m> ruek0293308600[m]: Ok. So, on which line within config.json file do I enter my custom difficulty value?
08:57:56 <ruek0293308600[m> If you're using a config, the user field e.g. `"user": "x+75000",`
08:58:32 <mechanic41turk[m> ruek0293308600[m]: Thanks. I will try that.
08:58:40 <mechanic41turk[m> Us 75000 a good value?
08:58:59 <mechanic41turk[m> How should one judge the appropriateness of such a number?
08:59:05 <merope> Use your hashrate * 30
08:59:14 <mechanic41turk[m> endor00[m]: Ok
08:59:16 <ruek0293308600[m> That's the example in the faq, you can tune it to your liking as xmrig will reload as soon as you edit it
08:59:29 <merope> mechanic41turk[m]: Your average time to find a share is diff / your hashrate 
08:59:49 <merope> And a good target time is 20-30 seconds
09:00:03 <merope> Hence hashrate * 30
09:10:25 <mechanic41turk[m> Now I am getting non zero hashrate and nonzero hashes.
09:11:11 <mechanic41turk[m> Am I like fooling my p2pool node this way? I still dont get how I can decide on my end on the amount of hashes submitted.
10:43:44 <pauliouk> mechanic41turk[m, originally when I started on p2pool I didn't set any difficulty and just mined at the pool side difficulty, landed shares just as regularly as I did with a difficulty set, just meant p2pool status mostly showed 0h/s
10:44:15 <pauliouk> my p2pool node still shows 0h/s as my xmrig-proxy doesn't have a set difficulty, but still getting shares and everything works as expected
11:07:23 <mechanic41turk[m> pauliouk: i see.
11:07:58 <mechanic41turk[m> s/id/is/
11:09:14 <pauliouk> yup :)
11:09:19 <pauliouk> nice to know its working though
13:48:01 <gingeropolous> merope, right, but the blocktime can be adjusted to 20 seconds or 13 seconds or whatever. 
13:54:00 <merope> Sure, but the whole round-trip latency can go north of 10 seconds sometimes, not to mention the possibility of broken tunnels (which mean you might lose a valid share due to network issues)
13:54:41 <gingeropolous> which could be accounted for with a modded uncle penalty
13:55:07 <gingeropolous> of course the problem is you can't force the users to use the hidden networks
13:55:23 <gingeropolous> well, i guess u can if there's only i2p / onion addies in the peer list
13:55:56 <gingeropolous> and, this could have the effect of encouraging locality based networks to pop up
13:56:14 <gingeropolous> though perhaps this is more for when monero mining is performed by more people
13:59:18 <pauliouk> tor is a risk I'd only consider if I had no other options to be fair
13:59:43 <pauliouk> I struggle to get shares on the mini sidechain as it is, it'd hurt if I missed out on one because of network lag
17:27:58 <hyc> how would network lag make you miss out on a share?
17:31:21 <merope> By the time you submit it, it has become stale. Or, by the time you get the new template, it has already been replaced by a new one
17:31:53 <merope> Keeping in mind that i2p can easily lag by several seconds
17:33:08 <hyc> ok
17:33:34 <merope> Or your tunnel might get broken because one of your intermediary peers has gone offline, and it might take a minute or two to form a new one 
17:34:00 <hyc> I don't consider that latency. that's a lost connection.
17:34:39 <merope> Same difference, at the end of the day
17:35:22 <merope> I2p is nice for anonimity, but it's not a very fast networj
17:35:42 <pauliouk> hmm fair point, but ya, my shares are too precious to me to risk it
17:36:30 <hyc> my shares are giving my cat a warm place to nap. the rest is just whatever
17:37:27 <crypto_grampy[m]> proof of comfy cats
17:41:21 <pauliouk> my cat prefers the laser printer on the top shelf :/
17:42:19 <hyc> we can port randomx to postscript
17:42:30 <hyc> keep the printer nice and toasty
17:46:50 <pauliouk> heh, not a terrible idea - though something tells me the work to do that is more than its worth :)
17:47:47 <hyc> ;)
17:48:04 <hyc> I have no idea what kind of performance modern laser printers are capable of anyway
17:48:46 <hyc> but back in the m68k days, the printer CPU was equal to or faster than a desktop CPU
19:06:45 <pauliouk> this is a geriatric SP100e - I doubt it has more than a 1970's calculator for a processor :P
19:07:31 <pauliouk> I only use it for printing out pcb designs on OHP paper for etching
19:07:54 <pauliouk> how much extra load does p2pool --no-randomx  have on the monerod?
19:13:58 <pauliouk> if for example, I were to run 50+ nodes for users?
19:17:48 <hyc> on mine it's unnoticeable
19:17:59 <hyc> but it really depends on how fast you submit shares
19:19:19 <hyc> actual creditable shares. not fixed-diff shares for hashrate estimation
19:23:22 <pauliouk> setting up a vps to host nodes for people struggling to get them running themselves. can't imagine there'd be much hashrate coming in :)
19:24:48 <hyc> the impact of --no-randomx is every time a share that meets the p2pool difficulty is received, it's sent to monerod for validation
19:25:07 <hyc> that still only happens once in a long while for typical miners
19:26:25 <pauliouk> and means that p2pool doesn't hog ~2gb of mem
19:27:17 <pauliouk> guess I'll need the monerod node running unrestricted though
19:28:14 <hyc> yes and yes
19:28:42 <hyc> if you don't want it open to the world, I would use an stunnel on both sides
19:28:45 <merope> <pauliouk> "setting up a vps to host nodes..." <- The problem with such a system is that people would have to fully trust you, because they would have no way to tell if you're legitimately running the p2pool node with their address in it, or your own
19:29:00 <pauliouk> yup
19:29:11 <pauliouk> not just hosting, but letting them see whats going on
19:29:30 <hyc> just host the monerod, let them run their own p2pool
19:29:49 <pauliouk> so they'll mine to an xmrig-proxy that connects to their node, that way I can give them miner stats
19:29:55 <hyc> the idea is not to centralize p2pool instances...
19:30:04 <pauliouk> its the whole "whats the point in p2pool if I can't port forward to let xmrvsbeast mine for me?!"
19:31:24 <merope> I mean... the whole point is that you can mine in a pool without having to trust a pool operator
19:31:42 <merope> You're just reinventing a pool with extra steps
19:31:53 <pauliouk> yeah I have a feeling those that won't go the lengths required to get it running themselves don't care much about that
19:31:59 <merope> Might as well just run a traditional pool at that point
19:32:26 <pauliouk> think of it as a try-before-you-buy
19:57:26 <gingeropolous[m]> oddly enough bitcoin's p2pool allowed that kinda thing
20:03:53 <hyc> allowed what?
21:53:53 <nikg83[m]> What % of daily monero txs currently are from p2pool payouts ?
21:55:45 <pauliouk> sethsimmons, no-body (not in this channel #p2pool-mini) is having issues with your docker setup when transition to the mini pool