Wait is it possible to use p2pool with remote daemon?

yes

you need a compatible remote daemon though

21 outputs on the last block

and I'm still unlucky: Current effort = 366.184%

even 22 outputs in 2448328

sech1: 23 on last block!

sech1: sorry about that. I stole your payouts

anybody here using p2pool with local monerod from home ?

How much out/in bandwidth do you have there ?

it depends on how many peers you have

3-4 KB/s per peer outgoing bandwidth

How much out/in network bandwidth do you pay for to have at home ?

incoming bandwidth is 9-10 times smaller

I have fix price 100 Mbit

wfaressuissia: no bandwidth limits here

10G/10G too

should be minimal, and you can reduce bw of monerod/p2pool by just having desired number of outgoing connections

I'm interested in lower boundary for bandwidth that is someone could have with 5KH/s hashrate

if your hashrate is local, you won't be seeing much traffic

* ... that is available to someone with ...

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

lots of blocks this morning found by p2pool

checked some logs, with pruned node with 100+ connections and p2pool with more hash than that, even remote, it's 50-80KB/s

heh. non-pruned node and p2pool running for 18 hours shows 2.5GB in and 13.7GB out

includes initial sync right Inge ?

wait no

saw 250GB in, need more sleep

hehe

10G == 10Gbps ? are you living in data center ?

no, just residential cheap internet wfaressuissia

he IS data hoarder after all

ah, and a free 1G backup ISP

some countries have better internet that is all :)

not so long ago it was 18Mbps/0,8Mbps here

now you can get 500/500 most places

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 :/

yeah, don't use any ISP router

oh and the connection itself is as stable as chihuahua on crack.

cable modem :/

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)

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.

(I created that to place bot output, can move things elsewhere, if another more "official" channel gets created)

Sounds good, thank you.

.tell hyc rumored 12600k lewd.pics/p/GqtP.png

oh

hyc: rumored 12600k lewd.pics/p/GqtP.png

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

don't think so URoRRuRRR[m], but you should be able to put xmrig-proxy in front of it

(and change ports, so for example p2pool uses stratum 3332, xmrig-proxy now uses 3333 and takes connections, then xmrig-proxy connects to p2pool)

that way you can just use that instead :)

no need to change config on workers just yet

great idea! thanks

we just missed a block because someone was mining to a lagging monerod instance: paste.debian.net/hidden/6fac52c9

one of those IPs there?

185.230.112.148

mined Monero block 2448479, but the network was already at height 2448484

any way to create countermeasures for this?

people need to fix their damn Monero nodes :D

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

XvB it seems sech1 again

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

yes, if it's more than 5 blocks behind

hadn't heard from them for a while, then all their blocks come at once paste.debian.net/1211578

but it was exactly 5 blocks behind

has happened a few times across the week

but how did we *miss* a block?

because it was too late to submit it

did that old block just force the rest of us to think that we should be on that .... oh

XvB's node soft-forked after that

submitted height H when monero was at height H + 5

it might be one of the reasons why we have more than 100% average effort

perhaps it should be 3 blocks and not 5 ... .shrugemoji

I didn't have this detection in logs until recently

side chain at 32 MH/s

right now we have 108.91% average effort over 94 blocks that have effort tracked

probability of this happening naturally is 22%

I suspect we missed a few Monero blocks because of this

or maybe we just had bad luck

I wonder if it's something on xmrvsbeast[m] node specific or we just notice cause hashrate accumulation

He needs to run monero with proper command line to avoid lagging

./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

well, bind/external bind part can be skipped

I use external bind to connect p2pool remotely, but only for whitelisted IPs

hmm, is it worth setting up a centralised monerod side chain? :D

another 24hrs no shares

hyc same

side chain hash rate is low atm, time to get some in

(and not get blocks mined!)

is this just a delayed effect of the hashrate being 60MH+ earlier?

Is the important thing here the `- "--add-priority-node=node.supportxmr.com:18080"`?

it's supposed to be a well-connected and fast node

