05:51:26 <fluffypony> sigh
06:23:40 <djwoveoaq> Dear fireice_uk. I must strongly object to you reporting our great Monero community members
06:23:41 <djwoveoaq> to Freenode for racism AND getting people K-lined as a result! https://i.imgur.com/R0T9GGY.png
06:23:42 <djwoveoaq> THEY ARE NOT NEO-NAZI!!! THEY ARE JUST SAYING NEO-NAZI THINGS!! https://i.imgur.com/JYu44As.png
06:23:43 <djwoveoaq> I know this because they have been nice to me and made me their Magical Crypto Friend!
06:23:44 <djwoveoaq> If you don't cease immediately I shall throw another tantrum!
06:23:45 <djwoveoaq> Monero Community Member
06:23:46 <djwoveoaq> PS. You are interrupting my session of masturbation to The Man in the High Castle.
07:03:28 <fluffypony> setting +r in the room for now
07:04:02 <fluffypony> so if you can't send messages please register with nickserv
07:33:09 <tvhtcguqr> Dear fireice_uk. I must strongly object to you reporting our great Monero community members
07:33:10 <tvhtcguqr> to Freenode for racism AND getting people K-lined as a result! https://i.imgur.com/R0T9GGY.png
07:33:11 <tvhtcguqr> THEY ARE NOT NEO-NAZI!!! THEY ARE JUST SAYING NEO-NAZI THINGS!! https://i.imgur.com/JYu44As.png
07:33:12 <tvhtcguqr> I know this because they have been nice to me and made me their Magical Crypto Friend!
07:33:13 <tvhtcguqr> If you don't cease immediately I shall throw another tantrum!
07:33:14 <tvhtcguqr> Monero Community Member
07:33:15 <tvhtcguqr> PS. You are interrupting my session of masturbation to The Man in the High Castle.
07:49:00 <fluffypony> lol of course they added a reg step to their script
07:49:39 <fluffypony> +m for now
07:49:48 <fluffypony> ping an op if you want voice
11:14:07 <kayront> is it expected that transactions with v0.17.x take forever? they were all failing before upgrading to 0.17.1.1, i've tried a couple since then, and while they don't fail, they get stuck in pending for 10 mins or so
11:15:11 <kayront> i'm running the wallet on a tightly isolated vm where only connections to monerod are allowed, and running the wallet with --no-dns. it doesn't seem relevant in this case, but that's the most exceptional thing about the setup. and it worked fine until v0.17x
11:45:54 <M5M400> kayront: what's your daemons status?
11:49:04 <M5M400> i wonder if you're blocked with bad nodes
11:53:41 <kayront> daemon seems fine
11:53:47 <kayront> fully synced
11:54:25 <kayront> maybe it's relevant, but it doesn't take any incoming connections. but again, this wasn't a problem until upgrading
11:54:44 <kayront> (it doesn't have incoming connections by design, long story not worth going into)
12:00:08 <M5M400> kayront: try blocking bad nodes... https://paste.debian.net/hidden/52d10abe/
12:00:44 <kayront> what is this bad nodes story though?
12:01:18 <kayront> transactions started failing pretty much immediately after upgrading daemon and wallet, just seems like a big coincidence
12:01:49 <kayront> then upgraded to 1.1, now they take forever instead.. dunno, the timing is suspect
12:02:09 <kayront> https://github.com/monero-project/monero/issues/6929 maybe the same
12:02:19 <M5M400> in earlier v0.17 versions there was a propagation issue, which should have been rectified
12:02:57 <M5M400> the bad nodes are run by an unknown actor, basically hogging all your peer slots and not propagating blocks at all
12:03:26 <kayront> interesting
12:04:15 <kayront> any theories ?
12:05:13 <M5M400> trying to harvest tx data? trying to block tx and slow down the network? take your pick
12:05:52 <kayront> but why not
12:05:55 <kayront> now*
12:06:15 <M5M400> because some three letter agencies put out bounties to make xmr traceable?
12:07:04 <kayront> i'm beginning to feel really good about the very tight cage around monerod and monero-wallet-cli
12:07:06 <kayront> lol
12:09:07 <kayront> yeah, so i tried another tx 5 mins ago, still pending in the wallet, doesn't show up on block explorers
12:09:32 <Lyza> 10 minutes pending isn't really that long. Have you been watching the block explorer or anything? For example the last block took 7.5 minutes. You could have easily had some bad luck maybe combined with slightly slow propogation
12:09:50 <Lyza> ah well if it's not on the explorer's that's diff
12:10:36 <kayront> well with v0.16 it was maybe 20 seconds until the wallet detected the tx was in the mempool
12:10:45 <kayront> now it's many minutes before it even registers on a block explorer
12:11:35 <Lyza> yeah it should be in the mempool for sure
12:12:11 <kayront> now it's in the mempool, about 6min later
12:12:40 <M5M400> hm.. mempool to your own node should be fast
12:13:01 <kayront> well, i checked from a block explorer (not on my lan)
12:13:17 <M5M400> then we're back at propagation
12:13:30 <M5M400> try blocking those nodes and increase your out_peers to 64 or something
12:13:30 <kayront> yeah
12:13:39 <kayront> i blocked them already
12:13:57 <kayront> could increase out peers, though the last time i did 64 it ended up running out of memory :p
12:14:07 <M5M400> huh?
12:14:12 <M5M400> smallish VM?
12:14:15 <kayront> lot more tcp connections
12:14:18 <kayront> not a lot of ram allocated
12:14:23 <kayront> unhappy ending
12:14:26 <kayront> but i have more memory now anyway
12:15:08 <M5M400> mine runs on 256 in/out peers and doesn't snack much memory at all https://node.supportxmr.com/
12:15:14 <kayront> it's vaguely concerning if evil nodes can partition my pet monerod away from the network so eadily though
12:15:41 <Lyza> wondering why I haven't seen this issue -- does enabling incoming connections resolve it?
12:16:03 <kayront> did these attacks start after v0.17 only? i imagine dandelion makes it harder for monerod to know if the peers it relayed txs to actually relayed them
12:16:21 <kayront> Lyza: unfortunately i cannot enable incoming connections to test. don't want to go into too much detail, but basically it's not possible
12:16:30 <M5M400> seemed to have started about a week ago
12:16:43 <Lyza> right kayront didn't mean as a sol'd for you necessarily but I was wondering more generally
12:17:23 <M5M400> kayront: you could add some known community nodes as priority nodes in monerod
12:23:53 <iDunk> It's been going on for over a year.
13:03:22 <gingeropolous> iDunk, the AHP has been going on for over a year, or the transaction propagation delay?
13:05:00 <iDunk> AHP
13:06:06 <iDunk> #5732 and #5737 were the initial mitigations.
13:08:43 <iDunk> #6920 works really well here.
13:09:51 <gingeropolous> yeah. So either A) dandelion has a bug B) the 150 AHP can really do a number on the network or C ) there are other AHP using a different method that we can't detect and they are doing a number on the network
13:10:16 <gingeropolous> because up until the fork, some unknown % of the network was still just constant flood
13:10:49 <gingeropolous> or some combination of those
13:11:54 <Inge-> Where is the up-to-date banlist again?
13:12:32 <asymptotically> Inge-: https://gui.xmr.pm/files/block.txt
13:14:14 <gingeropolous> u can also use a live checker in the case that They start launching different IPs.
13:14:37 <gingeropolous> i *think* my script is working - so far it produces the same list as selsta's. well lets do a diff
13:18:10 <gingeropolous> yeah its the same as the one posted on gui.xmr.pm
13:19:21 <gingeropolous> i want to look into the timer thing for "auto-fluff on fail" function
13:20:09 <gingeropolous> like, even if there's some large % AHP on the network, your tx should get broadcast by the fallback
13:20:59 <gingeropolous> so, because the fallback isn't working, that could mean that some large % of the network are AHP ..... ? or the fallback is buggy.
13:22:35 <gingeropolous> the numbers could probably be run on this - to broadcast your own tx, you must select 1 random peer from your list of connected peers.
13:23:22 <iDunk> Maybe #6914 changed the dynamic there in some unexpected way.
13:23:38 <gingeropolous> so at some (y total number AHP connected to) / (n total peers connected to), the probability of random means that the first node you relay to blackholes your tx
13:24:21 <gingeropolous> statisticians! where aaaarrreeee yoooouuuuuu
13:24:22 <iDunk> Note that my daemon was eclipsed twice in two days before I started mass banning the AHPs.
13:27:51 <gingeropolous> wow. amazing that just mirroring block height is so effective
13:28:52 <iDunk> Once all your peers are AHPs, your daemon stops syncing, and it prints those "there were 0 blocks in..." type messages.
13:30:03 <iDunk> And your txes are blackholed, as you mentioned earlier.
13:31:08 <nioc> Almost all of my txs consistently  take 3.5 to 4 minutes to show in mempool
13:32:27 <gingeropolous> yah know, maybe i've avoided being blackholed by always using --add-priority-node
13:32:27 <Inge-> nioc: do you have any AHP mitigation?
13:32:57 <nioc> When waiting to see my tx in the mempool I notice that txs often get added 3 at a time with the same time stamp to the second
13:33:03 <nioc> Inge-: no
13:34:12 <nioc> Often means almost always if there are enough txs to be added
13:34:32 <iDunk> Hmm, could that mean your txes are always sent by your daemon as fluff, never as stem after a timeout ?
13:36:59 <iDunk> If you send regularly, it would be a good test if you built with #6920 and used a blocklist to see if it's actually a D++ problem.
13:38:20 <iDunk> For now, I tend to attribute sync and tx propagation issues to AHPs.
13:38:39 <Lyza> gingeropolous I think you might be right because I have my i2p peers added as priority nodes and have also never seen this issue
13:44:16 <Inge-> iDunk: going on 3 minutes after banning AHPs
13:44:20 <Inge-> 4 minutes
13:44:34 <Inge-> about 4 minutes...
13:47:22 <iDunk> What was that average time..., 187 seconds or something like that ?
13:47:36 * iDunk afk
13:48:49 <moneromooo> About right.
13:54:46 <Inge-> I'm waiting for the promised 3s median :P
14:01:07 <selsta> So there are ~120 of these bad nodes. Mirroring your block height and feeding only their own nodes in peer lists is enough to get connected to almost every node.
14:01:50 <selsta> Inge-: As long as everyone has 50% bad peers there will never be 3s median
14:29:00 <gingeropolous> so what do we do
14:32:36 <Lyza> are there so few connectable nodes that only 120 can commonly eclipse people, or is the peer list poisoning somehow really effective?
14:32:48 <Lyza> 120 is a much smaller number than I assumed
14:33:07 <Lyza> given there are thousands of Monero nodes running
14:34:10 <gingeropolous> i think seed nodes need to run this ban list asap
14:35:00 <selsta> yea they are most likely adding seed nodes as priority peers
14:36:00 <gingeropolous> crap, how do you get the records from seeds.moneroseeds.x?
14:36:20 <gingeropolous> oh, its in the A list
14:36:43 <hyc> why doesn't sync_info print column headers? I've no idea what some of these fields are
14:37:12 <selsta> Lyza: afaik there are 2k+ monero nodes but most will have default out peers of 12, so setting out_peers to unlimited + peer list poising is most likely quite effective
14:37:14 <gingeropolous> its in the record of moneroseeds.se
14:37:21 <gingeropolous> not the subdomain ...
14:37:32 <selsta> gingeropolous: seed nodes are in the source code, not sure if dns seed nodes are used currently
14:38:19 <gingeropolous> hardcoded seed nodes are a fallback afaik, if the seed nodes don't return lists
14:38:31 <gingeropolous> err, if the dns seeders return empty, it uses hardcoded
14:39:52 <gingeropolous> oh wait, it only seems to come up at src/p2p/net_node.h ...
14:40:04 <gingeropolous> and dns check something
16:31:08 -xmr-pr- moneromooo-monero opened pull request #6933: p2p: use /16 filtering on IPv4-within-IPv6 addresses
16:31:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6933
16:39:39 <gingeropolous> who needs headers?
17:46:08 -xmr-pr- mj-xmr opened pull request #6934: Remove boost/optional from headers (mj-xmr)
17:46:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6934
18:09:59 <kayront> <nioc> Almost all of my txs consistently  take 3.5 to 4 minutes to show in mempool
18:10:13 <kayront> mine too! so is this then because of the malicious nodes?
18:10:18 <kayront> i assumed some problem with dandelion
18:11:10 <nioc> some where delayed before 0.17 but know it is consistent
18:11:13 <kayront> <iDunk> For now, I tend to attribute sync and tx propagation issues to AHPs. --> maybe just unhappy timing, but for me the problems begun the moment i upgraded
18:11:35 <nioc> some get into mempool quickly but that is rare
18:12:11 <nioc> *but now
18:14:10 <kayront> <gingeropolous> wow. amazing that just mirroring block height is so effective --> what did you mean by this? both mirroring block height, and being effective (at what?) - clearly i missed a part of the convo
18:14:11 <selsta> kayront: It is related to Dandelion++
18:15:06 <kayront> do we know what the problem is selsta ?
18:16:25 <selsta> Combination of multiple things but primarily there are malicious nodes that drop transactions.
18:16:58 <kayront> did the addition of dandelion make it easier for them?
18:17:08 <selsta> Easier to do what?
18:17:18 <kayront> drop the txs
18:17:24 <kayront> i haven't read much (any) on d++
18:17:26 <selsta> Easier to spy? No. Dandelion makes it harder to spy for them.
18:17:29 <kayront> just know what the idea is supposed to be
18:17:42 <kayront> no, i mean, if the tx is only announced to one peer because of d++
18:17:47 <kayront> then that makes it easier to blacklist
18:17:53 <kayront> but i'm not sure it acvtually works like that
18:18:41 <selsta> Yes, it makes it easier to drop transactions for them but you still get the privacy benefit of Dandelion
18:19:19 <sethsimmons> Weirdly the person your talking to is not being relayed to Matrix
18:19:31 <kayront> hmm, then i must really be missing smt here. won't the peer that blacklisted the tx know what it did?
18:19:36 <sethsimmons> Idk why but it looks like you’re talking to yourself selsta
18:19:50 <selsta> sethsimmons: not sure why
18:20:04 <selsta> kayront: Can you elaborate?
18:20:31 <kayront> ok, but bear in mind this might make no sense at all, as i said, haven't looked into d++ and definitely have not read any code
18:20:44 <kayront> if you have a large number of evil servers blocking transactions
18:20:53 <kayront> and they were the first hop in the censoring of said tx
18:21:22 <kayront> then couldn't they compare notes? if the tx was killed at the first hop and it never shows up from any other evil peers, then safe to assume we know the monerod that broadcast it
18:21:55 <selsta> How do they know they were the first hop?
18:23:05 <kayront> maybe not with 100% certainty, but if (I stress the if) victim1 is relaying the tx through a single peer because of d++ (evil1), then the rest of the evil peers won't see that transaction right?
18:23:14 <kayront> it never gets beyond the first hop
18:23:34 <kayront> so they talk between themselves on another evil channel, only one of them saw the tx, and it knows the ip it came from
18:28:11 <selsta> If you receive a transaction you don't know which hop it is. They can assume that they are always first hop but that is just an assumption and not particularly accurate. That’s how I understand it at least.
18:29:19 <selsta> Dandelion++ is not 100% perfect but it still significantly better than without. For "perfect" privacy people can use --tx-proxy with I2P / Tor
18:30:01 <kayront> it would be nice if someone else with better knowledge about the issue could comment later
18:30:20 <kayront> i'll resist making a joke about the ultimate privacy being having your transaction blacklisted :p
18:30:30 <selsta> Not sure what blacklisted means?
18:30:43 <kayront> not relayed
18:30:59 <kayront> maybe blacklist is not the best word
18:31:08 -xmr-pr- moneromooo-monero opened pull request #6935: keep track of peers' peer lists
18:31:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6935
18:31:11 <selsta> They do get relayed. Every hop starts a random timer and propagates it after a timeout.
18:31:58 <kayront> but does d++ use only one peer before (I assume) giving up and broadcasting to all connected peers eventually?
18:32:17 <kayront> because if yes, then it would relay yes, but only after the timeout. is this wrong?
18:32:50 <selsta> Yes, after a timeout. But malicious nodes don't know which hop they are so they can't say with certainty the source IP.
18:33:47 <selsta> Without Dandelion it is rather easy to find the source IP by setting up a large amount of nodes.
18:34:21 <kayront> not with certainty, but imagine there is quite a lot of them. and there might be some additional ways they've found out to increase the likelyhood of their nodes connecting to more peers than we could assume
18:34:33 <kayront> yes, i'm not criticizing d++ or saying it's a bad idea btw
18:34:50 <kayront> just trying to understand if someone is actually using it against monero
18:35:00 <selsta> Like I said we are working on minimizing the amount of timeouts.
18:35:08 <kayront> as a mild annoyance only? or part of something more ... elaborate
18:36:00 <selsta> These spy nodes existed for quite a long time, now they have it harder with finding the source IP with the tradeoff of a mild annoyance for the end user.
18:36:24 <kayront> that would fit too, yes
18:36:45 <selsta> Long term we are working on easier I2P / Tor integration (e.g. by adding seed nodes)
18:36:58 <selsta> tx-proxy works quite well already IMO
18:37:03 <kayront> re --tx-proxy, does it support setting a remote tcp socks5 proxy?
18:37:13 <kayront> i don't run tor in the same vm
18:37:17 <kayront> call me ultraparanoid
18:37:18 <kayront> :p
18:37:22 <selsta> I don’t know.
18:38:19 <kayront>  --tx-proxy arg                        Send local txes through proxy:
18:38:20 <kayront>                                         <network-type>,<socks-ip:port>[,max_con
18:38:20 <kayront>                                         nections][,disable_noise] i.e.
18:38:20 <kayront>                                         "tor,127.0.0.1:9050,100,disable_noise"
18:38:23 <kayront> looking good
18:38:38 <kayront> also
18:38:38 <kayront>   --anonymous-inbound arg               <hidden-service-address>,<[bind-ip:]por
18:38:38 <kayront>                                         t>[,max_connections] i.e.
18:38:38 <kayront>                                         "x.onion,127.0.0.1:18083,100"
18:38:45 <kayront> that's nice. i had no idea. things have been happening
18:39:16 <selsta> https://github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md
18:40:16 <kayront> yes, i confess i tuned out of the whole thing with the kovri fiasco
18:40:22 <kayront> clearly that was premature
18:41:13 <kayront> so will other peers actually find my .onion and presumably prefer to connect over tor?
18:41:59 <selsta> only tx get sent over Tor, you have to add one initial Tor peer (--add-peer) because we don’t have I2P / Tor seed nodes yet
18:42:06 <selsta> then it should work by itself
18:43:43 <kayront> do we have a list of such peers ?
18:43:53 <kayront> i tried the example .onion in the docs, seems to be down
18:44:20 <selsta> ./monerod --tx-proxy tor,127.0.0.1:9050 --add-peer xwvz3ekocr3dkyxfkmgm2hvbpzx2ysqmaxgter7znnqrhoicygkfswid.onion:18083 --add-peer zbjkbsxc5munw3qusl7j2hpcmikhqocdf4pqhnhtpzw5nt5jrmofptid.onion:18083
18:45:19 <kayront> cool, thanks
18:45:23 <kayront> btw,
18:45:26 <kayront> Active Bandwidth Shaping
18:45:26 <kayront> An attacker could attempt to bandwidth shape traffic in an attempt to determine the source of a Tor/I2P connection. There isn't great mitigation against this,
18:45:42 <kayront> how about https://nymtech.net ?
18:48:43 <kayront> also, curious: someone linked a list of bad nodes before, did someone write a program to identify them ?
18:49:08 <selsta> not familiar with bandwidth shaping so no idea
18:49:49 <kayront> check it out though, it seems legit (nym).
18:49:52 <selsta> it is easy to identify them with, pop ~1000 blocks, start with --no-sync and wait for nodes that mirror your block height (sync_info)
18:51:06 <iDunk> Looks like +m worked, lol.
18:51:23 <selsta> :D
18:51:50 <iDunk> And I didn't even notice the other ones above :)
18:53:44 <fluffypony> iDunk: yeah +m is extreme but it works
18:54:09 <iDunk> No complaints here.
18:55:57 <asymptotically> in -pools we banned all tor users and then exempted the people that use it and aren't spammers
18:56:17 <kayront> you torist!
18:56:23 <asymptotically> i think the best solution would be to quiet all tor users, exempt good people, and make it so that ops can see messages from quieted people (but i forgot how to do that)
18:58:13 * moneromooo amazed -pools banned spammers
18:58:24 <Inge-> -pools is such a model citizen
18:58:39 <asymptotically> lots of well informed discussion in -pools, wouldn't want it to be interrupted
18:59:02 <Inge-> Are seed nodes likely to implement AHP bans, or have already?
19:00:03 <moneromooo> Mine doesn't. I might at some point.
19:03:42 <Inge-> I really don't like there being a bunch of nodes that are at best assholes, and not unlikely to be malicious / logging
19:43:13 <normo> exit
22:50:00 <luigi1111> quit
23:17:42 <Inge-> m2049r: Andreas' favorite wallet is monerujo :D