-
fluffypony
sigh
-
djwoveoaq
Dear fireice_uk. I must strongly object to you reporting our great Monero community members
-
djwoveoaq
to Freenode for racism AND getting people K-lined as a result!
i.imgur.com/R0T9GGY.png
-
djwoveoaq
THEY ARE NOT NEO-NAZI!!! THEY ARE JUST SAYING NEO-NAZI THINGS!!
i.imgur.com/JYu44As.png
-
djwoveoaq
I know this because they have been nice to me and made me their Magical Crypto Friend!
-
djwoveoaq
If you don't cease immediately I shall throw another tantrum!
-
djwoveoaq
Monero Community Member
-
djwoveoaq
PS. You are interrupting my session of masturbation to The Man in the High Castle.
-
fluffypony
setting +r in the room for now
-
fluffypony
so if you can't send messages please register with nickserv
-
tvhtcguqr
Dear fireice_uk. I must strongly object to you reporting our great Monero community members
-
tvhtcguqr
to Freenode for racism AND getting people K-lined as a result!
i.imgur.com/R0T9GGY.png
-
tvhtcguqr
THEY ARE NOT NEO-NAZI!!! THEY ARE JUST SAYING NEO-NAZI THINGS!!
i.imgur.com/JYu44As.png
-
tvhtcguqr
I know this because they have been nice to me and made me their Magical Crypto Friend!
-
tvhtcguqr
If you don't cease immediately I shall throw another tantrum!
-
tvhtcguqr
Monero Community Member
-
tvhtcguqr
PS. You are interrupting my session of masturbation to The Man in the High Castle.
-
fluffypony
lol of course they added a reg step to their script
-
fluffypony
+m for now
-
fluffypony
ping an op if you want voice
-
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
-
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
-
M5M400
kayront: what's your daemons status?
-
M5M400
i wonder if you're blocked with bad nodes
-
kayront
daemon seems fine
-
kayront
fully synced
-
kayront
maybe it's relevant, but it doesn't take any incoming connections. but again, this wasn't a problem until upgrading
-
kayront
(it doesn't have incoming connections by design, long story not worth going into)
-
M5M400
kayront: try blocking bad nodes...
paste.debian.net/hidden/52d10abe
-
kayront
what is this bad nodes story though?
-
kayront
transactions started failing pretty much immediately after upgrading daemon and wallet, just seems like a big coincidence
-
kayront
then upgraded to 1.1, now they take forever instead.. dunno, the timing is suspect
-
kayront
-
M5M400
in earlier v0.17 versions there was a propagation issue, which should have been rectified
-
M5M400
the bad nodes are run by an unknown actor, basically hogging all your peer slots and not propagating blocks at all
-
kayront
interesting
-
kayront
any theories ?
-
M5M400
trying to harvest tx data? trying to block tx and slow down the network? take your pick
-
kayront
but why not
-
kayront
now*
-
M5M400
because some three letter agencies put out bounties to make xmr traceable?
-
kayront
i'm beginning to feel really good about the very tight cage around monerod and monero-wallet-cli
-
kayront
lol
-
kayront
yeah, so i tried another tx 5 mins ago, still pending in the wallet, doesn't show up on block explorers
-
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
-
Lyza
ah well if it's not on the explorer's that's diff
-
kayront
well with v0.16 it was maybe 20 seconds until the wallet detected the tx was in the mempool
-
kayront
now it's many minutes before it even registers on a block explorer
-
Lyza
yeah it should be in the mempool for sure
-
kayront
now it's in the mempool, about 6min later
-
M5M400
hm.. mempool to your own node should be fast
-
kayront
well, i checked from a block explorer (not on my lan)
-
M5M400
then we're back at propagation
-
M5M400
try blocking those nodes and increase your out_peers to 64 or something
-
kayront
yeah
-
kayront
i blocked them already
-
kayront
could increase out peers, though the last time i did 64 it ended up running out of memory :p
-
M5M400
huh?
-
M5M400
smallish VM?
-
kayront
lot more tcp connections
-
kayront
not a lot of ram allocated
-
kayront
unhappy ending
-
kayront
but i have more memory now anyway
-
M5M400
mine runs on 256 in/out peers and doesn't snack much memory at all
node.supportxmr.com
-
kayront
it's vaguely concerning if evil nodes can partition my pet monerod away from the network so eadily though
-
Lyza
wondering why I haven't seen this issue -- does enabling incoming connections resolve it?
-
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
-
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
-
M5M400
seemed to have started about a week ago
-
Lyza
right kayront didn't mean as a sol'd for you necessarily but I was wondering more generally
-
M5M400
kayront: you could add some known community nodes as priority nodes in monerod
-
iDunk
It's been going on for over a year.
-
gingeropolous
iDunk, the AHP has been going on for over a year, or the transaction propagation delay?
-
iDunk
AHP
-
iDunk
#5732 and #5737 were the initial mitigations.
-
iDunk
#6920 works really well here.
-
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
-
gingeropolous
because up until the fork, some unknown % of the network was still just constant flood
-
gingeropolous
or some combination of those
-
Inge-
Where is the up-to-date banlist again?
-
asymptotically
-
gingeropolous
u can also use a live checker in the case that They start launching different IPs.
-
gingeropolous
i *think* my script is working - so far it produces the same list as selsta's. well lets do a diff
-
gingeropolous
yeah its the same as the one posted on gui.xmr.pm
-
gingeropolous
i want to look into the timer thing for "auto-fluff on fail" function
-
gingeropolous
like, even if there's some large % AHP on the network, your tx should get broadcast by the fallback
-
gingeropolous
so, because the fallback isn't working, that could mean that some large % of the network are AHP ..... ? or the fallback is buggy.
-
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.
-
iDunk
Maybe #6914 changed the dynamic there in some unexpected way.
-
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
-
gingeropolous
statisticians! where aaaarrreeee yoooouuuuuu
-
iDunk
Note that my daemon was eclipsed twice in two days before I started mass banning the AHPs.
-
gingeropolous
wow. amazing that just mirroring block height is so effective
-
iDunk
Once all your peers are AHPs, your daemon stops syncing, and it prints those "there were 0 blocks in..." type messages.
-
iDunk
And your txes are blackholed, as you mentioned earlier.
-
nioc
Almost all of my txs consistently take 3.5 to 4 minutes to show in mempool
-
gingeropolous
yah know, maybe i've avoided being blackholed by always using --add-priority-node
-
Inge-
nioc: do you have any AHP mitigation?
-
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
-
nioc
Inge-: no
-
nioc
Often means almost always if there are enough txs to be added
-
iDunk
Hmm, could that mean your txes are always sent by your daemon as fluff, never as stem after a timeout ?
-
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.
-
iDunk
For now, I tend to attribute sync and tx propagation issues to AHPs.
-
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
-
Inge-
iDunk: going on 3 minutes after banning AHPs
-
Inge-
4 minutes
-
Inge-
about 4 minutes...
-
iDunk
What was that average time..., 187 seconds or something like that ?
-
» iDunk afk
-
moneromooo
About right.
-
Inge-
I'm waiting for the promised 3s median :P
-
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.
-
selsta
Inge-: As long as everyone has 50% bad peers there will never be 3s median
-
gingeropolous
so what do we do
-
Lyza
are there so few connectable nodes that only 120 can commonly eclipse people, or is the peer list poisoning somehow really effective?
-
Lyza
120 is a much smaller number than I assumed
-
Lyza
given there are thousands of Monero nodes running
-
gingeropolous
i think seed nodes need to run this ban list asap
-
selsta
yea they are most likely adding seed nodes as priority peers
-
gingeropolous
crap, how do you get the records from seeds.moneroseeds.x?
-
gingeropolous
oh, its in the A list
-
hyc
why doesn't sync_info print column headers? I've no idea what some of these fields are
-
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
-
gingeropolous
its in the record of moneroseeds.se
-
gingeropolous
not the subdomain ...
-
selsta
gingeropolous: seed nodes are in the source code, not sure if dns seed nodes are used currently
-
gingeropolous
hardcoded seed nodes are a fallback afaik, if the seed nodes don't return lists
-
gingeropolous
err, if the dns seeders return empty, it uses hardcoded
-
gingeropolous
oh wait, it only seems to come up at src/p2p/net_node.h ...
-
gingeropolous
and dns check something
-
xmr-pr
moneromooo-monero opened pull request #6933: p2p: use /16 filtering on IPv4-within-IPv6 addresses
-
xmr-pr
-
gingeropolous
who needs headers?
-
xmr-pr
mj-xmr opened pull request #6934: Remove boost/optional from headers (mj-xmr)
-
xmr-pr
-
kayront
<nioc> Almost all of my txs consistently take 3.5 to 4 minutes to show in mempool
-
kayront
mine too! so is this then because of the malicious nodes?
-
kayront
i assumed some problem with dandelion
-
nioc
some where delayed before 0.17 but know it is consistent
-
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
-
nioc
some get into mempool quickly but that is rare
-
nioc
*but now
-
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
-
selsta
kayront: It is related to Dandelion++
-
kayront
do we know what the problem is selsta ?
-
selsta
Combination of multiple things but primarily there are malicious nodes that drop transactions.
-
kayront
did the addition of dandelion make it easier for them?
-
selsta
Easier to do what?
-
kayront
drop the txs
-
kayront
i haven't read much (any) on d++
-
selsta
Easier to spy? No. Dandelion makes it harder to spy for them.
-
kayront
just know what the idea is supposed to be
-
kayront
no, i mean, if the tx is only announced to one peer because of d++
-
kayront
then that makes it easier to blacklist
-
kayront
but i'm not sure it acvtually works like that
-
selsta
Yes, it makes it easier to drop transactions for them but you still get the privacy benefit of Dandelion
-
sethsimmons
Weirdly the person your talking to is not being relayed to Matrix
-
kayront
hmm, then i must really be missing smt here. won't the peer that blacklisted the tx know what it did?
-
sethsimmons
Idk why but it looks like you’re talking to yourself selsta
-
selsta
sethsimmons: not sure why
-
selsta
kayront: Can you elaborate?
-
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
-
kayront
if you have a large number of evil servers blocking transactions
-
kayront
and they were the first hop in the censoring of said tx
-
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
-
selsta
How do they know they were the first hop?
-
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?
-
kayront
it never gets beyond the first hop
-
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
-
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.
-
selsta
Dandelion++ is not 100% perfect but it still significantly better than without. For "perfect" privacy people can use --tx-proxy with I2P / Tor
-
kayront
it would be nice if someone else with better knowledge about the issue could comment later
-
kayront
i'll resist making a joke about the ultimate privacy being having your transaction blacklisted :p
-
selsta
Not sure what blacklisted means?
-
kayront
not relayed
-
kayront
maybe blacklist is not the best word
-
xmr-pr
moneromooo-monero opened pull request #6935: keep track of peers' peer lists
-
xmr-pr
-
selsta
They do get relayed. Every hop starts a random timer and propagates it after a timeout.
-
kayront
but does d++ use only one peer before (I assume) giving up and broadcasting to all connected peers eventually?
-
kayront
because if yes, then it would relay yes, but only after the timeout. is this wrong?
-
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.
-
selsta
Without Dandelion it is rather easy to find the source IP by setting up a large amount of nodes.
-
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
-
kayront
yes, i'm not criticizing d++ or saying it's a bad idea btw
-
kayront
just trying to understand if someone is actually using it against monero
-
selsta
Like I said we are working on minimizing the amount of timeouts.
-
kayront
as a mild annoyance only? or part of something more ... elaborate
-
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.
-
kayront
that would fit too, yes
-
selsta
Long term we are working on easier I2P / Tor integration (e.g. by adding seed nodes)
-
selsta
tx-proxy works quite well already IMO
-
kayront
re --tx-proxy, does it support setting a remote tcp socks5 proxy?
-
kayront
i don't run tor in the same vm
-
kayront
call me ultraparanoid
-
kayront
:p
-
selsta
I don’t know.
-
kayront
--tx-proxy arg Send local txes through proxy:
-
kayront
<network-type>,<socks-ip:port>[,max_con
-
kayront
nections][,disable_noise] i.e.
-
kayront
"tor,127.0.0.1:9050,100,disable_noise"
-
kayront
looking good
-
kayront
also
-
kayront
--anonymous-inbound arg <hidden-service-address>,<[bind-ip:]por
-
kayront
t>[,max_connections] i.e.
-
kayront
"x.onion,127.0.0.1:18083,100"
-
kayront
that's nice. i had no idea. things have been happening
-
selsta
-
kayront
yes, i confess i tuned out of the whole thing with the kovri fiasco
-
kayront
clearly that was premature
-
kayront
so will other peers actually find my .onion and presumably prefer to connect over tor?
-
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
-
selsta
then it should work by itself
-
kayront
do we have a list of such peers ?
-
kayront
i tried the example .onion in the docs, seems to be down
-
selsta
./monerod --tx-proxy tor,127.0.0.1:9050 --add-peer xwvz3ekocr3dkyxfkmgm2hvbpzx2ysqmaxgter7znnqrhoicygkfswid.onion:18083 --add-peer zbjkbsxc5munw3qusl7j2hpcmikhqocdf4pqhnhtpzw5nt5jrmofptid.onion:18083
-
kayront
cool, thanks
-
kayront
btw,
-
kayront
Active Bandwidth Shaping
-
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,
-
kayront
-
kayront
also, curious: someone linked a list of bad nodes before, did someone write a program to identify them ?
-
selsta
not familiar with bandwidth shaping so no idea
-
kayront
check it out though, it seems legit (nym).
-
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)
-
iDunk
Looks like +m worked, lol.
-
selsta
:D
-
iDunk
And I didn't even notice the other ones above :)
-
fluffypony
iDunk: yeah +m is extreme but it works
-
iDunk
No complaints here.
-
asymptotically
in -pools we banned all tor users and then exempted the people that use it and aren't spammers
-
kayront
you torist!
-
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)
-
» moneromooo amazed -pools banned spammers
-
Inge-
-pools is such a model citizen
-
asymptotically
lots of well informed discussion in -pools, wouldn't want it to be interrupted
-
Inge-
Are seed nodes likely to implement AHP bans, or have already?
-
moneromooo
Mine doesn't. I might at some point.
-
Inge-
I really don't like there being a bunch of nodes that are at best assholes, and not unlikely to be malicious / logging
-
normo
exit
-
luigi1111
quit
-
Inge-
m2049r: Andreas' favorite wallet is monerujo :D