07:18:42 <mightysnowman[m]> Wait is it possible to use p2pool with remote daemon?
07:41:31 <DataHoarder> yes
07:44:28 <sech1> you need a compatible remote daemon though
07:57:09 <DataHoarder> 21 outputs on the last block
07:58:06 <sech1> and I'm still unlucky: Current effort     = 366.184%
07:58:53 <sech1> even 22 outputs in 2448328
08:08:11 <DataHoarder> sech1: 23 on last block!
08:29:12 <Inge> sech1: sorry about that. I stole your payouts
08:29:46 <wfaressuissia> anybody here using p2pool with local monerod from home ?
08:29:49 <wfaressuissia> How much out/in bandwidth do you have there ?
08:30:09 <sech1> it depends on how many peers you have
08:30:38 <sech1> 3-4 KB/s per peer outgoing bandwidth
08:30:45 <wfaressuissia> How much out/in network bandwidth do you pay for to have at home ?
08:30:48 <sech1> incoming bandwidth is 9-10 times smaller
08:31:13 <sech1> I have fix price 100 Mbit
08:34:22 <DataHoarder> wfaressuissia: no bandwidth limits here
08:34:34 <DataHoarder> 10G/10G too
08:35:20 <DataHoarder> should be minimal, and you can reduce bw of monerod/p2pool by just having desired number of outgoing connections
08:35:22 <wfaressuissia> I'm interested in lower boundary for bandwidth that is someone could have with 5KH/s hashrate
08:35:38 <DataHoarder> if your hashrate is local, you won't be seeing much traffic
08:35:43 <wfaressuissia> * ... that is available to someone with  ...
08:36:11 <sech1> if you don't open ports for incoming connections and use pruned node (it reduces bandwidth), I think you could get away with 100-200 Kbit outgoing
08:36:23 <DataHoarder> lots of blocks this morning found by p2pool
08:41:45 <DataHoarder> checked some logs, with pruned node with 100+ connections and p2pool with more hash than that, even remote, it's 50-80KB/s
08:45:58 <Inge> heh. non-pruned node and p2pool running for 18 hours shows 2.5GB in and 13.7GB out
08:46:19 <DataHoarder> includes initial sync right Inge ?
08:46:24 <DataHoarder> wait no
08:46:55 <DataHoarder> saw 250GB in, need more sleep 
08:48:17 <Inge> hehe
08:51:10 <wfaressuissia> 10G == 10Gbps ? are you living in data center ?
08:51:31 <DataHoarder> no, just residential cheap internet wfaressuissia 
08:51:35 <sech1> he IS data hoarder after all
08:51:43 <DataHoarder> ah, and a free 1G backup ISP
08:53:45 <DataHoarder> some countries have better internet that is all :)
08:57:51 <Inge> not so long ago it was 18Mbps/0,8Mbps here
08:58:01 <Inge> now you can get 500/500 most places
09:11:20 <pauliouk> meh, my ISP 'upgraded' our internet last week. All they did was reflash the router with a new image to get rid of the 4 year old vulnerbilities, and set it to 100mb/s down, 20mb/s up. Was all good, until I realised they've made the ethernet DHCP release IPs every hour :/
09:11:35 <DataHoarder> yeah, don't use any ISP router
09:11:58 <pauliouk> oh and the connection itself is as stable as chihuahua on crack.
09:12:22 <pauliouk> cable modem :/
09:51:27 <DataHoarder> not like security is necessary given the private tx key for coinbase is known, but it uses the mersenne twister, an alternate version (mt19937_64)
10:23:02 <QuickBASIC> moneromooo: "Maybe this channel could be split between dev type interesting stuff and the mining banter." I suppose you might've gotten your wish since DataHoarder's bot is in #p2pool-log I imagine most of the "banter" will go on there.
10:23:56 <DataHoarder> (I created that to place bot output, can move things elsewhere, if another more "official" channel gets created)
10:30:29 <moneromooo> Sounds good, thank you.
10:34:54 <\x> .tell hyc rumored 12600k https://lewd.pics/p/GqtP.png
10:35:02 <\x> oh
10:35:10 <\x> hyc: rumored 12600k https://lewd.pics/p/GqtP.png
11:45:08 <URoRRuRRR[m]> Is it possible to get the names of the workers from p2pool? I have one that ha disappeared and being able to identify it would be nice
11:45:44 <DataHoarder> don't think so URoRRuRRR[m], but you should be able to put xmrig-proxy in front of it
11:46:17 <DataHoarder> (and change ports, so for example p2pool uses stratum 3332, xmrig-proxy now uses 3333 and takes connections, then xmrig-proxy connects to p2pool)
11:46:27 <DataHoarder> that way you can just use that instead :)
11:46:44 <DataHoarder> no need to change config on workers just yet
11:47:10 <URoRRuRRR[m]> great idea! thanks
13:10:28 <sech1> we just missed a block because someone was mining to a lagging monerod instance: https://paste.debian.net/hidden/6fac52c9/
13:11:23 <gingeropolous> one of those IPs there?
13:11:41 <sech1> 185.230.112.148
13:12:02 <sech1> mined Monero block 2448479, but the network was already at height 2448484
13:12:26 <gingeropolous> any way to create countermeasures for this?
13:13:11 <sech1> people need to fix their damn Monero nodes :D
13:13:28 <gingeropolous> my morning caffeine brain can't make sense of how a single mining node can mine an old block and make the whole pool go stupid
13:14:27 <DataHoarder> XvB it seems sech1 again
13:14:30 <gingeropolous> like, wouldn't my node hear the news of this block and go "no way dude, your behind, im not dealing with you" and then, ignore them for a bit or something
13:15:14 <sech1> yes, if it's more than 5 blocks behind
13:15:18 <DataHoarder> hadn't heard from them for a while, then all their blocks come at once https://paste.debian.net/1211578/
13:15:24 <sech1> but it was exactly 5 blocks behind
13:15:26 <DataHoarder> has happened a few times across the week
13:15:32 <gingeropolous> but how did we *miss* a block?
13:15:53 <sech1> because it was too late to submit it
13:16:00 <gingeropolous> did that old block just force the rest of us to think that we should be on that .... oh
13:16:05 <sech1> XvB's node soft-forked after that
13:16:22 <DataHoarder> submitted height H when monero was at height H + 5
13:16:29 <sech1> it might be one of the reasons why we have more than 100% average effort
13:16:48 <gingeropolous> perhaps it should be 3 blocks and not 5 ... .shrugemoji
13:16:53 <sech1> I didn't have this detection in logs until recently
13:17:31 <DataHoarder> side chain at 32 MH/s
13:18:07 <sech1> right now we have 108.91% average effort over 94 blocks that have effort tracked
13:18:20 <sech1> probability of this happening naturally is 22%
13:18:33 <sech1> I suspect we missed a few Monero blocks because of this
13:18:50 <sech1> or maybe we just had bad luck
13:19:00 <DataHoarder> I wonder if it's something on xmrvsbeast[m] node specific or we just notice cause hashrate accumulation
13:19:21 <sech1> He needs to run monero with proper command line to avoid lagging
13:20:04 <sech1> ./monerod --rpc-bind-ip 0.0.0.0 --rpc-bind-port 18081 --confirm-external-bind --zmq-pub tcp://0.0.0.0:18083 --out-peers 32 --in-peers 32 --add-priority-node=node.supportxmr.com:18080  --ban-list block.txt
13:20:21 <sech1> well, bind/external bind part can be skipped
13:21:15 <sech1> I use external bind to connect p2pool remotely, but only for whitelisted IPs
13:21:37 <pauliouk> hmm, is it worth setting up a centralised monerod side chain? :D
13:21:47 <hyc> another 24hrs no shares
13:22:00 <sech1> hyc same
13:22:04 <DataHoarder> side chain hash rate is low atm, time to get some in
13:22:15 <DataHoarder> (and not get blocks mined!)
13:22:43 <hyc> is this just a delayed effect of the hashrate being 60MH+ earlier?
13:22:48 <sethsimmons> Is the important thing here the `- "--add-priority-node=node.supportxmr.com:18080"`?
13:23:00 <sech1> it's supposed to be a well-connected and fast node
13:23:07 <sech1> so at least 1 peer will be good from the start
13:23:24 <sech1> ban list is also important
13:23:37 <sethsimmons> Yeah, I use ban lists on all nodes
13:23:37 <DataHoarder> on my compose added a few known ones indeed
13:24:00 <sech1> https://gui.xmr.pm/files/block.txt
13:26:19 <hyc> sech1: hmmm, logger is not detecting that logrotate moved the logfile
13:26:27 <hyc> so it's still writing to the old one
13:26:41 <pauliouk> I just got a load of 2021-09-13 12:16:02.373	E Transaction not found in pool
13:26:42 <pauliouk>   
13:27:04 <pauliouk> well I say just, about an hour ago
13:27:14 <hyc> I think you should add a check of st_ino to make sure it's actually a different file
13:27:27 <sech1> hyc https://github.com/SChernykh/p2pool/blob/master/src/log.cpp#L165
13:27:58 <hyc> right
13:28:13 <sethsimmons> `2021-09-13 13:27:52.4625 P2Pool BLOCK FOUND: main chain block at height 2448496 was mined by this p2pool`
13:28:15 <sethsimmons> There we go :)
13:28:21 <pauliouk> 2448496 was mined by this p2pool
13:28:23 <pauliouk> :_
13:28:40 <hyc> i think the problem is that logrotate creates a new logfile so this existence check always succeeds
13:28:48 <pauliouk> now if only I could get some shares :D
13:28:50 <sech1> hyc so is that code correct?
13:29:00 <hyc> not sufficient, no
13:29:18 <hyc> I'll cook up a patch
13:29:38 <DataHoarder> well at least we found another block now 
13:30:53 <DataHoarder> 27 miners paid out, p2pool is growing
13:34:21 <mandelbug> could do with finding a few more whilst I have 3 shares in the PPLNS window :D
14:04:02 <QuickBASIC> Yeah my logrotate did something weird last night too. It started logging into p2pool.log.1 and left p2pool.log blank.
14:08:10 <QuickBASIC> Is there currently any way to output log other than working directory. I'd like to put it in /var/log/p2pool/ for example, but right now it's going into the service account's home /var/lib/p2pool.
14:11:05 <DataHoarder> links is a hack you can do
14:11:11 <DataHoarder> so you get both
14:16:12 <QuickBASIC> Yeah I ln it in there but I thought that's what messed up my logrotate since it's pointed at the hardlink.
14:17:26 <hyc> ah ok, so add nocreate to the logrotate conf to prevent this screwup
14:17:40 <hyc> easier than patching the p2pool code
14:19:18 <hyc> QuickBASIC: just delete the current p2pool.log file. it's prob empty right now anyway
14:19:28 <hyc> then p2pool will notice and switch to a new logfile
14:22:37 <hyc> and for now, just use a startup script that cd's to /var/log/p2pool before running
14:50:44 <hyc> so, at what point do we figure the current sidechain is big enough, and tell people to configure a new sidechain of their own?
14:57:09 <DataHoarder> then no one will find enough blocks on that other sidechain, and most shares be left unused :)
15:01:03 <hyc> meh. eventually this sidechain will max out on addresses it can support. more sidechains will have to spring up, just like there are multiple pools today
15:02:00 <QuickBASIC> hyc pretty sure sech1 said around 150 M/hs (5%) of network hashrate, then it might be necessary. (MoneroTalk podcast).
15:02:59 <QuickBASIC> The problem is going to be finding other small miners to join your side chain. I wonder if it would be helpful to have several named side chains in the documentation so at least you can pick one and not have to find other people.
15:03:27 <QuickBASIC> i.e. Default Default-Low
15:03:47 <DataHoarder> can it max out on addresses hyc? it'll just average out and pay different shares each time
15:03:52 <DataHoarder> like it already kind of does
15:05:09 <DataHoarder> random idea, two chains, small, big. p2pool does both at once. Hashrate above a threshold after gets pushed towards big one, while below the threshold stays on small
15:05:21 <DataHoarder> still will end up with same payouts anyhow
15:05:39 <DataHoarder> and might confuse people using it
15:06:18 <QuickBASIC> I think it's best to let people configure it manually or include a couple of defaults they can select b/c otherwise they might be mad they're on the "wrong" chain.
15:06:31 <DataHoarder> they will always be on the wrong chain
15:06:49 <DataHoarder> the other one will always either: mine more blocks, or give you more shares
15:07:36 <QuickBASIC> Haha. I think I still have shares on the pool named 'default' that never got mined to a block b/c we switched to 'mainet test 2 electric boogaloo'.
15:08:03 <QuickBASIC> So wrong chain indeed.
15:08:21 <DataHoarder> nothing is stopping you from setting a password and mining 100% of the shares :>
15:08:29 <DataHoarder> good luck finding a block though
15:13:12 <QuickBASIC> No, somone was still mining on the 'default' chain so it never died so my shares were still in there, but I just checked again and it's dead now.
15:13:57 <QuickBASIC> I was just joking that I got the shares on the "wrong" chain b/c we switched pools right after I got them lol.
15:18:27 <sech1> Can anyone ping Cake Wallet on twitter? They still haven't updated to the latest Monero code
15:19:44 <DataHoarder> maybe an Issue on GH?
15:19:47 <sech1> When they update, I'll start preparing for p2pool release
15:20:02 <sech1> oh, they have github
15:20:11 <DataHoarder> https://github.com/cake-tech/cake_wallet
15:20:24 <DataHoarder> 27 issues open, 5 closed
15:20:41 <DataHoarder> PRs they do action on more
15:20:48 <DataHoarder> but seems that they are their own
15:21:57 <sech1> https://github.com/cake-tech/cake_wallet/issues/186
15:27:22 <QuickBASIC> Apparently they follow me on twitter so i was able t o DM them the issue and ask.
15:27:38 <sech1> Wallet support + xmrvsbeast[m] needs to fix this node to improve pool luck, and then I think it will be a good time to release
15:27:50 <sech1> *fix his node
15:28:03 <QuickBASIC> In case they're like me and don't see GitHub notifs until days later.
15:28:19 <sech1> it will still have to use custom monerod at first, but I can include monerod binary
15:29:07 <sech1> they ought to update to Monero v0.17.2.3 anyway because of other fixes there (decoy selection fixes)
15:29:21 <sech1> no idea what takes them so long, Monerujo updated 5 days ago
15:29:55 <DataHoarder> maybe sech1 wait till PR merge, so at least you are not using a "monerod fork" but a "dev monero build"
15:30:13 <DataHoarder> no idea how long though
15:39:41 <DataHoarder> https://github.com/cake-tech/cake_wallet/issues/186#issuecomment-918305579
15:39:57 <DataHoarder> nice, but when
15:40:05 <sech1> eventually (c)
15:40:12 <DataHoarder> soon (tm)
16:11:14 <sethsimmons> If you're using Matrix to join these chats, be sure to update your client immediately: https://matrix.org/blog/2021/09/13/vulnerability-disclosure-key-sharing
16:45:34 <sech1> so I checked logs and found 2 more blocks that were wasted: https://paste.debian.net/hidden/80fb872d/
16:45:45 <sech1> 3 blocks wasted today only, since I started logging it
16:45:57 <DataHoarder> oh no :(
16:46:12 <DataHoarder> maybe should have part of the notes about running properly connected monerod
16:46:27 <sech1> no wonder we linger aroung 110% average effort
16:46:29 <sech1> *aroun
16:46:31 <sech1> *around
16:48:14 <sech1> all these blocks follow the same lag pattern (XvB's node desyncs and then sends a lot of shares)
16:48:46 <DataHoarder> maybe it lags because it's checking the block very carefully
16:49:30 <DataHoarder> maybe I can connect a few nodes to it and force in new blocks :)
16:49:34 <sech1> it's something with that node - it desyncs from Monero network and after that all hashrate goes to waste
16:49:52 <DataHoarder> I think the seed node I have connects with their node already
16:49:52 <sech1> hmm, I think I'll add it as a priority node too
16:50:38 <sech1> how do you know?
16:51:01 <DataHoarder> cause I added it as priority
16:51:10 <DataHoarder> (to monerod)
16:51:34 <DataHoarder> an alternative maybe it's that p2pool lags behind, but then XvB monero would submit it either way
16:51:36 <wssh> failing to verify chains.
16:51:40 <DataHoarder> unless it lags everywhere
16:52:17 <DataHoarder> https://old.reddit.com/r/xmrvsbeast/comments/pk5ed6/simplified_p2pool_setup/
16:52:21 <sech1> XvB's p2pool found that block and at that point it should've submitted it to monerod, but monerod was out of sync
16:52:31 <jaska087> I think the xvb node is just bad
16:52:37 <sech1> so that block was orphaned by Monero network
16:52:58 <sech1> 3 blocks in the last 24 hours, not sure about earlier days
16:53:04 <sech1> but it's probably the case we're at 110%
16:53:32 <jaska087> is xbv running their pool/p2pool node as public node too?
16:53:36 <DataHoarder> seems like p2pmd.xmrvsbeast.com:18080 is not really open?
16:53:41 <jaska087> multiple peeps accessing it could cause it to lag
16:54:01 <sech1> it's better to separate public node and the actual mining node
16:54:09 <sech1> all major pools do it to avoid DDoS
16:54:23 <jaska087> ^this
16:55:43 <sech1> mining node must be on a fast machine, preferable dedicated server and limit in/out peers like this: --out-peers 32 --in-peers 32
16:56:02 <sech1> or it'll end up with 553 in peers like mine did :D
16:56:20 <DataHoarder> I have limits but higher than that heh
16:56:57 <sech1> XvB's node might actually have more than 1000 peers and hit ulimit of 1024 open descriptors
16:57:03 <DataHoarder> OH
16:57:13 <DataHoarder> that could be interesting
16:57:21 <sech1> 553 is not far from 1024
16:58:50 <wssh> restarting p2pool and monerod.
16:59:11 <DataHoarder> what error do you get on logs wssh ?
16:59:35 <wssh> just failing to verify chains.
17:00:05 <DataHoarder> in monerod, or p2pool?
17:00:11 <wssh> p2pool
17:00:34 <wssh> and now p2pool crashes when trying.
17:00:55 <DataHoarder> can't find that error message on p2pool code, weird
17:01:04 <DataHoarder> you have free space on disk right?
17:01:14 <wssh> tons.
17:01:44 <wssh> 3 300gb sas disks.
17:01:47 <wssh> 4*
17:02:05 <sech1> paste your p2pool logs (10-20 lines before the crash) to https://paste.debian.net/
17:02:13 <DataHoarder> you can always delete p2pool.cache I believe to force a resync from stratch, but I wonder what made that happen, so maybe don't delete and just move it to p2pool.cache.old
17:03:04 <wssh> ihttps://paste.debian.net/1211615/
17:05:43 <sech1> can you add "--loglevel 5" to p2pool command line and try again? I need more detailed logs
17:10:30 <QuickBASIC> So question, is the only p2pool instance that transmits a solution to monerod the one that finds it or do other p2pool instances also broadcast it to their monerod?
17:10:42 <DataHoarder> they also try to broadcast it
17:10:52 <DataHoarder> as they get the sidechain block from other p2pool peers
17:11:02 <QuickBASIC> Cool cool. Thank you.
17:11:19 <DataHoarder> (this sometimes fails due to having unknown transactions  on it, as transactions can take time to get across nodes)
17:12:44 <sech1> which means XvB's node didn't broadcast these blocks when it found them, probably because it was lagging too much
17:13:39 <sech1> lagging nodes wouldn't be a big problem on p2pool if all miners had the same hashrate
17:13:55 <sech1> but lagging node with 96% hashrate is a problem
17:20:46 <wssh> no crash this time.
17:20:51 <QuickBASIC> So solution is adoption.
17:21:20 <DataHoarder> (and also please fix your nodes so they perform as it matters)
17:21:52 <DataHoarder> XvB is noticeable but smaller ones might also suffer if they lag and find shares that exceed uncle height diff 
17:28:42 <sech1> I've submitted a fix to make this issue less severe. It's recommended to update both binaries (p2pool and monerod)
17:31:57 <DataHoarder> sech1: seems like you brought changes from p2pool-api branch only right, not new ones?
17:32:43 <sech1> I synchronized branches
17:33:11 <DataHoarder> yes, checked commit, it's not newer than the changes from 2 days ago I mean
17:33:13 <sech1> p2pool-api is the latest version of monerod changs, p2pool-api-v0.17 now reflects it
17:33:42 <DataHoarder> great!
17:35:12 <sethsimmons> sech1: So p2pool-api is best branch moving forward? Want to rebuild my image shortly.
17:35:38 <DataHoarder> that is based off a version of master monero upstream
17:36:24 <DataHoarder> anyhow, fired several builds
17:36:34 <sech1> sethsimmons it's built on top of master branch, so it's not exactly what the release would be. Also it doesn't have recent checkpoints, it will sync from scratch slowly
17:39:24 <sethsimmons> So keep using apu-v0.17 branch?
17:40:24 <sech1> yes
17:40:34 <sech1> both branches should work fine
17:42:28 <sethsimmons> Thanks!
17:59:12 <DataHoarder> I'll be pretty happy once it's merged and released cause that means I can grab the produced builds gz, attach a hash / check signature on it, and just use that instead of compiling monerod from source on starved machines :)
17:59:21 <QuickBASIC> My VPS is taking sweet time compiling Monero can I just compile locally on Ubuntu and scp the monerod?
17:59:34 <gingeropolous> if you build it right
17:59:36 <DataHoarder> if you build statically maybe, depends on architecture
17:59:41 <gingeropolous> something static
18:03:47 <DataHoarder> if you are VERY lazy I think you can grab an artifact from here? https://github.com/monero-project/monero/pull/7891/checks?check_run_id=3575081687
18:04:04 <DataHoarder> contains monerod heh
18:05:47 <sech1> gitian builds are static, they should run everywhere
18:06:22 <sech1> https://github.com/monero-project/monero/tree/master/contrib/gitian
18:22:22 <QuickBASIC> Man that sucked because I'm dumb. I recompiled p2pool first and restarted it before the new monerod, and it wanted the new RPC version.
18:23:00 <QuickBASIC> Had to snag the giant build b/c monero compile on VPS kept failing.
18:23:22 <QuickBASIC> s/giant/gitian
18:23:42 <DataHoarder> got xmrig-proxy in front, which points to first p2pool instance, fallbacks to second instance elsewhere, then fallbacks on MO
18:26:00 <QuickBASIC> Yeah I had fallback, but it's still syncing b/c installed SSD and didn't bother to copy Blockchain off old hd.
18:44:27 <sethsimmons> `v0.17.2.3-04bfd948a` is latest, correct? Just built.
19:13:20 <sech1> sethsimmons yes, it's the latest
19:17:42 <sethsimmons> Thanks!
22:02:17 <abberant[m]> Any suggestions for cutting down internet usage of monerod and p2pool? They're using like half a terrabyte a week, and according to monerod's netstats I'm assuming the majority must be from p2pool.
22:08:09 <DataHoarder> Disable number of peers, disable incoming connections kind of
22:08:34 <DataHoarder> also if you have remote workers for mining, make sure they report only the necessary shares
22:08:46 <DataHoarder> pruned monerod too
22:09:51 <DataHoarder> other than that you do need the information coming from p2pool at least, that said, I am not seeing that kind of bandwidth usage
22:19:07 <abberant[m]> <DataHoarder> "also if you have remote workers..." <- How would I make remote workers only report necessary shares? is it an xmrig option?
22:21:05 <DataHoarder> Do not set any custom difficulty 
22:21:17 <DataHoarder> that would be it
22:21:47 <DataHoarder> That said you should probably log traffic per port and see what uses the most, then adjust accordingly 
23:56:04 <abberant[m]> I used vnstat to log internet usage and it aligns with what the node is telling me, so it seems something else on my network must be the culprit, but 20g per day from the node is still a bit much so I'm going to use those other tips to try and bring it down.