01:07:43 needmoney90: what's up? 09:20:37 .merges 09:20:37 -xmr-pr- 6886 10:27:22 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 12:05:31 same here 12:06:17 even though I have a bunch of incoming p2p tor connections 12:07:31 which makes that errmsg rather weird - if there are incoming tor peers, why do we care if there are no outbound? 12:10:26 kayront add some peers with --add-priority-node -- kinda hacky but works for me to make i2p usable 12:11:16 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 12:20:27 Eve can easily Sybil a node with tor connections. 12:20:45 You at least choose your outbound connections. 12:49:20 sorry but what is the actual harm of a sybil attack in this scenario? 12:49:56 Dandelion loses its ability to keep tx origin private. 12:50:34 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 12:51:40 There is: if Eve receives tx A on all her sybils, she can guess it's not yours. Otherwise, fair probability it's yours. 12:52:19 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. 12:53:05 ok 12:55:09 sounds like that assumption only works if the txn is received on all sybils at around the same time 12:55:51 if they're received at non-uniform times, there's no way to know that they weren't relayed thru another node first 13:03:52 If Alice has tx A and receives the A fron another node later, she will do nothing. 13:04:29 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. 13:04:39 It's just Alice being very slow. 13:09:01 ^ but you can defeat that rule obviously, by having Alice repeat send of A 13:11:22 You'd have Alice relay txes several times at random-ish intervals ? Presumably not to all peers at once ? 13:11:28 yes 13:11:36 and not even all the time. only with N% probability 13:11:59 Not sure what that'd do to dandelion privacy, but it's suck for extra bandwidth and extra latency, at least. 13:12:29 Well, not extra latency since we already eat that. 13:12:49 e.g. if only 10% of txs get a redundant send, impact isn't too bad 13:13:04 but the uncertainty destroys that heuristic. 13:13:16 10% chance you're wrong ? 13:14:15 the guess becomes meaningless, with other random network latencies taken into consideration 13:14:30 * moneromooo would not be so sure 13:15:11 there's a multiplicative effect 13:15:34 which is also why you couldn't use ratios above 25-30% or so - the network would totally swamp itself 15:46:08 -xmr-pr- mj-xmr opened pull request #6956: Clang build time analyser mj xmr 15:46:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6956 17:31:08 -xmr-pr- phreaknik opened issue #6958: monerod crashes during resync: Exception in threadpool 17:31:08 -xmr-pr- > https://github.com/monero-project/monero/issues/6958 17:31:09 -xmr-pr- phreaknik opened issue #6957: monerod crashes during resync: Exception in threadpool 17:31:09 -xmr-pr- > https://github.com/monero-project/monero/issues/6957 19:24:03 any final opinions if we should include https://github.com/monero-project/monero/pull/6936 in next release? 19:27:06 FWIW the daemon hasn't crashed again, and the other one runnning the patch never did. 19:32:27 I’m fine with including it, it also never crashed for me 19:33:07 xiphon: any preference on https://github.com/monero-project/monero/pull/6936? would you include it? 19:43:41 selsta: yep 19:48:58 ok 6933 6940 6942 6944 6946 6954 would also require reviews 19:49:15 most of them are quite small 19:52:00 * moneromooo grumbles about functions with no names 19:58:30 6954 done 20:02:59 ty 20:18:35 "I am the function with no name: Zapp Brannigan" 20:52:56 moneromooo: I assume I2P / Tor connections always have a score of 0 so this does not apply? https://github.com/monero-project/monero/pull/6940 20:53:09 or they use a completely different function 21:30:24 atm I think tor/i2p peers should always have 0 score. 21:30:36 Define "does not apply".