needmoney90: what's up?

.merges

is it just me or maintaining peers over tor is extremely shaky? i've been unable to send transactions about 95% of the time since changing the setting, because monerod almost never has a tor peer going

same here

even though I have a bunch of incoming p2p tor connections

which makes that errmsg rather weird - if there are incoming tor peers, why do we care if there are no outbound?

kayront add some peers with --add-priority-node -- kinda hacky but works for me to make i2p usable

something about inbound connections being less trusted? they're sort of tied to an identity base on the i2p address since it only changes if you change it manually. cant recall if there was another reason

Eve can easily Sybil a node with tor connections.

You at least choose your outbound connections.

sorry but what is the actual harm of a sybil attack in this scenario?

Dandelion loses its ability to keep tx origin private.

e.g., suppose a node has *only* tor connections, and only inbound. if it receives a txn, obviously over tor, doesn't seem like there's any harm in relaying it onward

There is: if Eve receives tx A on all her sybils, she can guess it's not yours. Otherwise, fair probability it's yours.

There is: if Eve receives tx A *from your node* on all her sybils, she can guess it's not yours. Otherwise, fair probability it's yours.

ok

sounds like that assumption only works if the txn is received on all sybils at around the same time

if they're received at non-uniform times, there's no way to know that they weren't relayed thru another node first

If Alice has tx A and receives the A fron another node later, she will do nothing.

So if Eve receives A from Alice on one Sybil, then A again from Alice some time later on another sybil, she knows it didn't come from another peer either.

It's just Alice being very slow.

^ but you can defeat that rule obviously, by having Alice repeat send of A

You'd have Alice relay txes several times at random-ish intervals ? Presumably not to all peers at once ?

yes

and not even all the time. only with N% probability

Not sure what that'd do to dandelion privacy, but it's suck for extra bandwidth and extra latency, at least.

Well, not extra latency since we already eat that.

e.g. if only 10% of txs get a redundant send, impact isn't too bad

but the uncertainty destroys that heuristic.

10% chance you're wrong ?

the guess becomes meaningless, with other random network latencies taken into consideration

there's a multiplicative effect

which is also why you couldn't use ratios above 25-30% or so - the network would totally swamp itself

any final opinions if we should include monero-project/monero #6936 in next release?

FWIW the daemon hasn't crashed again, and the other one runnning the patch never did.

I’m fine with including it, it also never crashed for me

xiphon: any preference on monero-project/monero #6936? would you include it?

selsta: yep

ok 6933 6940 6942 6944 6946 6954 would also require reviews

most of them are quite small

6954 done

ty

"I am the function with no name: Zapp Brannigan"

moneromooo: I assume I2P / Tor connections always have a score of 0 so this does not apply? monero-project/monero #6940

or they use a completely different function

atm I think tor/i2p peers should always have 0 score.

Define "does not apply".