09:33:55 Maybe one of the resident Linux cracks can help me out, with a problem installing libzmq3-dev on a new Debian Buster system 09:34:33 It complains about a problem with a needed, referenced package, and when I follow the chain, I finally arrive at this: https://paste.centos.org/view/88008a96 09:35:46 My attempts to remove the general "E: Unable to correct problems, you have held broken packages." error with various tips from the Internet have been unsuccessful so far. 09:38:06 rbrunner: what's the output for apt-cache policy libcom-err2 09:39:45 https://paste.centos.org/view/00f977d7 09:42:19 ok apt-get install libcom-err2=1.44.5-1+deb10u3 09:42:27 I have now 2 kernels on this system because of driver problems, but went back to the older, "standard" Buster one 09:42:36 and then apt-mark hold libcom-err2 09:42:39 so that it doesn't update it 09:44:12 Ha, many thanks, worked without problems. So the system was not clever enough to find out on its own a combination that would work? 09:44:30 yeah something else in the chain was trying to force a more recent version of libcom-err2 09:44:41 so you just manually install it and then block any updates and voila 09:45:18 Alright. Now I can build the one true coin there is on this planet, Monero :) 09:45:25 using aptitude instead of apt helps with these conflicts 09:45:35 ErCiccione[m]: sometimes, yes 09:45:52 sometimes aptitude gets stuck in dependency hell just as badly 09:45:54 yeah, sometimes makes things worse :) 09:46:46 A manual fix is always the way to go when possible, in my experience 19:50:10 What's the average/expected transaction delay introduced by dandelion++? I wonder if instant payments on xmrto and bets on minko (both are zero-confirmation), have just become extremeley sluggish between pressing "send" and seeing anything happen on the recceiver end 19:51:32 It's more vulnerable to asshole peers who drop dandelion txes. Other than that, it shouldn't be more that a few seconds. 19:52:16 If a peer doesn't know about dandelion, it will relay it normally, so it should be even faster until everyone's updadated. 19:53:16 If a peer is an asshole and drops, there's a timeout, I don't recall the value, but it's about order of 10 seconds or so I think. 19:57:21 binaryFate: is it sluggish for you? 19:58:12 I did some testing between D++ nodes and didn’t notice any delay but that was before the network updated. 19:58:47 What delay is being seen? 20:00:40 Well sluggish is relative, I'm just wondering because of some feedback mentioning ~20s more than usual 20:01:08 Might be for any other reason, I just realized I never wondered what was the actual practical delay added by dandelion++ :) 20:02:54 IIRC Isthmus and friends maintain archival nodes, but I don't know if they're otherwise connected or have a topology that implies better overall connectivity to the network than the average node 20:03:04 also not sure if they're doing such timing data 20:04:29 Yep, we've got archival nodes 20:04:41 Studying impact of D++ would be interesting 20:05:48 We could also test each organic node for D++ functionality by connecting directly and sending some pilot transactions to see if it respects D++ rules or always rebroadcasts immediately. 20:06:56 The Monero archival nodes aren't put together in any particular configuration. However I've been experimenting with overlaying floodnets on top of p2p nets to reduce global prop time 20:07:21 Mmm this all sounds interesting but overkill for my question :) I have no idea of the delay used in the Dandelion++ code to decide if/when to relay a transaction, I'm just curious about that 20:09:06 Btw I wanted to update https://community.xmr.to/network to show Dandelion++ enabled node vs. others. But apparently the poking mechanism to determine if a node is dandelion-enabled or not, is too heavy to integrate in a gentle network crawler 20:10:26 But if you find a gentle way to detect them, let me know. Hopefully not, as moneromooo said, we probably prefer fingerprinting to not be too easy 20:28:27 binaryFate: yep, can confirm that minko is super slow at the moment 20:28:43 takes like 1 minute for tx to show up 20:30:06 Might be on our side, I didn't check anything. But it made me curious if Dandelion++ would introduce a ~1s delay for players, or a ~1mn? 20:30:28 vtnerd commented on this a while back because I have to ask the same 20:30:34 but have to look at backlog 20:30:44 I care mostly for xmrto instant transactions, for people using it in real life to pay for a bar or something like that 20:34:52 binaryFate: if it works correctly D++ should take 2-3 seconds (upper bound) according to vtnerd 20:36:01 in most cases less, unless someone "black holes" the tx 20:36:04 kinda what mooo said 20:37:57 Great! so I'll check things on xmrto/minko side, and I learned something, thanks guys 20:38:49 tested again between my two nodes and it took 1-2 sec 22:15:28 Hmm, services that want to be able to get txns into the mempool with no delay for UX reasons might just want to set their node to `--instant-fluff` and broadcast directly. Effective a latency <> network (off-chain) privacy tradeoff. 22:21:09 Is there any anti-black-hole mechanism? Stem length is probabilistic of course, but if the network uses parameters that target an upper bound of 3 secondish, something has probably gone wrong if I don't hear it post-fluff within 30 seconds. 22:21:25 Imagining: if my node propagates a D++ txn (heard stem from peer 1, sent stem to peer 7) and doesn't hear it from from anybody else within 30 seconds, maybe I stem out to peer 4 for good measure. 22:21:32 The protocol specifically accounts for this 22:21:41 Oh cool, I've looked at it, but haven't done a thorough deep dive 22:21:51 If it doesn't see a stem transaction again within a window, it fluffs it and assumes the worst 22:22:01 Perfect. 22:22:05 That's a key part of D++ 22:22:30 I figured/hoped there was probably some mechanism in place : ) 22:22:35 indeed 23:07:13 moneromooo: btw oss-fuzz switched from travis to github actions, this might fix your travis issue 23:07:35 afaik you deactivated afl because it made travis fail 23:07:51 I did. 23:08:11 Thanks, that might help if the timeout on load is more leninet. 23:13:06 ffmpeg now passes all sanitizers 23:13:13 but I didn’t understand what made it fail in the first place