00:13:56 panic over? 00:39:07 Is there a way to make donations to the devs? 00:40:30 There is an address in the README.md file, and even a donate command in monero-wallet-cli. 00:41:00 There is also ccs.getmonero.org so you can choose what/who you donate to. 00:54:14 Thanks everyone for putting out the fire today 02:24:56 So, hf done done yesterday? 06:20:39 .merges 06:20:39 -xmr-pr- 6862 6875 6881 6882 6886 6891 07:17:10 .merges 07:17:11 -xmr-pr- 6886 11:44:40 I have a number of peers which report height 0 or 1 connected to my node, are these "asshole" peers? moneromooo 11:46:10 no 11:46:30 "asshole" peers will report your own height 11:46:55 Is it possible they are newly syncing peers? 11:46:55 If they continue to report that height after several blocks, though, I'd be inclined to call them asshole peers 11:47:07 Oh, I guess theres a specific kind of asshole you're talking about. Oops 11:47:13 It is possible that they are nodes with --no-sync 11:47:37 (if they show height 0) 11:50:45 Sometimes they report 0, possibly when they don't know your height yet. 11:58:36 yes, they were showing 0 but then changed to normal height 12:01:27 Maybe a simple way to detect is to tet them: report a bogus height and see if they echo it back 12:08:13 you can pop e.g. 200 blocks and start with --no-sync 12:08:21 if the peers show your height they are malicious 12:08:30 test them* 12:11:01 trying it now 12:17:45 that's A LOT of assholes: https://paste.debian.net/hidden/a67347a7/ 12:18:11 24 of 44 connected peers 12:19:37 a lot seem to come from the same subnets/ISPs 12:20:20 we should probably add subnet masking to the Ban command 12:20:23 what are they trying to achieve? Drop Dandelion++ transactions? 12:20:29 I did, for this very reason :) 12:20:50 They predate dandelion by a lot. 12:21:31 So what's their purpose? Track all transaction IPs? 12:21:41 nice stats sech1. Could you try the same test on larger sample of several hundreds nodes? 12:22:57 moneromooo: is that in current code? isn't in "help ban" text 12:23:03 I'm not sure I can lure more peers, but I'll try with --out-peers 128 12:23:52 Yes. It's been there for a good while now. 12:23:59 started with --out-peers 128 and --no-sync, let's wait for some time 12:25:03 I wonder if they're just using modified monerod code, or if something written from scratch 12:27:09 54.39 is owned by OVH 12:27:13 what's the criteria for being an asshole in this context? 12:27:28 node lies about its own blockheight 12:27:37 you can't sync from that node 12:27:39 always reports same as yours 12:29:00 Here's my current ban list https://paste.debian.net/hidden/0b76ef00/ 12:29:06 doesn't propagate txs 12:29:18 And yes, most, if not all, are OVH. 12:30:37 then we could prob report to ovh for sabotage/etc 12:31:17 at the least it would inconveniene these guys, drive up their cost to move to new hoster 12:31:23 could we detect the non-tx-propagation? Given long enough time sample so it's statistically significant, a node that doesn't propagate enough transactions compared to average/median/whatever of other nodes must be an asshole 12:31:35 if it never sends you anything 12:36:11 https://paste.debian.net/hidden/da371ec1/ 12:36:14 84 of 150 peers 12:37:14 iDunk I see they're in your list already 12:39:33 does anyone know how to add fail2ban rule for these? Any lines in the log to look for? 12:43:48 moneromooo would be nice to add some detection and print their IPs in the log, then it's easy to use fail2ban 12:44:09 monerod supports banning ips 12:44:16 Yes, it just needs to find a good way to detect them, because as soon as we do they'll start hiding. 12:45:03 And categorization by partial peer lists seem like a good way to me, it's just not obvious how to do it. 12:45:20 k-means maybe. 12:45:41 But peer lists are partial and evolving per node. 12:52:39 banning 114 IPs fron iDunk's list really helped, only a few asshole peers now 12:53:00 how are they asshole peers? 12:53:06 they're fake 12:53:15 don't sync, don't relay tx 12:53:33 would love to have an in at OVH and know who's doing this 12:53:46 if anyone reads this... :) 12:54:29 getting quite a few new IPs now 12:57:15 https://paste.debian.net/hidden/54cda36c/ 12:57:23 ^ iDunk + my node + sech1 combined into 1 list 12:57:33 not many more than iDunk’s list 12:58:13 so theyre surveillance nodes? 12:58:24 136 IPs in my iptables list now 12:58:41 still got 3 more connected so far :D 13:02:09 Is there an easy way to pass that to monerod as one bulk list? Might be good to keep growing it as an interim fix, especially for those with syncing issues due to it. 13:05:42 yea would be nice to have an option to easily specify ban list 13:05:53 ban list in iptables doesn't really help, monerod connects to them as out_peers 13:06:56 unless I add them as outgoing IP bans too... 13:09:53 pardon my ignorance... is there a node setting where you just listen and don't participate? is this just a normal configuration behavior? 13:12:40 by participate do you mean mining? 13:13:04 Also you are better off asking in #monero 13:13:06 relaying tx and serving old blocks 13:13:30 --no-sync in command line does that 13:13:42 but mirroring your own block height is not normal behavior 13:13:43 every node that is not synced will have that behaviour 13:14:26 v0.17.1.1 seems to have ended my issue with outgoing i2p peer connections dropping constantly, which was still an issue in v0.17.1.0 13:14:52 Ig I'm wondering if that was intentional as the github issue hasn't moved 13:15:14 MoneroArbo: it also got better for me but I don’t think much has changed code wise, maybe we just have more I2P and Tor peers now? 13:15:57 I have 7 I2P peers and 10 Tor peers 13:16:30 sech1: does iptables outgoing work for you? 13:16:39 works now 13:16:49 at least it shows blocked packets now 13:17:32 could be! but I'm definitely noticing a significant different between yesterday and today. Though even before that I noticed incoming peers would often stay connected for 100s of minutes while outgoing connections still dropped after at most 5 minutes. Which Ig means *some* peers were having successful outgoing connections. Anyway, totally better 13:17:33 now, I have outbound peers that have been connected for like 30 minutes 13:18:54 but sending over i2p / tor works quite well now, once we have seed nodes it will even be easier to setup 13:20:07 yeah I've been using it for awhile but I've been hvaing to add peers as priority nodes so it'd keep reconnecting. gonna try turning that off. and if it works for me still I'll close the github issue? 13:20:27 selsta looks like your ban list is almost complete, I've got only 4 new IPs so far 13:23:07 Via iptables outgoing, correct? Not via monerod bans? 13:23:18 iptables outgoing and ingoing connections 13:23:48 Is it possible to ban a list in monerod? 13:23:59 That would be more portable if we want to recommend this for others, since FWs vary so much. 13:23:59 not that I know of 13:24:24 26 peers connected, all good so far... 13:24:32 132 banned IPs in the list right now 13:24:55 You can do something like: 13:25:12 cat LIST | while read ip; do ./monerod ban $IP; done 13:25:28 Guess it doesn't work for windows. 13:25:47 but it's only temporary ban 13:25:48 also not persistent after restart 13:25:53 banning ips is just wackamole 13:26:14 I had 60% of connected fake peers before 13:26:17 this is serious 13:26:52 Quite the Sybil attack 13:26:54 aye, a bandaid is needed, sure. is a script up to scan and block these? 13:27:10 gingeropolous: we have a list of ips 13:27:20 no good way to ban them yet apart from firewall 13:27:30 4 more IPs again... 13:29:59 you could also write a custom rule for fail2ban that just takes a list of IP addresses 13:30:02 and lets it deal with them 13:30:10 https://paste.debian.net/hidden/20f43970/ 13:31:07 Wow those “asshole nodes” were almost all of my in peers 13:31:16 Down from 55 to 7 13:33:44 yes, I had 32 out + 51 in peers before, now it's 26 out + 3 in 13:34:11 gui bins are on website 13:35:27 anyone have access to this? https://www.sciencedirect.com/science/article/pii/S0020025518306728 13:35:54 my latest list with 138 IPs seems to catch them all so far 13:36:13 sech1: should we update dns today? 13:36:19 binaryFate: ^ 13:37:51 yes I don't see why not. Lot of people probably waiting 13:38:06 hrm, loki uses a PoW in its p2p to prevent sybil apparently: https://medium.com/@LokiNetwork/preventing-sybil-attacks-runes-pow-and-captchas-a358e241cff6 13:38:29 do you want to give it few hours to check everything is allright with that version? 13:39:03 up to you selsta and everyone who work on gui. My confidence is neutral/uninformed 13:40:55 yea it will depend on fluffy’s availability anyway 13:41:04 in the evening would be perfect 13:41:09 gives us a bit of time 13:46:31 gingeropolous: "loki uses a PoW in its p2p" 13:46:33 ^ no 13:46:58 sorry, just skimmed :( 14:03:08 I've put sech1's list into my outbound iptables as well 14:03:40 outbound is enough, it will prevent responding to any TCP connect handshakes 14:04:27 so only outbound list will do? I'll try 14:05:13 yeah. I created a new chain "junk", added DROP rules for all of those destination addresses 14:05:27 and forward to it from my OUTPUT chain 14:05:46 forward with which rule? They can use different port numbers 14:05:55 just protocol tcp 14:07:38 Hi, in the `cryptonote_core/blockchain.cpp` file 14:08:13 the case in line 3130 seems to overlap the case in line 3143 14:08:40 it seems the latter 'if' won't be triggered at all 14:09:10 on the mastre branch 14:09:59 Looks like a merge bug. And I did this so long ago I have no clue which one I meant now. 14:10:12 Thanks, I'll search for history. 14:10:26 ok, glad it's noted 14:11:24 coolhat did you run some static analysis tool to find this? 14:11:35 no I was just lucky 14:13:07 static analysis is good at detecting this type of bugs (impossible "if" conditions etc) 14:13:39 It can be removed, it's a duplicate. 14:14:04 While on static analysis, it'd be nice to have monero back on coverity, it occasionally finds real bugs... 14:14:34 what's needed for this? 14:14:36 core team has to set it up 14:14:57 https://scan.coverity.com/users/sign_up 14:15:00 "Sign in with github" afaik 14:15:17 it was already setup, did it expire? 14:17:12 afaik it was anonimal’s account 14:17:33 and he stopped updating his repo 14:17:39 ah 14:44:32 oh hmmm 14:44:43 I can do it from my account 14:44:53 it just has to be an org member right? 14:46:24 It would be better to be a core team account, to avoid the current state. 14:46:42 But any is better than none. 14:46:45 moneromooo: yeah - I meant that it has to be a member of the monero-project org 14:47:04 moneromooo: cat LIST | while read ip; do ./monerod ban $IP; done <- one can do that with a running daemon in background? nice 14:47:22 Installer still links to v0.17.0.1 for Windows GUI: https://downloads.getmonero.org/gui/win64install 14:47:30 sech1: cache probably 14:47:33 fluffypony: do you also have time for DNS hashes today / tomorrow? 14:47:58 M5M400: Yes. 14:48:06 Yup, darn cache always gets me... 14:48:07 ok I've added it - does anyone want email notifications for new defects? 14:48:16 also do we want the badge? 14:48:31 I used to receive coverity e-mails 14:48:53 I don't want email, I'd never see it anyway. As long as I can login from time to time and mark stuff as fixed or irrelevant. 14:48:59 I did too, but would prefer not to now. have no patience for the 99% false positives. 14:49:00 sech1: is that self-service 14:49:04 ok 14:49:33 no, I was just added somewhere at some point and started receiving them. Don't mind receiving them again. 14:49:57 I have no idea how to set this up so that it's automated 14:50:12 selsta: will do it tomorrow 14:50:33 Thanks. 14:53:37 I assume it's monero-project/monero ? 14:55:20 it should be sufficient to periodically poll all idle peers that claim to have our blockheight, and retriee the last N block hashes from them 14:56:33 that seems easily outsourced 14:56:51 but it will take time & compute resources either way 14:58:03 I guess could use a randomly generated list of block heights then 14:58:09 and a different list for each peer 15:02:20 another possibility might be to randomly generate invalid txns and send to them 15:02:37 then see if they send them back or correctly reject them 15:03:13 so the attacker runs 1 real node and then forwards 1k ips to that service 15:04:00 could probably even use the public remote nodes 15:05:20 yes, sybil attack can use one beefy node to serve data to 1000 fake nodes 15:05:42 ... but at least they are running 1 beefy node now, as opposed to none 15:05:50 right 15:07:33 i mean, a wacky idea would be to periodically use the monero network to "test" a random peer or a collection of peers. peers that are aggregating on the backend will have a different response than an honest peer ... perhaps 15:07:43 though dunno how a pine64 on a 5400 rpm would hold up 15:09:03 ... monero is technically a botnet 15:09:06 wondering if this an issue that might've been seen & solved on other networks or is it somehow unique to cryptonote / monero 15:09:24 it's a common problem for all p2p networks 15:09:51 torrent clients solve it by using peer rating 15:10:01 but it's easy for torrent, they can just verify downloaded blocks 15:10:36 what about bitcoin 15:11:00 easy to do, but perhaps no point 15:11:14 the objective is generally to spy on user privacy 15:11:20 but bitcoin has no privacy to begin with 15:11:36 ah I see I didn't know this was a privacy issue 15:11:52 there could be other objectives too, isolating a node from the real network 15:12:07 but that would be such a targeted attack most nodes wouldn't see it happening 15:14:07 the most obvious objective is to map the network and the propagation of txs, to track where they all originate 15:35:07 that makes sense thanks for the explanation 16:01:08 -xmr-pr- PostNZT opened issue #6919: Malwarebytes reports RiskWare.BitcoinMiner malware 16:01:08 -xmr-pr- > https://github.com/monero-project/monero/issues/6919 16:03:46 moneromooo: would you be okay with adding --block-list parameter to monerod that reads ips from file? if yes I will work on it, does not sound too difficult 16:05:07 Yes. 16:06:58 would be also nice to watch this file for modifications 16:54:50 why not in bitmonero.conf? 17:01:37 getmonero.org still has version 0.17.1.0 for Win64-bit posted. Need update to 0.17.1.1, Noticed when verifing hash. I felt the need to say something as Im the last person in the world to still be using windows and nobody else would ever notice. 17:03:23 StickyMann: try different browser 17:03:34 or private browser window 17:03:37 it is probably cached 17:08:01 ++ sech1 | would be also nice to watch this file for modifications 17:14:22 +selsta -- ty, that did it --- I SWORE I cleared that cache earlier.... 17:14:37 the cache is a bit too aggressive on the website 17:27:23 when I call block_host() with std::numeric_limits::max() I get a compile error suggesting to use unit16_t (which works) 17:27:41 but from daemon I can block for unint32_t::max seconds 17:27:54 from daemon meaning typing "ban ip -1" 17:28:53 hmm 17:28:55 found the issue 17:29:24 I was entering the port number, not the time :D 18:15:10 Who controls the travis setup ? 18:15:19 selsta: might be you ? 18:15:23 no 18:15:30 hmm 18:15:30 Do you know who does ? 18:15:32 luigi has access 18:15:36 ty 18:15:38 I think all of core 18:15:45 but luigi changed stuff for me 18:58:42 moneromooo: if I want to add config-file support for my new --ban-list flag, which file should I take a look at? 18:58:55 ./monerod --ban-list works now, but no idea about config file 18:59:39 It's automatic AFAIK. Never used it though. 18:59:52 selsta, what i've discovered with the config file is that you add multiple lines for an array 19:00:17 so, ban-ip=xxx 19:00:28 right 19:00:31 I had wrong syntax 19:00:33 it worked nice 19:01:24 oh does list point to a newline delimited file? 19:02:15 yep 19:04:29 did u make a script to identify the AHP? 19:04:46 i guess AHPs is how it should be typed 19:11:32 banlist already in? 19:11:34 nice. 19:11:51 PRed it but now reviewed yet 19:12:24 * M5M400 waves fist at lazy, slow FOSS coders 19:12:29 /jk 19:13:41 hmm does not seem to compile on linux 19:13:44 * selsta loves C++ 19:16:08 -xmr-pr- selsta opened pull request #6920: net_node: add --ban-list option 19:16:09 -xmr-pr- > https://github.com/monero-project/monero/pull/6920 19:18:33 selsta, so this is how you detected them? you can pop e.g. 200 blocks and start with --no-sync 19:18:33 if the peers show your height they are malicious 19:18:44 yes 19:19:12 sounds like its time for me to make some ugly bash scripts 19:19:45 nice the ips get read backwards lol 19:20:21 inb4 curl https://shitlist.moneroworld.com 19:21:39 yeah, we could do that. but you might as well run it yourself every n hours 19:23:22 ignorant question, if some people use the ban list option, will that result in those that do not use it having a higher % of AHPs? 19:24:04 don’t think so, these nodes don’t limit their in / out peers 19:43:24 selsta, how'd u get the height of your peers? from the log output, or is there a command? 19:43:35 sync_info 19:44:21 thanks 19:49:06 wow, i had 2 19:56:37 6920 compiles and works on Windows. 19:56:51 iDunk: force pushed, should still work though 19:57:07 previously the IP was reversed and compile failed on windows 19:57:12 both should be fixed now 19:57:17 s/windows/linux 20:00:48 All the peers gotten with sync_info with my same height are assholes? Because if that's the case i have 123 assholes out of 148 total peers 20:01:14 If your height is the current chain height, probably not :) 20:02:03 ErCiccione: you have to pop blocks e.g. 200 blocks and start with --no-sync 20:02:22 if they still show your height then yes 20:02:55 Aaah sure, makes sense. Got it now 20:04:42 I added the IPs in this list to my banned peers (iptables): https://paste.debian.net/hidden/0b76ef00/ is there a new one around that i missed? 20:05:43 updated, more than new 20:33:17 Hello, guys! My node stopped syncing on block #2210720 after upgrading to 0.17.0. In logs I can see following message: "2020-10-19 20:17:55.697 [P2P8] WARNING cn src/cryptonote_core/cryptonote_core.cpp:1956 There were 0 blocks in the last 90 minutes, there might be large hash rate changes, or we might be partitioned, cut off from the Monero network 20:33:17 or under attack, or your computer's time is off. Or it could be just sheer bad luck.". Any help? Thanks 20:33:45 you should upgrade to 0.17.1.1 20:34:16 Ok, I will try. Is it some hotfix in 0.17.1.1?) 20:34:21 you're experiencing a bug that is fixed in this new version 20:34:24 Yes 20:35:01 Got it! Thank you, guys 23:02:42 yes. this bug is fixed in 0.17.1.1 23:03:05 whoa, meant to send that way earlier. ignore plz