so at least 1 peer will be good from the start

ban list is also important

Yeah, I use ban lists on all nodes

on my compose added a few known ones indeed

sech1: hmmm, logger is not detecting that logrotate moved the logfile

so it's still writing to the old one

I just got a load of 2021-09-13 12:16:02.373 E Transaction not found in pool

 

well I say just, about an hour ago

I think you should add a check of st_ino to make sure it's actually a different file

hyc github.com/SChernykh/p2pool/blob/master/src/log.cpp#L165

right

`2021-09-13 13:27:52.4625 P2Pool BLOCK FOUND: main chain block at height 2448496 was mined by this p2pool`

There we go :)

2448496 was mined by this p2pool

:_

i think the problem is that logrotate creates a new logfile so this existence check always succeeds

now if only I could get some shares :D

hyc so is that code correct?

not sufficient, no

I'll cook up a patch

well at least we found another block now

27 miners paid out, p2pool is growing

could do with finding a few more whilst I have 3 shares in the PPLNS window :D

Yeah my logrotate did something weird last night too. It started logging into p2pool.log.1 and left p2pool.log blank.

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.

links is a hack you can do

so you get both

Yeah I ln it in there but I thought that's what messed up my logrotate since it's pointed at the hardlink.

ah ok, so add nocreate to the logrotate conf to prevent this screwup

easier than patching the p2pool code

QuickBASIC: just delete the current p2pool.log file. it's prob empty right now anyway

then p2pool will notice and switch to a new logfile

and for now, just use a startup script that cd's to /var/log/p2pool before running

so, at what point do we figure the current sidechain is big enough, and tell people to configure a new sidechain of their own?

then no one will find enough blocks on that other sidechain, and most shares be left unused :)

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

hyc pretty sure sech1 said around 150 M/hs (5%) of network hashrate, then it might be necessary. (MoneroTalk podcast).

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.

i.e. Default Default-Low

can it max out on addresses hyc? it'll just average out and pay different shares each time

like it already kind of does

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

still will end up with same payouts anyhow

and might confuse people using it

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.

they will always be on the wrong chain

the other one will always either: mine more blocks, or give you more shares

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'.

So wrong chain indeed.

nothing is stopping you from setting a password and mining 100% of the shares :>

good luck finding a block though

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.

I was just joking that I got the shares on the "wrong" chain b/c we switched pools right after I got them lol.

Can anyone ping Cake Wallet on twitter? They still haven't updated to the latest Monero code

maybe an Issue on GH?

When they update, I'll start preparing for p2pool release

oh, they have github

27 issues open, 5 closed

PRs they do action on more

but seems that they are their own

Apparently they follow me on twitter so i was able t o DM them the issue and ask.

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

*fix his node

In case they're like me and don't see GitHub notifs until days later.

it will still have to use custom monerod at first, but I can include monerod binary

they ought to update to Monero v0.17.2.3 anyway because of other fixes there (decoy selection fixes)

no idea what takes them so long, Monerujo updated 5 days ago

maybe sech1 wait till PR merge, so at least you are not using a "monerod fork" but a "dev monero build"

no idea how long though

nice, but when

eventually (c)

soon (tm)

If you're using Matrix to join these chats, be sure to update your client immediately: matrix.org/blog/2021/09/13/vulnerability-disclosure-key-sharing

so I checked logs and found 2 more blocks that were wasted: paste.debian.net/hidden/80fb872d

3 blocks wasted today only, since I started logging it

