00:16:46 <h2017> my node is not staying up
00:17:38 <wfaressuissia[m]> h2017, details ?
00:17:48 <h2017> 8G on the box
00:17:56 <h2017> monero is the only thing i'm running on it
00:17:59 <h2017> monerod
00:18:42 <wfaressuissia[m]> define "not staying up"
00:18:57 <h2017> it appears to completely die without any log messages
00:19:01 <h2017> it gets restarted
00:19:28 <h2017> it's only lasting for 10 minutes at a time
00:19:53 <h2017> Height: 2259551/2259551 (100.0%) on mainnet, not mining, net hash 1.71 GH/s, v14, 11(out)+16(in) connections, uptime 0d 0h 2m 22s
00:20:05 <wfaressuissia[m]> which ports are opened ?
00:20:08 <h2017> says it's only been up for 2 minutes 22 second
00:20:15 <h2017> just the p2p port
00:20:24 <selsta> we are looking into it, please keep restarting for now
00:22:25 <wfaressuissia[m]> 10 minutes period is quite short, can you restart with "--log-level 4" and share logs after unexpected restart ?
00:22:35 <h2017> sure
00:24:31 <h2017> hold on i'm going to make an adjustment to make this easier for me
00:31:26 <h2017> wfaressuissia[m],  no logs for now. it looks like others are looking into this.
00:37:14 <wfaressuissia[m]> good luck with debugging then selsta and others
02:20:48 <camalonso> my node is behaving REALLY bad, it runs few minutes and then starts grinding and consuming all memory. Eventually it either crashes or i'll force it to restart. Nothing special in logs. How to debug this?
02:23:34 <selsta> camalonso: be patient please, we are looking into it
02:29:51 <agentpatience> all nodes will be going down.
02:30:44 <selsta> agentpatience: it will be fine
02:55:24 <wfaressuissia[m]> minexmr/support has closed incoming connections from Tor, nice workaround
03:00:18 <wfaressuissia[m]> soon Tor will be blacklisted by everywhere
03:00:30 <wfaressuissia[m]>  * soon Tor will be blacklisted everywhere
03:31:26 <hyc> this is just a temporary measure until a good patch can be written and teste
03:31:27 <hyc> d
03:45:09 <h2017> this is rather more serious attack then the previous ones since killing nodes is a serious thing
03:45:24 <h2017> sorry i suppose we shouldn't be discussing it
03:45:34 <h2017> my bad
03:46:38 <selsta> it is okay now
03:46:42 <h2017> anyway it's a growing pain on the way to the moon
03:46:44 <selsta> we have what we want
03:46:57 <h2017> it's only getting attacked because it's a high value target
03:47:42 <h2017> sorry i thought was on #monero-markets too
04:21:33 <wfaressuissia[m]> Tor nodes are cheap but easy to ban so this attack wasn't very serious
04:33:01 <wfaressuissia[m]> h2017: to be serious you need to kill at least all nodes belonging to mining pools
04:33:09 <wfaressuissia[m]> after that all nodes with opened p2p port
04:33:37 <wfaressuissia[m]> that's about 50 nodes for pools (known to me) and 1200 general purpose nodes belonging to some stanges
04:36:39 <camalonso> attack vector is rather serious though
04:37:56 <wfaressuissia[m]> serious enough to gather money through CCS for proper fix ?
04:38:00 <wfaressuissia[m]> or so-so
04:43:13 <wfaressuissia[m]> What are the limitations of this OOM killer ? Does it kill only cheap nodes ?
04:43:35 <wfaressuissia[m]> only minexmr nodes have been killed ?
04:49:02 <dgoddard> no any monerod that gets the wrong peer goes down
04:50:47 <dgoddard> just apply selsta's new ban list and you're fine for now https://gui.xmr.pm/files/block_tor.txt
04:51:06 <selsta> the tor exit node list is not complete, so it might still crash
04:51:12 <selsta> will update the list with a more complete list
04:51:35 <selsta> hmm wait
04:57:18 <ackroydai> MoneroOcean has been acting strangely this last week while mining
04:57:57 <wfaressuissia[m]> MoneroOceas using the most cheapest virtual machines
04:58:59 <wfaressuissia[m]> pruned db, slow hdd / cheap ssd, 2-4 GiB of RAM
04:59:19 <ackroydai> Thats's an interesting point...
05:00:51 <wfaressuissia[m]> All low end mining pools must keep p2p port closed by default
05:01:54 <wfaressuissia[m]> and high end pools instead of blacklisting Tor should spend part of their resources on better infrastructure and CCS donations in order improve codebase
05:02:13 <wfaressuissia[m]> but in reality: big pools blockhole Tor and smalls stay with opened p2p port for everyone :D
05:02:24 <selsta> blacklisting Tor is only a workaround until we have a patch
05:03:07 <ackroydai> Agreed blacklisting might be a type of whack-a-mole
05:03:12 <wfaressuissia[m]>  * but in reality: big pools blacklist Tor,  small pools are trying to stay with opened p2p port for everyone :D
05:04:39 <wfaressuissia[m]> good that there are only 2 major pools not 30, easier to cooperate and act synchronously
05:15:19 <wfaressuissia[m]> selsta, Can you publish an example of artificially crafted p2p packet ?
05:18:26 <h2017> wfaressuissia[m], it doesn't matter. we understand the nature of the attack. it's no different from allowing an arbitrarily large input and someone taking advantage of that
05:18:56 <h2017> programmers often don't notice when they leave that kind of attack available
05:19:17 <wfaressuissia[m]> h2017: there are limits in software of packet that can be consumed, processed and freed at once in order switch to the next
05:19:24 <wfaressuissia[m]> 100MiB for network packet, 100 recursion limit
05:19:27 <h2017> yes
05:19:57 <wfaressuissia[m]> only number of incoming connections is unlimited
05:21:26 <wfaressuissia[m]> I've been waiting for this malicious peer with opened p2p port
05:21:51 <wfaressuissia[m]> 49 out/ 12 in, nothing interesting 600MiB of RAM
05:23:38 <wfaressuissia[m]> only regular "Failed to handle NOTIFY_REQUEST_CHAIN", but these are unrelated
05:24:12 <nioc> Default out is 12, do you mean 12 out and 49 in?
05:24:25 <wfaressuissia[m]> I have out 2048
05:24:30 <nioc> Ok
05:24:33 <wfaressuissia[m]> in order to speed up the process
05:28:55 <wfaressuissia[m]> "blacklisting Tor is only a workaround until we have a patch", 100% probability that these IPs will stay there forever since Tor is a free way to get 1000 uniq ips for an experiment
05:29:45 <wfaressuissia[m]> 718M, 63 out / 18 in
05:31:48 <h2017> i've applied the new blacklist
05:32:13 <wfaressuissia[m]> centralization is coming
05:32:39 <h2017> soon there will be a whitelist with one central node
05:32:50 <h2017> the masternode
05:33:33 <h2017> man that., so non-woke. i managed to say blacklist, whitelist and a word with "master" in it in the space of three posts
05:33:39 <wfaressuissia[m]> whitelist with central nodes, good output keys an so on
05:36:28 <wfaressuissia[m]> assuming that bitcoin is for rich people that don't care about privacy (since it isn't possible to hide billions of dollars)
05:37:00 <wfaressuissia[m]> then monero is for poor people
05:37:34 <wfaressuissia[m]> it should be one of the main priorities to optimize monerod so that you can use the cheapest VM without any problems
05:37:41 <wfaressuissia[m]> and any special knowledge
05:38:17 <h2017> not necessarily but isn't someone already offering a cheapish dedicated appliance?
05:38:22 <h2017> that's the way to go
05:38:28 <h2017> just plug and play
05:39:07 <wfaressuissia[m]> OOM kill, ban list, puned db, any other form of DoS, +2 block, ...
05:39:23 <wfaressuissia[m]> ^ these are signs that software is in ready for poor people
05:39:43 <wfaressuissia[m]> * pruned db in order to fit into small SSD
05:40:01 <wfaressuissia[m]> * not ready
05:41:42 <h2017> wfaressuissia[m], people have a hate-on for monero. other coins don't have dedicated attackers
05:42:26 <wfaressuissia[m]> something strange is happening, rpc 18081 port isn't usable anymore and al incoming peers have gone
05:43:07 <wfaressuissia[m]> false positive, 127.0.0.1 has been banned due to p2p behind NAT
05:43:20 <h2017> my own node is running smoothly
05:43:51 <wfaressuissia[m]> I'm not using any preventive mechanisms
05:44:10 <h2017> you want to see the attack for yourself?
05:44:18 <wfaressuissia[m]> yes, i need that packet
05:47:30 <h2017> the guy behind the attacks (if it is the same guy who has been doing other stuff) is a major ZEC supporter
05:47:37 <h2017> the backstory is unknown to me
05:47:53 <selsta> wfaressuissia[m]: max packet size in monero is 100MB?
05:48:01 <wfaressuissia[m]> yes
05:48:37 <wfaressuissia[m]> git grep -ie 'levin.*packet'
05:48:52 <wfaressuissia[m]> contrib/epee/include/net/levin_base.h:#define LEVIN_DEFAULT_MAX_PACKET_SIZE 100000000      //100MB by default
05:49:08 <wfaressuissia[m]> But output packet is at most 32MiB
05:49:18 <wfaressuissia[m]> so you could easily reduce INPUT to the same at least
05:49:31 <wfaressuissia[m]> But shit * 0.99 ~= shit
05:50:38 <wfaressuissia[m]> one parseable packet can be compased from few 32MiB but in reality at most 1 32MiB paket can be sent
05:50:53 <wfaressuissia[m]> nothing is using framentation of p2p messages now
09:11:00 <moneroist> Hi, I would like to create wallet by rpc call, but don't know how to run monero-wallet-rpc with idle mode, what are minimal command arguments for run monero-wallet-rpc without opening particular wallet
09:12:35 <wfaressuissia[m]> `monero-wallet-rpc --wallet-file test_wallet --daemon-host 127.0.0.1 --rpc-bind-ip=127.0.0.1 --rpc-bind-port=18084 --prompt-for-password --disable-rpc-login --log-level 1`
09:13:09 <moneroist> ok so I need to pass some wallet file right?
09:14:06 <moneroist> I asking about it because there is rpc method open_wallet
09:14:36 <moneroist> so I thought that there is possible to run idle monoer-wallet-rpc without particular wallet and then call this method
09:17:51 <wfaressuissia[m]> `monero-wallet-rpc --wallet-dir /tmp --rpc-bind-port  18084 --disable-rpc-login`, with specified --walled-dir you're free to start without wallets
09:17:57 <moneroist> Ok I can do it, just need to use --wallet-dir
09:18:02 <moneroist> exactly
09:18:07 <moneroist> thanks!
09:21:59 <VashTheStampede> .bal
09:29:32 <moneroist17> wfaressuissia[m] maybe you know there is possible to reveal seeds words by rpc call? because I can not find this in docs
09:29:51 <moneroist17> wfaressuissia[m]
09:33:21 <moneroist17> Ok I found it :)
09:33:42 <rbrunner> Where? Did not find it directly in the .h file ...
09:34:08 <rbrunner> Not even a way to query secret keys
09:34:08 <moneroist17> there is method query_key
09:34:22 <moneroist17> in wallet rpc docs
09:34:44 <moneroist17> I have checked this out and this works
09:34:59 <rbrunner> Ah, yes, see it now. Quite some way still until you have a seed from that, right?
09:35:55 <moneroist17> right :)
09:37:25 <rbrunner> No pain, no gain
09:38:22 <Mochi101> curl http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"query_key","params":{"key_type":"mnemonic"}}' -H 'Content-Type: application/json'
09:38:52 <rbrunner> Clever, so it's one of the key types :)
11:41:55 <vekin> hello, thought i would idle in here after my monerod started getting OOM
11:43:13 <dEBRUYNE> vekin: https://www.reddit.com/r/Monero/comments/kjrub1/in_honor_of_people_who_work_on_christmas_eve/ggyiids/
11:43:28 <vekin> thanks, i've loaded the new block_tor.txt
11:45:01 <vekin> kind of freaked out thinking someone had a remote exploit for monerod
12:08:09 <aum> I've restarted monerod, even rebooted the node's container, but every time, monerod on startup shows on 'top' as having 100+GB of virtual memory
12:08:26 <aum> I have added the block_tor.txt file
12:09:37 <vekin> the block_tor.txt worked for me, ./monerod --ban-list block_tor.txt
12:12:02 <vekin> oh virtual ram, it isn't actually using that much ram
12:13:41 <xnbya> it maps the entire blockchain into virtual mem, you can ignore it
12:19:58 <aum> vekin, xnbya thanks -- so none of that memory-map of the blockchain is eating physical unless/until it needs to?
12:21:22 <vekin> yeah in htop you want to look at RES column to see actual memory usage
12:22:07 <aum> so what kind of hostile traffic was the attacker hiding behind the tor exits? DDoS, or something more menacing?
12:22:32 <vekin> I'm hoping it was just DoS too
12:29:52 <aum> I really gotta dive into the codebase. I'm guessing a big chunk of ongoing effort goes into defending against toxic nodes (similar to Freenet and I2P when I was working on those projects)
12:30:05 <Jaska_> Hmm.. monerod on my windows desktop pc makes my pc go *HURGH!* and stalls
12:31:00 <vekin> Jaska_: https://www.reddit.com/r/Monero/comments/kjrub1/in_honor_of_people_who_work_on_christmas_eve/
12:31:34 <aum> vekin, should that be added to this chan topic?
12:34:31 <anchor[m]> >makes my pc go *HURGH!* and stalls
12:34:31 <anchor[m]> lol
12:40:23 * aum starts working on a systemd unit for '*HURGH! out of memory*' monitoring
12:42:31 <vekin> you can use "MemoryMax=10000M" or something similar to have systemd auto kill it past a certain point
12:45:46 <aum> good idea
12:45:58 <camalonso> In some (rare) cases the attack may come via Tor node not listed in "official" exit node list. I've compiled a list of exit nodes that doesn't have "Exit flag" but do have exit policy accepting *:18080
12:46:07 <camalonso> https://pastebin.com/kUpPTVZT
12:46:38 <camalonso> just in case someone is having issues even with all the block lists applied
12:47:54 <aum> according to coingecko this doesn't seem to have hit XMR/USD
12:48:54 <camalonso> correction: they might have exit flag, but some of the don't..
12:52:53 <aum> camalonso, does that supplement, or override, the earlier block_tor.txt ?
12:53:07 <aum> s/override/supersede/
12:54:14 <Lyza> block_tor.txt is the normal block list + blocks tor exit nodes
12:54:48 <Lyza> sorry you were asking about camals list
12:55:10 <aum> i've already got block_tor.txt in place
13:00:38 <camalonso> it's supplement to all other block lists, in case your node still gets rekt
13:01:12 <aum> ok
13:04:47 <aum> I'm noticing CLI args and jsonrpc verbs for start/stop/configure mining, but no info on how to review mining status, or allocate mining rewards to a wallet's address - am I missing something?
13:09:17 <Jaska_> another quick question, I SYNCHRONIZED OK. This is related to the attack but why it's spamming it when there is no even new blocks being announced.
13:48:06 <selsta> Jaska_: SYNCHRONIZED OK should show up less often in the next release
13:51:24 <selsta> ok wait, could be that the attacker is spamming it now
13:53:06 <Jaska_> 2 syncs every 10 seconds
13:53:18 <rbrunner> I wonder how long it takes until all those sync shenigans completely break the ETA / sync time display I programmed in the daemon :)
14:03:58 <Lyza> another report of 'synchronized ok' spam https://www.reddit.com/r/Monero/comments/kjrub1/in_honor_of_people_who_work_on_christmas_eve/ggziqx9/
14:08:02 <selsta> you can ignore it for now
14:08:17 <selsta> does not seem harmful apart from being verbose
14:10:19 <dEBRUYNE> selsta: PM btw
14:11:20 <Idancelikethis> talking about my wife? verbose and not SEEM harmful
14:11:53 <vekin> LOL
14:13:32 <rbrunner> Yeah, I also have "SYNCHRONIZED OK" messages that multiply like rabbits. As long as the daemon stays up :)
14:17:06 <vekin> its probably because you are sending out tons of blocks on account of a lot of nodes going down
14:17:21 <vekin> but idk how the protocol works so that may be wrong
14:18:10 <vekin> mine is sending at 1-3MB/s and I haven't seen it use that much previously
14:26:42 <p3rL> merry xmas fluffypony
14:26:46 <teddit[m]> same here, lots of SYNCHRONIZED OK messages
14:26:49 <p3rL> how long we need to wait for free xmr giveaway
14:27:16 <marmulak> how many xmr do you get?
14:27:50 <p3rL> waiting for fluffy's giveaway
14:28:58 <selsta> the SYNCHRONIZED OK is something we have fixed on Github, we will include it in the next release
14:29:02 <selsta> you can ignore it
14:29:30 <selsta> https://github.com/monero-project/monero/pull/7154
14:31:46 <Mochi101> Are we getting a new point release for Christmas?
14:34:06 <kico> selsta, is this due to dem nasty nodes?
14:34:26 <selsta> yes
14:34:37 <kico> ic makes sense
14:34:45 <kico> in a twisted way iGuess
14:34:48 <kico> thanks
14:36:59 <kico> I see some txs getting stuck in the nodes at times also
14:37:15 <kico> relay_tx doesn't seem to do the trick
14:42:41 <kico> mebbe block.txt needs an update
14:42:44 <kico> :P
14:43:49 <selsta> updated the block list with new IPs
14:43:57 <selsta> which should make the synchronized spam stop
14:47:48 <kico> thx
14:48:02 <kico> can I has the link pls?
14:48:19 <selsta> https://gui.xmr.pm/files/block_tor.txt
14:48:29 <selsta> this one for the current attack, afterwards please use https://gui.xmr.pm/files/block.txt again
14:48:46 <kico> merry thanks :)
16:17:21 <spedex> The "Synchronized ok" started to happen again with the new block list.....10 secs apart.
16:20:53 <vekin> 10s? mine are often 1s apart
16:24:04 <selsta> spedex: likely he spun up new IPs
16:24:13 <selsta> you can add 95.216.217.238
16:24:56 <spedex> OK will do
16:26:34 <spedex> Annoying fellow that whoever is doing this
16:38:12 <spedex> Maybe another one: 95.216.173.96?
16:38:50 <spedex> If that is correct then I figured out how I can look for them myself and add to my blocklist
16:40:02 <selsta> set_log 1
16:40:15 <selsta> and then look for the IP before the synchronized message
16:41:10 <spedex> yeah that is what I did
16:41:38 <selsta> yep he is adding hetzner IPs now
16:43:31 <selsta> updated my block list
16:43:34 <monerouser1144> Came here to check about the malicious IPs, here is my info http://paste.debian.net/1178294/
16:50:12 <monerouser1144> Btw I was wondering, do such attacks happen on the other cryptocurrency networks, or is Monero getting a "special treatment" ? ;-)  TIA.
16:50:43 <Mochi101> monerouser1144, some coins even get 51% attacks
16:56:00 <monerouser1144> Please remind me, if a peer node that is still reporting being at block #1 after e.g. 30min, is it an indication of suspicious/malicious activity or maybe it is unable to sync due to e.g. using outdated software? Should I block them (I have 3 out of my 10 peers at block #1)?
16:56:26 <selsta> no need to ban them
16:56:39 <selsta> they are honest about their block height by claiming to be on 1
16:59:47 <monerouser1144> selsta thx, I remember you gave me the same answer a couple of months ago. Please check the paste I sent earlier, because I don't see 159.89.95.30 in your block.txt
17:00:51 <Mochi101> seems bad nodes are using random ports
17:01:21 <selsta> monerouser1144: thanks, added it
17:05:41 <monerouser1144> Perhaps a DNS-based solution can be created for querying the ban-list, similar to the various DNSBL used for mail servers.
17:06:59 <selsta> we have a DNS based ban list for the next release
17:07:02 <selsta> opt in
17:10:06 <omega> hello. i'm running latest linux release and my daemon keeps coming up "Killed" what is killing it?  I set log level to 0 1 2 and I don't see anything in the terminal killing the process?
17:11:18 <selsta> omega: please apply the following ban list: https://gui.xmr.pm/files/block_tor.txt
17:11:23 <selsta> some network attack
17:12:27 <omega> yes.  i am using the start up flag -ban-list with block.txt -  are others reporting the same issue?
17:12:42 <selsta> this is a new version of block txt
17:12:50 <selsta> it includes tor exit nodes which are used for this attack currently
17:12:53 <omega> okok..  i try. thanks
17:12:56 <selsta> yes, other have this too
17:20:36 <omega> TO ALL AGENTS ON CHANNEL: Your time is up. The New World Order Firewall WILL NOT be successful. BEING FREE IS MY BIRTHRIGHT. Millions of people are waking up.
17:20:57 <Mochi101> Mmmkay
17:33:19 <Jaska_> I feel like banning the whole ovh network D:
17:33:48 <Mochi101> That's one way to be sure you're not connecting to any bad actors Jaska_
17:34:47 <selsta> Jaska_: ban OVH, Hetzner and DigitalOcean :D
17:34:53 <selsta> and all Tor exit nodes
17:34:55 <Jaska_> yeah
17:35:09 <Jaska_> manually banning one ovh ip, another pops up :P
17:40:38 <monerouser1144> I use iptables+ipset to block many IP ranges. But I am not sure if banning the low-cost VPS providers (OVH, DO, Hetzner etc) is a good idea.
17:42:04 <selsta> my nodes have been quite quiet with latest version of  https://gui.xmr.pm/files/block_tor.txt
17:42:05 <M5M400> my nodes are mostly hetzner and ovh :(
17:42:13 <M5M400> don't ban me
18:46:44 <selsta> does anyone know if the SYNCHRONIZED OK attack is still ongoing?
18:47:22 <ragn4> 2020-12-25 18:46:54.430 I SYNCHRONIZED OK
18:47:25 <ragn4> let's see
18:47:31 <hyc> yes
18:47:39 <hyc> I'm still getting a ton of those
18:49:42 <Mochi101> selsta, sometimes yes and sometimes no
18:50:20 <Mochi101> after banning some nodes it goes away... but I have some obviously bad nodes connected for awhile with no resulting syncronized ok message
18:51:13 <ragn4> 2020-12-25 18:50:47.242 I SYNCHRONIZED OK
18:51:13 <ragn4> 2020-12-25 18:50:57.750 I SYNCHRONIZED OK
18:51:13 <ragn4> 2020-12-25 18:51:08.259 I SYNCHRONIZED OK
18:51:41 <selsta> ok thanks
19:50:28 <aum> if a node is configured to do mining, how does it receive the benefit?
19:55:37 <rbrunner> For mining you have to give a wallet address. If your daemon finds a block, the transaction with that block reward goes to that address.
19:57:54 <miziel> and the block just needs to get confirmed by the network and taaadaaa! ez money :D
20:06:07 <mechanic41turk[m> <miziel "and the block just needs to get "> literally creating money out of thin air !!!
20:06:51 <sethsimmons> hyc any idea which of these would be most interesting to keep track of for monitoring monerod memory usage?
20:06:53 * sethsimmons uploaded an image: ima_661b58f.jpeg (386KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/xIAjJjhSnIztbnQnJgHNWiYn/ima_661b58f.jpeg >
20:10:39 <sethsimmons> Monitoring percent real, resident set size, and virtual size right now.
20:11:04 <moneromooo> RSS is important. That's what will be pretty much unswappable.
20:11:49 <sethsimmons> Perfect — was just monitoring total which included virtual before, which wasn’t all that meaningful and didn’t help catching OOM attacks/events.
20:11:56 <moneromooo> Virtual is address space, it'll include all the mmap'd stuff. No idea what real is.
20:14:50 <sethsimmons> Percent real is just RSS/total mem
20:21:56 <hyc> I'd watch RSS and swap
20:22:08 <hyc> if swap starts growing fast you're in trouble
20:25:08 <sethsimmons> Yeah thats how I would have caught the issue very early if I hadn’t been AFK for the holidays, swap kept filling and pinging me because of it
20:26:52 <hyc> and RSS alone doesn't mean much. it's ok for RSS to grow if it's all shared memory
22:49:23 <xmrpow> Does anyone know how I could  get rid of this p2p attack? My node is always crashing within 30min.  Is there sth else than using selstas latest ban list and using 17.1.7?
22:51:01 <Lyza> This one is coming from tor exit nodes, so you can use https://gui.xmr.pm/files/block_tor.txt which is the original list + tor exit nodes
22:52:04 <xmrpow> Im already using the list which is blocking tor exits
22:53:00 <xmrpow> But it does still not work.
22:53:36 <Lyza> ah well it's possible it may be missing some
22:53:36 <selsta> there is also https://gui.xmr.pm/files/block_tor_new.txt which also blocks tor relays with 18080 exit policy
22:53:55 <selsta> this one should be more complete
22:54:12 <xmrpow> Thanks selsta going to try the new one
22:54:20 <selsta> mine running https://gui.xmr.pm/files/block_tor.txt did not crash in 12+ hours
22:54:35 <shabash> what's the latest and greatest blocklist to use?
22:54:47 <selsta> use https://gui.xmr.pm/files/block_tor.txt
22:54:55 <selsta> if you still have issues, try https://gui.xmr.pm/files/block_tor_new.txt
22:56:05 <h2017> xmrpow they updated it though. make sure you have the latest update
22:56:48 <shabash> so https://gui.xmr.pm/files/block_tor.txt is the address to remember?
22:57:10 <h2017> my node's been up for amost 7 hrs with no issues but only using the latest block list
22:57:27 <xmrpow> h2017: ok. trying the new one.
22:59:35 <xrv0> hey, quick question regarding coin supply again. Doesn't the total emission look less like this https://i.stack.imgur.com/Dms1D.png and more like this https://prnt.sc/w9zsyg because of the block time change in 2016?
23:00:02 <xrv0> or was the block reward doubled after the update?
23:02:32 <xmrpow> How long do you think will it take to get rid off these attacks? Is there any sign of a solution on the closer horizon or do you think this back and forth with blacklists is going to continue for few weeks?
23:02:36 <nioc> block reward was double when the block time doubled
23:03:49 <moneromooo> It'll continue until the jerk doing this stops trying. Until then, we'll just fix whatever he tries to break.
23:04:36 <ragn4> rm ./total.txt ./block_tor.txt ./block.txt;wget https://gui.xmr.pm/files/block_tor.txt;wget https://gui.xmr.pm/files/block.txt;sort -u block_tor.txt block.txt > total.txt;wc -l total.txt;./monerod ... --ban-list total.txt
23:04:38 <moneromooo> It seems likely they've spent the last year or whatever poring over the code, so they might have a few of those.
23:05:35 <Lyza> <ragn4> block_tor.txt should already contain block.txt
23:05:56 <ragn4> ok thanks
23:06:58 <xmrpow> moneromoo: I rly dont like the way how this guy is dealing the issues, but what kind of worries me that nobody thought about the issues before within the community... Hasnt this been an issue in btc p2p network before?
23:07:27 <moneromooo> monero you mean ? We have issues in p2p before I think, yes.
23:07:59 <selsta> fwiw even Bitcoin wiki claims that they are vulnerable to P2P DoS https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks
23:08:05 <moneromooo> Couldn't point to one in particular, but see git log if you want to search.
23:09:20 <xmrpow> So btc p2p is obviously safe, otherwise they would be under constant attack.
23:09:23 <moneromooo> Anyway, I've got patches for these things, so I'll PR them.
23:09:32 <Lyza> there's just not that many people doing actual development work and, no offense intended, I don't think any of them are particularly well verses in networking stuff
23:09:54 <selsta> just because they don’t get attacked does not mean they are safe, else they would not claim to be vulnerable themselves
23:10:30 <selsta> but Monero is obviously less mature than bitcoin and has more p2p dos vectors
23:10:33 <Lyza> I guess the assumption is that the incentive to attack btc is higher than to attack monero, but I'm not sure about that
23:10:57 <selsta> what is the incentive to DoS the network?
23:11:04 <ragn4> ddos over nodes now?
23:11:40 <xmrpow> moneromooo: Yes, I meant monero. Didnt know about it.
23:12:01 <moneromooo> Assuming it's the same person, it's someone who tried to work with us a few times, but pretty every time became abusive. In the end we just tried to have nothing to do with him. So I guess it's taking rejection badly. Maybe three's something else I don't know about though.
23:12:46 <moneromooo> So I guess the incentive is... not being able to have their way, then trying to piss on it in spite ? I dunno. Looks like it to me.
23:12:58 <selsta> xmrpow: see the amount of DoS attacks here https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
23:13:00 <selsta> some of them quite recent
23:13:16 <ragn4> Connection timed out
23:13:17 <selsta> it only takes one skilled malicious dev to abuse this
23:13:27 <moneromooo> Assuming it's the same person doing it all. Which seems likelt, but not certain.
23:14:26 <aum> does anyone have any data of mining machine kWh per XMR, for the various pools?
23:15:16 <aum> i need to calculate the break-even time for a mining rig based on hardware cost, setup time, local electricity costs, average returns per megahash...
23:15:41 <aum> I guess the node mining feature can't be set up to use a pool
23:17:31 <moneromooo> You need special software. Of which there are a handful.
23:17:55 <xmrpow> selsta: "what is the incentive to DoS the network?" Pool nodes would be attractive
23:18:13 <dEBRUYNE> xmrpow: Always easy to say in hindsight. In practice, it is difficult to harden a network against a large variety of attacks a priori
23:18:13 <moneromooo> Basically, to distribute jobs and keep track of who you distribute to, and account for who to pay when a block is found. And all the fancy stuff to go around.
23:18:55 <aum> I'd rather grab off-the-shelf Ubuntu-compatible s/w, cos I want to start my coding effort on building python asyncio-based RPC clients/integrations
23:18:57 <Mochi101> To be fair moneromooo, we don't really know who it is. We only assume.
23:19:42 <Mochi101> I'm glad you worded it that way.
23:19:51 <xmrpow> debruyne: True. I dont want blame devs, but I kind of feel uncomfortable about the fact that one guy can do that much damage.
23:20:47 <xmrpow> Mochi101: Do you know how M5 is protecting his nodes ?
23:20:50 <moneromooo> It's made of software, you know.
23:21:10 <Mochi101> xmrpow, come on... is that even a question?
23:21:52 <dEBRUYNE> xmrpow: If they have competence and resources, I don't see why not
23:21:52 <Mochi101> xmrpow, most pool ops are very dedicated.
23:22:17 <xmrpow> Mochi101: Yes it is.
23:23:19 <xmrpow> Mochi101: So he is basically baning the hell out of it?
23:26:32 <ocb> hello. been running full xmr node at full 1gbps speed over a year now. in the past 72 hours monero started using extensive amount of memory, at the moment 500mb but in no time it jumps to 12gb which is the hard limit of a docker container. until now, had no problems. v0.17.1.5
23:26:35 <Mochi101> xmrpow, I don't know how he's addressing it or even if he has problems anymore.
23:27:01 <ocb> is anyone having similar issues? ^ some kind of attack ongoing maybe? i just noticed .. about to start debugging.
23:27:20 <Mochi101> ocb, it's an attack
23:27:45 <Mochi101> use the latest version with the ban list
23:28:34 <ocb> thank you. all this is becoming very sad, receiving lots of L7 attacks on electrum servers too.. now this. there are some haters around. thanks for the info, i'll update right away. mind giving some additional info if you have it near?
23:29:03 <selsta> https://gui.xmr.pm/files/block_tor.txt
23:29:18 <xmrpow> ocb:https://sethsimmons.me/posts/moneros-ongoing-network-attack/
23:29:19 <selsta> apply this text file using --ban-list and look out for a new release soon
23:30:03 <ocb> thank you guys!
23:30:27 <Mochi101> selsta, you want the ip addresses that I've manually banned?
23:31:26 <selsta> what kind of IP addresses are these?
23:31:51 <xmrpow> moneromoo: Arent you the only one who is permanently working on the code base or is there sb else who is funded by ccs?
23:32:14 <selsta> vtnerd and xiphon are also CCS funded
23:32:27 <Mochi101> I'm not sure what you mean selsta. They all seemed to be using strange ports and were always "syncing"
23:32:37 <sech1> xmrpow https://github.com/monero-project/monero/graphs/contributors
23:32:56 <selsta> Mochi101: incoming peers use random ports
23:33:32 <selsta> afaik my list is quite complete, but you can send me "sync_info" output and I can take a look
23:33:45 <ocb> at the moment i'm blocking electrum ddos by limiting concurrent connections to 9, if one goes over that - that ip is added to blacklist with ipset that is called fromiptables
23:35:06 <ocb> here's a quicky if needed, could possible be changed to work with monero with some more verbose logging - https://termbin.com/c4q6 will look into it now. thanks for the info, going to update.
23:35:27 <xmrpow> sech1, I know about all the volunteer contributors, but I dont think they are not all constantly contributing like for instance moneromooo
23:36:36 <xmrpow> sech1, * but I think
23:38:51 <xmrpow> Are there any other devs who would be willing to work as paid devs, but cant be paid because of lacking donations etc. ?
23:39:56 <selsta> lack of donations have not been a problem
23:42:08 <xmrpow> selsta: What s the problem then? Not enough skilled devs?
23:45:16 <xmrpow> moneromoo: How long do you think it would take for sb who can code python and java to get into c++ in order to work with the monero code base?
23:46:13 <sech1> xmrpow 5 years
23:46:25 <Mochi101> :D
23:46:27 <sech1> not kidding
23:46:45 <sech1> and that assuming that somebody has talent already
23:47:01 <sech1> c++ is just a different beast
23:47:15 <moneromooo> Depends what you want to do really. And it depends a *lot* on the person. Some people ask me the same questions over and over again in PM, you'd cry.
23:47:48 <moneromooo> For someone who knows Java well and can learn, < 5 years easily.
23:48:39 <sech1> c++ is easy to learn in 1 year or so, but to be able to write good quality code in a large codebase... it takes time
23:51:00 <xmrpow> moneromoo: Sry I hope you didnt have to cry now ;)
23:51:57 <xmrpow> Are you both in touch with c++ in you day time job?
23:52:16 <sech1> For the last 15 years, yes
23:53:25 <xmrpow> Hm, I rly hate the decision that they are teaching java at my university....
23:54:06 <Mochi101> But 3 Billion Devices Run Java
23:54:10 <selsta> Doubt the language matters at University
23:54:43 <xmrpow> Mochi101: I feel the bitterness there ;)
23:54:44 <selsta> If you get the general concepts you can learn C++ yourself
23:54:44 <xrv0> java atleast gives you a solid understanding of oop programming. Once you understand the principles you can adapt to new languages pretty easily
23:56:19 <sech1> They should teach you programming
23:56:25 <sech1> Instead they teach you java
23:56:46 <xmrpow> sech1: You mean java is to specific?
23:56:56 <xmrpow> *too
23:57:00 <sech1> I mean java is a programming language
23:57:09 <sech1> They teach you words, but not how to make sentences
23:57:23 <sech1> figurally speaking
23:57:26 <moneromooo> Sufficient.
23:57:38 <sech1> do you have basic algorithms and data structures course there?
23:57:53 <moneromooo> Enough.
23:58:23 <moneromooo> (trying to see how you can have a conversation with single words)
23:58:38 <sech1> Specific programming language is secondary. Once you know fundamental stuff, programming language is just a tool
23:59:06 <xmrpow> I started with computer science but ended up in information systems. When I studied computer sciences we had such courses there, but it was basically always proofing mathematical stuff.
23:59:30 <xmrpow> It was very theoretical.
23:59:47 <xmrpow> But I understand what you mean...