-
moneromoooo
8% orphans on the share chain atm. Looks like it shot up as more peers joined.
-
sech1
There is 1 or 2 peers with lagging monerod. btw I turned off my node, maybe this is one more reason
-
sech1
the more important metric is if _your_ non-lagging node has any orphans
-
sech1
hyc I've started mainnet p2pool, ~21 kh/s there from me. Instructions are on github
-
aypro
nice, updating right now
-
aypro
how do i switch branches btw ? for monerod
-
sech1
git checkout p2pool-api-v0.17
-
sech1
in monero folder
-
sech1
then build as usual
-
aypro
instructions still say "./monero-wallet-cli --testnet"
-
sech1
updated
-
aypro
i think i'm good, p2pool already banned 2 peers though
-
sech1
they're probably testnet peers
-
aypro
"Height: 2436207/2436207 (100.0%) on mainnet" " (height 2436207, your height 2436205). Is your monerod stuck or lagging?"
-
aypro
p2pool says i'm lagging, monerod says i'm sinced
-
sech1
-
sech1
you're lagging
-
sech1
network is on *207
-
aypro
yeah that's what monerod says
-
aypro
207
-
sech1
check your log, if you see "new miner data" messages
-
sech1
did you build both monerod and p2pool?
-
sech1
I changed ZMQ context name, so old p2pool will not sync properly
-
aypro
i did a git pull and then build
-
aypro
let me clear everything and build again
-
sech1
cat p2pool.log | grep -E 'height[ ]{2,}=' to see if it's syncing properly
-
sech1
or maybe you copied monerod binary from the wrong directory
-
sech1
it's in build/Linux/p2pool-api-v0.17/release/bin/
-
aypro
yeah i didn't get it from there
-
aypro
well i don't have that directory actually, maybe cause windows
-
aypro
i rebuilt p2pool and trying now
-
sech1
it should be similar path on Windows
-
sech1
p2pool-api-v0.17 must be part of the path
-
sech1
you can run this to check if everything is ok: cat p2pool.log | grep -E 'height[ ]{2,}='
-
sech1
then compare the output with what monerod says
-
sech1
ah right, you're on Windows...
-
sech1
then just open the file in notepad or something and search for the last "new miner data"
-
sech1
it seems you're still lagging
-
aypro
there's like 3 blocks lag again
-
aypro
i will clear the monerod folder and checkout again
-
sech1
but is it monerod lagging or p2pool not syncing with it?
-
aypro
p2pool is lagging behind monerod
-
aypro
monerod is synced with network
-
sech1
I need p2pool.log from you
-
sech1
can you zip it and share on some hosting?
-
aypro
yeah
-
aypro
-
sech1
p2pool binary is correct
-
sech1
but monerod is from wrong branch
-
aypro
i'll clear and rebuild monerod then
-
sech1
it should say "Monero 'Oxygen Orion' (v0.17.2.3-29309f08e)" on startup
-
sech1
double check the hex numbers that it shows there
-
sech1
aypro it's still lagging
-
sech1
did you check monero version it shows on startup?
-
aypro
Monero 'Oxygen Orion' (v0.17.2.3-unknown)
-
sech1
do you have "--zmq-pub tcp://127.0.0.1:18083" in monerod command line?
-
aypro
yes
-
aypro
no way i got the wrong branch, i cloned it from scratch
-
sech1
then open monero\src\rpc\zmq_pub.cpp, search for "json-full-miner_data" there
-
aypro
M:\monerod\monero (p2pool-api-v0.17 -> origin)
-
sech1
hmm
-
aypro
and then ?
-
aypro
{u8"json-full-miner_data", json_miner_data},
-
sech1
so it's there
-
sech1
don't know then
-
sech1
are you running p2pool now? Any warnings?
-
aypro
running without warnings
-
sech1
I don't see stale blocks from you anymore
-
aypro
i'll leave it running and check back later
-
sech1
last stale block from you was ~7 minutes ago, then you restarted and it's running fine now
-
sech1
nope, 3 blocks lag again
-
sech1
I'll build on Windows and check if it lags
-
sech1
aypro v0.17.2.3-unknown is incorrect. My Windows build shows v0.17.2.3-29309f08e
-
sech1
so you were building from source code in an unknown state
-
sech1
Oh hi xmrvsbeast! "TCP p2pool:37890->xmrvsbeast.com:56964 (ESTABLISHED)"
-
hyc
I'm building newest code now. my mainnet daemon crashed a while ago and needs to sync up again
-
hyc
(OOM'd)
-
sech1
p2pool-api-v0.17 should have the recent checkpoints, it will sync fast until block 2430000
-
hyc
hm, i used p2pool-api. should I build v0.17 instead?
-
sech1
hyc by the way I found the "real proper" way to shutdown TCPServer. It turns out, you can't call uv_close from other threads, it's safe to do only from the event loop thread
-
sech1
p2pool-api is fine, but it will sync slow
-
hyc
I'm at 2422500 already
-
sech1
then it's fine
-
sech1
latest code should have no memory/fd leaks
-
sech1
I fixed everything I could
-
hyc
glad you got that uv_close stuff sorted
-
gingeropolous
man i can't wait to try this out!
-
sech1
so why wait? Try it!
-
gingeropolous
i can't access my machines right now :(
-
sech1
-
sech1
We need more hashrate there
-
sech1
I'm almost 100% :D
-
gingeropolous
oh i'll be there. i've been mining solo for a while. it'd be nice to actually have payouts more frequently
-
sech1
10 second block time is much more stable, only 2 uncles so far
-
nioc
I can only imagine how happy and excited gingeropolous is right now
-
sech1
p2pool is at 50+ KH/s
-
gingeropolous
tis a dream come true
-
sech1
61.886 KH/s
-
hyc
I will be adding a mighty 2kh to it in about an hour or so :P
-
oliver_
someone could make post on reddit, about p2pool going on mainnet. that would surely attract more hashrate
-
aypro
sech1 can you post your windows build somewhere ?
-
aypro
monerod
-
hyc
we don't need to indiscriminatly add hash rate at this point.
-
hyc
we need competent users who can provide logs and debug info if they run into bugs
-
hyc
... I also added 8GB swap space to this node so next time it shouldn't OOM. it'll just slow to a crawl
-
sech1
if it lags 5 blocks or more, other peers will ban it
-
sech1
5 Monero blocks
-
hyc
I expect that such tight RAM situations will be temporary and will recover on their own
-
gingeropolous
the p2pool requires a lot of ram?
-
hyc
no
-
gingeropolous
ah
-
sech1
2.5 GB for best performance (RandomX dataset + 2 RandomX caches)
-
hyc
but my mainnet monerod on my rockpro64 died
-
sech1
0.5 GB for 2 RandomX caches in light mode
-
hyc
and has been slow to catch up
-
hyc
running p2pool on my mac, and macos has no hugepage support
-
hyc
so it's only lightmode\
-
hyc
prob should tweak that so full dataset mode is still possible, even without hugepages
-
hyc
ok, monerod sync'd, p2pool starting now
-
hyc
i wonder if |I should've deleted the old cache first. oh well
-
sech1
p2pool assumes nothing about cache contents
-
sech1
so it should just ignore it
-
hyc
ok. xmrig started up
-
hyc
hmm. p2pool is saying my mainchain height is lagging. but status on monerod shows correct height
-
aypro
ok, it's running fine now, i'll just stop reporting errors i guess
-
hyc
restarted, seems ok now
-
sech1
hyc is your monerod v0.17.2.3-29309f08e - this exact build?
-
hyc
no, it's p2pool-api branch
-
sech1
cat p2pool.log | grep -E 'height[ ]{2,}='
-
hyc
it's commit 710ed6e5ab782d79ee0b0d33032ed08dafeda913
-
sech1
It should show all new block heights it gets from monerod
-
sech1
that commit should be compatible
-
hyc
log is mostly full of testnet heights but got some mainnet at the end
-
sech1
you should compare with what ./monerod status says
-
hyc
yeah they disagreed height = 1796938
-
hyc
Main chain height = 1796938
-
hyc
Side chain height = 286618
-
hyc
Main chain height = 1796939
-
hyc
Side chain height = 286657
-
hyc
Main chain height = 1796940
-
hyc
Side chain height = 286686
-
hyc
Main chain height = 1796941
-
hyc
Side chain height = 286755
-
hyc
Main chain height = 1797156
-
hyc
Side chain height = 341652
-
hyc
height = 2436398
-
hyc
Main chain height = 2436398
-
hyc
Side chain height = 3147
-
hyc
Main chain height = 2436398
-
hyc
Side chain height = 3147
-
hyc
Main chain height = 2436398
-
hyc
Side chain height = 3164
-
hyc
height = 2436403
-
hyc
height = 2436404
-
hyc
height = 2436405
-
hyc
height = 2436406
-
hyc
height = 2436407
-
hyc
doh
-
hyc
was supposed to paste the url
paste.debian.net/1209321
-
sech1
2436407 is correct height
-
sech1
as of right now
-
hyc
it was stuck on 2436398 for a while, monerod showed correct height at the time
-
hyc
anyway it's correct now
-
hyc
I think i didn't have --zmq-pub set on previous monerod invocation
-
sech1
that would explain it :D
-
hyc
this says to me there's some redundant rpc info going across
-
hyc
if it was able to get the height correct initially, but not ongoing
-
sech1
no, it calls RPC once on startup and then relies on ZMQ
-
hyc
ok
-
hyc
but why does it need anything besides zmq then?
-
sech1
because ZMQ only send updates on new blocks, so it has to call RPC first
-
hyc
I thought the entire rpc API is already exposed in zmq
-
sech1
not even a 10%
-
hyc
no need to use old http rpc at all
-
hyc
oh well
-
sech1
zmq api is very rudimentary
-
sech1
it doesn't even have "submit_block", so I have to use RPC
-
hyc
that's a shame. I thought that was part of an entire FFS project
-
hyc
full zmq support of rpcs. oh well
-
hyc
someone sent an invalid txn? 61k, 0 fee
-
sech1
-
sech1
invalid txn? What's in the log?
-
hyc
2021-08-27 17:17:07.9352 StratumServer new block template at height 2436410
-
hyc
2021-08-27 17:17:07.9353 StratumServer sent new job to 1/1 clients
-
hyc
2021-08-27 17:17:45.7773 P2Pool invalid transaction: tx id = 8624b40eb5fbefe4f151716b3dacd8d22a8ad64313c4965dd5ce9cd7132d9c7b, size = 61130, weight = 61130, fee = 0.000 um
-
sech1
I had these glitches sometimes where monerod ZMQ notification for transaction has 0 fee or 0 weight
-
sech1
hmm, I also have 0 fee in my log for this tx
-
sech1
-
sech1
I think it's some bug in monerod
-
sech1
either old code or what I added
-
hyc
well, the logmsg only outputs 0.000 which is correct at 3 decimal places
-
sech1
hyc wait a minute... this is pre-RingtCT transaction
-
sech1
you can literally see amounts there
-
sech1
how is this possible?
-
hyc
interesting...
-
sech1
moneromoooo ^^^
-
sech1
we've got a block with pre-RingCT transaction:
xmrchain.net/block/2436411
-
sech1
on mainnet???
-
sech1
wtf is going on
-
hyc
\is this a coinbase txn?
-
sech1
no
-
sech1
maybe it's someone moving veeery old funds?
-
sech1
580 inputs/10 outputs
-
hyc
possible
-
moneromoooo
Is it causing trouble ?
-
sech1
p2pool didn't like it
-
sech1
because monerod said it had 0 fee in ZMQ notification
-
sech1
it's not critical, p2pool just ignores such transactions
-
moneromoooo
Well, they're rare, but allowed when you spend pre-rct outputs. We don't want to burn those.
-
sech1
yeah, it's just a transaction spending really old inputs
-
moneromoooo
I guess the 0mq serialization wasn't tested with those.
-
moneromoooo
vtnerd is the one to talk to.
-
sech1
the question is why 0mq notification has 0 fee for those
-
moneromoooo
I assume due to a bug.
-
sech1
most likely
-
sech1
core::handle_incoming_txs doesn't fill in the fee for such transactions, at least not until the moment it's sent to 0mq
-
sech1
no, it's a bug in zmq_pub.cpp
-
sech1
in the code I added
-
sech1
-
sech1
it only handles RCT transactions
-
hyc
ok, mystery solved, good
-
sech1
moneromoooo hmm, how to get the fee for pre-RingCT transactions. I have event.tx there which is class transaction with everything in it
-
moneromoooo
sum(inputs)-sum(ouputs)
-
sech1
oh, that simple
-
sech1
because they're in plain text there, right
-
sech1
need to fix that bug
-
sech1
actually, there is already bool get_tx_fee(const transaction& tx, uint64_t & fee) that should've been called there
-
sech1
pushed the fix, rebuilt and restarted monerod on both my nodes. p2pool handled it well, so you can restart monerod
-
hyc
ab89b179a6a6dd6b6c77dbaece0f7431f80707e2 has the fix?
-
hyc
ah I see it ok
-
sech1
yes
-
sech1
I saw these invalid tx before in my internal tests a few times, but had no idea what they were. They're rare.
-
hyc
sure, old coins prob don't move that often\
-
hyc
ok rebuilt my monerod too
-
sech1
and every time they move, fewer are left... So they'll end eventually...
-
hyc
off-topic: moneromooo, thought this might interest you
twitter.com/DecentralizedG/status/1431315395798052872
-
moneromoooo
Yes, it turns out most idea we have and think it's new, others had it before :D
-
hyc
I meant, it might be interesting to connect with other developers in the same space
-
hyc
so p2pool status shows next payout. How can this number be known in advance? doesn't it depend on the actual block reward of the next found block?
-
sech1
it's your payout in the latest p2pool block
-
sech1
so it is an estimation
-
sech1
it assumes that next payout will be the same
-
hyc
ok
-
garth
Build p2pool successfully on OSX 11.4 Big Sur (intel cpu) with a number of warnings:
paste.Debian.net/1209356
-
sech1
these are harmless. ScopeGuard stuff is actually intentional. I'll make a pass on the code to fix other warnings tomorrow
-
garth
👍