oh no :(

maybe should have part of the notes about running properly connected monerod

no wonder we linger aroung 110% average effort

*aroun

*around

all these blocks follow the same lag pattern (XvB's node desyncs and then sends a lot of shares)

maybe it lags because it's checking the block very carefully

maybe I can connect a few nodes to it and force in new blocks :)

it's something with that node - it desyncs from Monero network and after that all hashrate goes to waste

I think the seed node I have connects with their node already

hmm, I think I'll add it as a priority node too

how do you know?

cause I added it as priority

(to monerod)

an alternative maybe it's that p2pool lags behind, but then XvB monero would submit it either way

failing to verify chains.

unless it lags everywhere

XvB's p2pool found that block and at that point it should've submitted it to monerod, but monerod was out of sync

I think the xvb node is just bad

so that block was orphaned by Monero network

3 blocks in the last 24 hours, not sure about earlier days

but it's probably the case we're at 110%

is xbv running their pool/p2pool node as public node too?

seems like p2pmd.xmrvsbeast.com:18080 is not really open?

multiple peeps accessing it could cause it to lag

it's better to separate public node and the actual mining node

all major pools do it to avoid DDoS

^this

mining node must be on a fast machine, preferable dedicated server and limit in/out peers like this: --out-peers 32 --in-peers 32

or it'll end up with 553 in peers like mine did :D

I have limits but higher than that heh

XvB's node might actually have more than 1000 peers and hit ulimit of 1024 open descriptors

OH

that could be interesting

553 is not far from 1024

restarting p2pool and monerod.

what error do you get on logs wssh ?

just failing to verify chains.

in monerod, or p2pool?

p2pool

and now p2pool crashes when trying.

can't find that error message on p2pool code, weird

you have free space on disk right?

tons.

3 300gb sas disks.

4*

paste your p2pool logs (10-20 lines before the crash) to paste.debian.net

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

ihttps://paste.debian.net/1211615/

can you add "--loglevel 5" to p2pool command line and try again? I need more detailed logs

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?

they also try to broadcast it

as they get the sidechain block from other p2pool peers

Cool cool. Thank you.

(this sometimes fails due to having unknown transactions on it, as transactions can take time to get across nodes)

which means XvB's node didn't broadcast these blocks when it found them, probably because it was lagging too much

lagging nodes wouldn't be a big problem on p2pool if all miners had the same hashrate

but lagging node with 96% hashrate is a problem

no crash this time.

So solution is adoption.

(and also please fix your nodes so they perform as it matters)

XvB is noticeable but smaller ones might also suffer if they lag and find shares that exceed uncle height diff

I've submitted a fix to make this issue less severe. It's recommended to update both binaries (p2pool and monerod)

sech1: seems like you brought changes from p2pool-api branch only right, not new ones?

I synchronized branches

yes, checked commit, it's not newer than the changes from 2 days ago I mean

p2pool-api is the latest version of monerod changs, p2pool-api-v0.17 now reflects it

great!

sech1: So p2pool-api is best branch moving forward? Want to rebuild my image shortly.

that is based off a version of master monero upstream

anyhow, fired several builds

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

So keep using apu-v0.17 branch?

yes

both branches should work fine

Thanks!

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 :)

My VPS is taking sweet time compiling Monero can I just compile locally on Ubuntu and scp the monerod?

if you build it right

if you build statically maybe, depends on architecture

something static

if you are VERY lazy I think you can grab an artifact from here? monero-project/monero #7891/checks?check_run_id=3575081687

contains monerod heh

gitian builds are static, they should run everywhere

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.

Had to snag the giant build b/c monero compile on VPS kept failing.

s/giant/gitian

got xmrig-proxy in front, which points to first p2pool instance, fallbacks to second instance elsewhere, then fallbacks on MO

Yeah I had fallback, but it's still syncing b/c installed SSD and didn't bother to copy Blockchain off old hd.

`v0.17.2.3-04bfd948a` is latest, correct? Just built.

sethsimmons yes, it's the latest

Thanks!

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.

Disable number of peers, disable incoming connections kind of

also if you have remote workers for mining, make sure they report only the necessary shares

pruned monerod too

other than that you do need the information coming from p2pool at least, that said, I am not seeing that kind of bandwidth usage

<DataHoarder> "also if you have remote workers..." <- How would I make remote workers only report necessary shares? is it an xmrig option?

Do not set any custom difficulty

that would be it

That said you should probably log traffic per port and see what uses the most, then adjust accordingly

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.