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