00:02:29 Here are some site that I've found helpful: https://monerodocs.org/ https://localmonero.co/knowledge https://www.monerooutreach.org/ 00:04:56 Also https://monero.stackexchange.com/ and reddit (in additional to the official site ofcourse). 03:40:24 Fork 2: Electric Boogaloo 05:29:09 Greetings, earthlings. 05:29:16 I wish to use both the Tor and the i2p-zero for a Monero node. Is this a good idea? I'd run it under Whonix so I2P can peer over Tor. 07:25:12 it's possible. however i don't see a rationale behind running i2p over tor, except wasting tor bandwidth 08:06:52 Any special 'trick' to get the daemon to hurry up and sync past block 2210720, or is it just a matter of waiting it out? 08:10:53 Blockchains are very un-funny, they don't offer such tricks ... 08:11:46 hehehe 08:12:21 Well... I thought maybe I could force it to connect to a safe, known peer or something that might help. 08:31:02 I'm being disconnected at block 2210720 despite running 0.17.1.0 08:32:56 Isn't this pretty bad? Is it happening to anyone else? 08:33:17 It's the v14 activation height 08:34:53 Height: 2210861/2210861 (100.0%) on mainnet, not mining, net hash 1.48 GH/s, v14, 8(out)+0(in) connections, uptime 3d 18h 41m 47s 08:35:05 on my v0.17.1.0 node right now 08:36:04 try cleaning your peer list 08:36:29 happening to me too ajsodasd 08:37:10 I removed ~/.bitmonero/p2pstate.bin. I'm checking again 08:40:35 sech1, just ban peers until you get some that are good? 08:40:53 seems all my peers are on 719 or 720 08:44:05 why would I ban peers if me node is good? 08:46:12 all my peers are at block 719 or 720 08:46:27 so I can't get past this height either 08:46:36 my peers: https://paste.debian.net/hidden/708df234/ 08:46:38 try them 08:46:53 how do I add a preferred peer? 08:48:09 some command line option, let me check 08:48:37 I am affected as well 08:48:50 --add-peer Manually add node to local peer list. 08:49:06 ah for startup 08:49:07 --add-priority-node ip:port 08:49:10 mkay 08:49:14 --add-priority-node=ip:port 08:49:53 you might need to change port number to 18081 in my list 08:50:03 this was just connections dump 08:51:40 or no, port 18080 08:51:45 I don't remember anything 08:52:51 sech1, can you type sync_info into your daemon and give me someone who is past block 720 08:53:47 https://paste.debian.net/hidden/8c224830/ 08:54:09 thanks 08:57:33 seems --add-priority-node is not helping much 08:59:18 try --add-exclusive-node 09:03:04 I've restarted my node with 25in/25out peers limit 09:03:08 maybe it'll help someone 09:03:23 also enabled port 18080 for incoming connections finally :D 09:03:48 This node is in Hetzner DC with 1 Gbit connection 09:04:10 hey peeps, can you guys be pals and check out my node list website? https://monero.fail/ add some nodes if you know of any 09:04:54 well, out of 26 connected peers almost all are synced fine at block 2210884 09:06:18 I just saw that I have the same problem syncing beyond 2210720 with a monerod compiled from master yesterday 09:06:19 All of mine show 2210720. Even the ones in your paste that are past 09:06:53 It sees many other daemons that tell it the correct height, but it seems it does not like their blocks? 09:06:53 do you run official binaries? 09:08:02 master had a number of commits since the release, so maybe one of them broke something 09:08:15 Latest master, compiled myself on Linux 09:09:15 compile release-v0.17, not master 09:09:36 I see quite a bit of difference in commits between them 09:11:23 I run monero-linux-x64-v0.17.1.0.tar.bz2 09:11:27 Yeah, no doubt that this will run. Still strange that master does not seem to be able to sync. I see nothing useful at first glance with set_log 1 09:12:11 The only "Error" lines (in red) are: Setting timer on a shut down object ... 09:14:08 "monerod is now disconnected from the network" when I connect to peers at 2210888 09:14:18 I might be wrong but i don't think master should be used untill it gets the commits from the branch 09:16:24 Would it be fine to try out monero-linux-x64-v0.17.0.1.tar.bz2? 09:17:54 *17.1.0 that is the current version yes 09:17:56 I run 0.17.1.0, it should be preferred 09:18:46 I wanted to try in case that version can actually sync 09:19:03 any 0.17 version should sync 09:19:12 I am running the gui version and not able to sync 09:19:35 Height: 2210720/2210720 (100.0%) on mainnet, not mining, net hash 1.47 GH/s, v14 (forking now), 8(out)+18(in) connections, uptime 0d 0h 3m 24s 09:19:57 version 09:19:57 0.17.1.0-release 09:20:18 There were some sync problems in precedent versions of the GUI that should be resolved with 0.17.1 afaik. 09:20:29 Oh you are using that one already 09:20:46 yeah 09:20:49 0.17.1.0-release and I cannot sync 09:21:16 Someone posted this issue to Reddit too it seems 09:21:32 even added a bunch of priority nodes that supposedly show they are synced past 720 but my node ignores it or something 09:21:43 same 09:21:47 Selsta xiphon any idea? ^ 09:21:50 I added nodes from sech1 09:22:01 https://paste.debian.net/hidden/8c224830/ 09:22:16 tried --db-salvage too but it did not do anything 09:22:26 now when I do sync_info these nodes show up to 720 09:22:43 Mochi101 try to clean your peers again, stop monerod, pop a few blocks and start syncing again 09:23:13 try supportxmr node as an exclusive node 09:23:36 maybe to fix this try to pob blocks before the v13 fork and then start with "--add-exclusive-node" just until you are synced past 720.. 09:23:38 or better pop 1000 blocks to be sure 09:24:42 Mochi101 was your node running through the both fork heights? My node didn't restart since October 15th 09:25:06 nah... this is just my local node... I turn it on only when I need it 09:25:10 my other one was fine 09:25:13 I somehow doubt that it's bad peers. I went up to "out_peers 50" but still no luck. 09:25:22 bitinfocharts.com is also stuck on the old chain^^ crazy though there are 2200+ tx in the last 24h and moer than 300blocks 09:26:18 hmm seems good so far with pop-bloocks 1000 09:26:51 Try the same. Of course it syncs the V12 blocks now, but let's wait 09:26:52 spedex Did it sync past 2210720? 09:28:08 https://miningpoolstats.stream/monero is also stuck, it shows difficulty 232.04G which is outdated 09:28:44 but on the other hand, it shows that all pools are doing fine 09:28:47 not quite there yet :) maybe 1000 was a bit excessive 09:28:50 but let's see 09:30:12 https://paste.debian.net/hidden/d1fd98c3/ 09:30:18 I don't see many problematic peers 09:30:30 no stuck again: Height: 2210720/2210720 (100.0%) on mainnet, not mining, net hash 1.47 GH/s, v14 (forking now), 7(out)+19(in) connections, uptime 0d 0h 4m 24s 09:30:38 No luck with my master-compiled daemon after dropping 1000. 09:30:57 trying to sync after popping 1000 blocks and with preferred nodes 09:31:09 er...priority-nodes 09:31:22 takes a bit... will let you know 09:32:09 I am really curious whether using known-good priority nodes will work. Somehow I doubt it. My daemon sees many other peers with the correct current height and still does not seem to want blocks from them. 09:33:16 Yes, it just says "monerod is now disconnected from the network" when I connect to peers at correct height 09:34:56 I tried to pop 1000 blocks, use the supportxmr node as an exclusive and it's the same 09:35:30 Alright, I compiled 0.17.1.0 in the meantime. Same problem. 09:36:10 That can't be good ... 09:36:21 nope 09:36:39 strange I have one node that is good... and my local node is bad 09:36:55 and both run official binaries? 09:36:59 yes 09:37:07 then it's something local 09:37:11 but the good one is linux and my local is windows 09:37:50 the good one was running the whole time though 09:38:13 so what if you stop the good one, pop 1000 blocks and start again? 09:38:27 nfw 09:38:34 Well, maybe, for whatever reason, it's not possible *anymore* to sync past that block. No conspiracy theories, I know, but what if somebody manages to disturb the network enough now? 09:38:43 That is part of my critical infrastructure. 09:39:04 I can try it with my node :shrug: 09:39:27 what was the command to pop blocks? 09:39:35 ok..popped 1000 blocks...added like 6 priority nodes and resynced... still can't get past block 720 09:39:52 ./monero-blockchain-import --pop-blocks 1000 09:40:05 1k is too much 09:40:07 do 100 09:40:12 or wait forever 09:40:14 :D 09:40:27 No, 100 won't get you back to V12 blocks ...? 09:40:43 ok 09:40:59 1k then 09:41:24 Who was writing yesterday that Monero forks are oh so boring, nothing bad ever happens with them :) 09:41:31 ummm 09:41:34 dunno 09:41:36 :D 09:42:07 Maybe it helps to whisper "moneromooo" 3 times? 09:42:07 all right, syncing again 09:42:24 Height: 2209905/2210905 (99.9%) on mainnet, not mining, net hash 1.87 GH/s, v12, 17(out)+0(in) connections, uptime 0d 0h 0m 28s 09:43:34 damn, this is slow 09:43:40 I'm on HDD by the way 09:43:42 Big blocks now 09:43:57 To add suspense? :) 09:44:31 Also syncing from scratch on my Windows PC, but that one is R7 3700X + 32 GB RAM + Samsung 970 Pro NVMe SSD 09:44:31 fuck windows, use linux! 09:44:36 fuck Quotes 09:44:49 Definitely. 09:45:57 2210305, place your bets... 09:47:12 bad news 09:47:17 all my peers are 2210720 or below 09:47:48 good news, not all 09:48:46 2210645... 09:48:54 i have count load of peers all on 2210908 09:49:20 aaaannnddd... I'm stuck at 2210720 09:49:34 #metoo 09:49:38 fuck you all 09:49:49 calm down 09:50:04 We're not in pools. 09:50:08 3hehe 09:50:09 hehe 09:50:30 now I'm curious. updating my local toynode 09:50:38 what if this chain (past 720) is not the real chain at all? 09:51:01 "real chain" 09:51:03 :D 09:51:13 or maybe it's just syncing code that's broken 09:51:17 put ya back in chains 09:51:21 so better not restart working nodes 09:51:34 until moneromooo fixes it 09:51:58 910 09:52:22 blocks coming okey, 09:52:50 I even add M5M400's node as an exclusive node... doesn't do anything 09:53:02 ok, now my node banned everyone who's past 2210720 09:53:26 2020-10-18 09:53:13.920 I Synced 2175013/2210910 (98%, 35897 left) 09:53:39 M5M400 it'll get stuck at 2210720 09:54:08 ok let me sync again for test 09:54:22 popped some blocks on linux trying to reproduce 09:55:06 for all we know, restarting node might get it stuck at block 2210720 and probably further blocks if they have the problematic data in them 09:55:47 I think I found the problem: https://xmrchain.net/tx/c5151944f0583097ba0c88cd0f43e7fabb3881278aa2f73b3b0a007c5d34e910 09:55:51 this tx shouldn't be there 09:56:10 maybe running daemon allowed it, but syncing code rejects it 09:56:29 rbrunner can you recompile the code, but change 2210720 to 2210721? 09:56:33 why shouldn't it be there? 09:56:33 as a fork height 09:56:42 Mochi101 because it's MLSAG 09:56:49 2210720 and up should be only CLSAG 09:57:54 mlsag tx in clsag only block? :D 09:58:02 seems like it 09:58:51 one more: https://xmrchain.net/tx/6f2f117cde6fbcf8d4a6ef8974fcac744726574ac38cf25d3322c996b21edd4c 09:59:22 can't sync after 720 too on linux my node was fully synced before and was online the whole time during both forks 10:00:10 yep, my node was fully synced and was running through both fork height 10:00:19 then I popped 1000 blocks and now can't sync past 720 10:00:38 so I put my bet on an off-by-one error somewhere in the code 10:02:44 Alright, can try that alternative fork height in about 1 hour, busy with lunch now ... 10:08:41 that brings an interesting question. The fix will be a consensus change. Granted that we in fact have 2 different fork heights in the code now, it can also be considered just as a fix, not a consensus change. 10:09:10 so we change from 2210720 to 2210721 if someone (rbrunner) confirms 2210721 works for syncing 10:14:45 How come it was fine for some nodes and not others though 10:16:04 Stuck at 2210720 too 10:16:29 Me too! 10:16:52 sech1: How did those transactions managed to get included in a block? A one off? 10:16:57 Mochi101 it was fine for everyone who was online 10:17:09 yes, I suspect an off-by-one error in the code that handles incoming blocks 10:17:16 but syncing code doesn't have this error 10:17:30 so they don't agree and we get this clusterfuck 10:17:44 I see 10:18:17 it wasn't an issue past few forks because old type transactions weren't issued at all after the first fork 10:18:23 but this time, they kept coming in 10:18:50 Tried already. Maybe your intuition about one-off error is correct, but by merely changing the fork height from 2210720 to 2210721 does not seem to help 10:18:56 0.17 should've rejected MLSAG right after 2210000 10:19:05 Stuck at 2210720 too. What can be done? 10:19:08 Presumably due to old wallet software being connected to an updated remote node? 10:19:23 fort1: Wait for a fix to be released I guess 10:19:52 rbrunner are you still stuck at 2210720? Tried connecting to known working nodes as exclusive peers? 10:19:59 my peer list all at 2210720! 10:20:04 so I should avoid restarting pool nodes, right? 10:20:14 yeap 10:20:20 Stuck yes, tried with good nodes no 10:20:21 M5M400 don't restart until moneromooo tells more 10:20:41 Right now it's just my speculation on what's happening under the hood 10:20:49 * jonathancross sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/taCuuJlouOYAXgaoSFddRyiu/message.txt > 10:20:55 but MLSAG transactions in block 2210720 is certainly not ok 10:20:55 oki, thanks @dEBRUYNE 10:21:43 * jonathancross sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/nanqdCFcqGLCSuItZSpAruht/message.txt > 10:22:27 jonathancross: Those messages aren't getting through properly 10:22:36 They are displayed as links 10:22:44 @dEBRUYNE, should I keep the node running, or it does not make sens? 10:23:32 If it is stuck, I guess it doesn't make much sense to keep it running 10:23:39 oki 10:24:17 my 2 nodes are still fine, were running thru the fork 10:24:40 was also mining 10:24:48 few hundred H/s 10:24:55 What if ... moneromooo is on vacation for 1 month on some island in Townforge? :) 10:25:04 M5M400, when I connect to node.supportxmr.com as an exclusive node it doesn't seem to connect 10:25:54 hyc, you have an open node? 10:25:55 dEBRUYNE: just saying my linux node is syncing fine with release binaries. 10:25:55 (Hopefully you can see this?) 10:25:59 set loglevel to 1 10:26:07 Going offline now 10:26:19 Mochi101: yes, 173.255.205.142 10:26:49 jonathancross: Did you keep it running or? 10:26:55 hyc, 18081 ? 10:27:45 we need to confirm if changing 2210720 to 2210721 in hardfork.cpp helps 10:27:49 Mochi101: if you're doing --add-exclusive-node, you should use the p2p port (18080) 10:28:02 It'll take 6-10 hours for me to check... Syncing from scratch here 10:28:03 that's probably why node.supportxmr.com didn't work for you 10:28:09 ok 10:29:02 sech1: That should also work by using a synced chain and popping blocks, no? 10:29:17 Also, rbrunner reported this: 10:29:17 Tried already. Maybe your intuition about one-off error is correct, but by merely changing the fork height from 2210720 to 2210721 does not seem to help 10:30:28 I had a working node, then I popped blocks and it's not working now 10:30:47 2020-10-18 10:30:22.108 E Ringct type 4 is not allowed from v14 10:30:47 2020-10-18 10:30:22.109 I Transaction with id= <6f2f117cde6fbcf8d4a6ef8974fcac744726574ac38cf25d3322c996b21edd4c> has at least one invalid output 10:30:47 2020-10-18 10:30:22.109 E Transaction verification failed: <6f2f117cde6fbcf8d4a6ef8974fcac744726574ac38cf25d3322c996b21edd4c> 10:30:47 2020-10-18 10:30:22.109 I transaction with hash c5151944f0583097ba0c88cd0f43e7fabb3881278aa2f73b3b0a007c5d34e910 not found in db 10:30:56 ok... so sech1 is correct it seems 10:31:35 yep, these 2 transactions in block 2210720 10:32:06 I popped 100 blocks, set log level to 1 and used a known good node as an exclusive 10:32:16 I had already some syncing problems with v0.16.0.3 about 1 week before the fork. Earlier it worked perfectly. 10:32:49 M5M400, are your blockchains pruned? 10:32:54 nope 10:33:01 pruning is for plebs 10:33:02 My working one is pruned. 10:33:06 :P 10:33:35 syncing so sloooow 10:33:51 Mine is not pruned 10:34:44 my public node is now pruned, because I ran out of disk space 10:35:01 and couldn't justify bumping up to the next size up Linode 10:35:06 Why if I pop 10 blocks and use a known good node as an exclusive does it still not sync though? 10:35:18 because there is a bug. 10:35:42 wasn't there a way to skip verifications for trusted sources? 10:36:07 or was that just for importing the .raw? 10:36:29 Email me your blockchain please M5M400 10:36:30 just for importing .raw 10:36:39 but that's a good idea M5M400 10:36:54 we can do an export of 2 blocks 10:37:08 and post that .raw file so people can import and get past the error 10:37:26 is it possible? 10:37:28 I'll try that now 10:37:29 didn't know partly exporting is possible 10:37:38 yes of course it is 10:37:47 well, great :) 10:37:54 obvs 10:37:55 :P 10:38:00 ;) 10:38:19 Why 2 blocks, is 1 block not enough? 10:38:29 sech1: just in case. 10:38:57 but unfortunately, while export has a --block-stop option, it has no --block-start option. crazy. 10:39:00 I don't see any MLSAG transaction after 2210720 10:41:01 looks like I can only do an export starting from block 0 10:42:18 feature request time! 10:43:07 hyc just hack monero-blockchain-import to add block 2210720 unconditionally 10:43:34 Instead of shipping a db file, wouldn't it be possible to just write a script to send stuck nodes the block as if it's live? 10:44:24 *I understand it's not exactly that simple. My guess is you'd also need to do transmit the TXs so they enter the mempool (my first, uneducated guess, at why this split happened) 10:45:08 imagine if you could just slip a block into the chain at will 10:45:18 But if you lie to one stuck node saying it's new, wouldn't it rebroadcast it to any others it knows as well? Gets the current stuck nodes going again/provides a script to run to fix the problem? 10:45:28 oh! Here's one that give me 100000 XMR! 10:45:41 thinking so small, Mochi101 10:45:45 kayabaNerve: it would need to skip the verification 10:45:56 I think the fix basically needs to make those two transactions seen as valid 10:45:57 asymptotically: Not if we replicate the original conditions? 10:45:59 And use the MLSAG verification rules 10:46:10 Live nodes didn't fail. 10:46:28 I'm asking if it's possible to ejust tell the stuck nodes it is live. 10:46:38 dEBRUYNE that fix is better than changing fork height, but we also need to find the actual bug and fix it 10:46:39 Send the TXs so they enter the mempool, as if they're pending, and then sync the block. 10:46:55 So it fixes the current network before needing to ship out a new release for anyone syncing in the future 10:47:10 Mochi101 going by your debug output from before it should be enough to add a rule in cryptonote_core/blockchain.cpp:3070 to allow that transaction hash. 10:47:16 *And means existing nodes don't HAVE to upgrade so quickly/articially edit their DB files 10:47:23 unfortunately the .raw file format doesn't include block number in each block 10:47:42 so -import just counts all blocks in the file, to assign block number to each record 10:47:52 hacky. 10:48:02 wow 10:48:03 hyc rewrite monero-blockchain-import to import single block? 10:48:04 so the only way to import block number X is to have (X-1) records in front of it 10:48:17 Couldn't you use the last hash from the header? 10:48:44 *Still breaks compatibility. Just less so then a new format 10:48:53 Thought it sounds like a new method is being discussed... 10:48:56 hmm, I have one more thought. What if someone tries to use these 2 MLSAG transactions as decoys? Won't it break something again? 10:50:20 MLSAG outputs are still allowed as decoys no? 10:50:30 It's not like the non-RCT -> RCT change where you basically have two pools of outputs 10:51:29 * dEBRUYNE may be wrong here 10:52:10 ^ This transaction also uses MLSAG outputs as decoys -> https://xmrchain.net/tx/e610bfb45f2ca4c57d8bee35f3d99eb1d275c49b9e0c5770f86e603d7865f0da 10:52:14 yes, they should be allowed anyway 10:54:00 Guess we'll see v0.17.2.0 soon lol 10:54:40 when it rains, it pours. 10:57:42 ok, this isn't so horrible. the raw file header format has fields for block start. it's just that export inits them to 0 and import ignores them 10:57:57 but we can add support for them without having to change the raw file format 10:59:05 * Mochi101 starts writing an e-book, "The Day hyc Saved Monero" 10:59:33 right in the feels. 10:59:41 lol 11:01:13 can I be the one pretending to be his brother claiming that it never happened? 11:01:21 for sure 11:02:05 That'll give it some real depth. 11:07:12 is moneromooo in US somewhere? Still sleeping? 11:08:16 mooon 11:09:17 They are usually online at current daytime 11:09:20 hi, I'm here now 11:09:43 2210720 has 2 MLSAG tx 11:09:46 welcome to the party moneromooo 11:09:47 nodes can't sync 11:10:18 That seems... annoying. 11:10:24 A little. 11:10:36 but nodes that were online are at 2210950 now 11:10:41 so network kind of keeps working 11:10:55 just outdated nodes can't sync 11:11:27 my guess is an off-by-one error that allowed MLSAG in 2210720 11:13:00 moneromooo, if you want some relevant log: https://pastebin.com/LZ4Z9bSq 11:13:45 It's using a known good exclusive node 11:15:08 dEBRUYNE: care for some visible PSA on /r/monero if not there yet already? 11:15:10 adding an exception for these two transactions would allow nodes to sync. Or changing v14 height to 2210721. But I'm more worried about where this off-by-one error is hiding. 11:15:55 Happy Sunday everybody. 11:16:37 i am not a fan of adding an exception for 2txs betther then off by 1 11:17:04 changing v14 height is a more clean "fix" for sure 11:17:31 I just can't test if it really works, still syncing at 16% here 11:17:39 But that fork height fix only starts to work after most daemons put it into service, right? 11:17:44 M5M400: Seems like a good idea, not sure what to put there though? 11:17:59 rbrunner it'll start to work for anyone who's stuck and applies it 11:18:22 and then syncs using known working nodes 11:18:30 Not sure, I did try that. Edit the fork height, compile, try, yes? 11:18:45 --add-exclusive-node ??? 11:19:12 and clear p2pstate.bin before that too 11:19:14 No. You mean I can't rely on nodes that tell me the correct current height to be "working"? 11:19:27 Because I have plenty of those. 11:19:28 rbrunner: Did you check if you were connected to a node that is actually past the 'stuck' height 11:19:34 just changing hardforks.cpp won't do the trick (at least for me) 11:19:40 if they tell you correct height above 720, you should be able to sync 11:20:07 Yes, that's what I mean. I had several nodes announcing the correct current height to my daemon, which did not budge. 11:20:16 we need to send out a message on monero-announce list soonish IMO. If we don't come up with specific plan within an hour or so, I'll just send a general warning 11:20:34 ah I think I know why 11:20:42 Version in block info? 11:20:43 because they already tell that 2210720 is v14 11:20:47 yep. 11:21:04 so these 2 tx must be added to the code as exceptions 11:21:05 binaryFate: ++ 11:21:18 sech1: yep thats the same log output i had 11:40:38 Apparently monero php library isn't working anymore after new changes. Most wallet RPC functions accepting arrays are failing. An example: 11:40:48 Request have return error: Parse error. Request: {"jsonrpc":"2.0","method":"make_multisig","params":{"multisig_info":[null,null],"threshold":2,"password":"mypassword"},"id":0}; 11:46:54 you got asked this a lot already I'm guessing. I'm running several nodes, one of them got stuck at the second fork block 2210720. 11:46:59 I need to wait for a patch? 11:47:34 yes, it requires a patch to sync after 2210720 11:49:29 but a different node synced just fine 11:52:28 yes, depends if it was running during fork and had 2 specifics tx in its mempool at that time 11:52:31 nodes that were online did fine, nodes that were offline can't sync now 11:53:50 none were offline though, just saying 11:54:10 aubergine: Are you already on the latest release 0.17.1.0. I am not sure, but I think there was a fix for that RPC problem. 11:56:26 https://paste.debian.net/hidden/80c30661/ fixes it 12:03:03 btw is there some open source tool for making a pool ? 12:05:30 QUESTION: Problems Syncing my monerod v017.1.0 , stuck at block 2210720, new top block candidates get added. assumption: is this problem on my side ?. 12:05:59 No, new version will be out soon. 12:06:06 k, thnks.. 12:06:07 If you know how to compile yourself you can fix it now 12:06:27 https://github.com/monero-project/monero/pull/6906 12:06:44 k, Network still OK, just client problem right ? 12:06:57 Network still okay, just new nodes can’t join it 12:07:10 (without applying this patch) 12:07:33 @Freneticks I think this might be outdated (https://github.com/Snipa22/nodejs-pool) but MoneroOcean maintains a fork at (https://github.com/MoneroOcean/nodejs-pool). There's probably other forks floating around, Idk, but I think most pools are using some version of this nodejs-pool 12:07:49 k, thnks, have a nice Sunday ... 12:11:07 MoneroArbo: nice thx ! 12:21:13 @rbrunner yes no new updates yet 12:27:12 So I'm curious how this fork issue came about -- a bug or some more fundamental issue? 12:28:18 See the commit message. 12:30:11 https://github.com/monero-project/monero/pull/6906 12:30:36