Maybe one of the resident Linux cracks can help me out, with a problem installing libzmq3-dev on a new Debian Buster system

It complains about a problem with a needed, referenced package, and when I follow the chain, I finally arrive at this: paste.centos.org/view/88008a96

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.

rbrunner: what's the output for apt-cache policy libcom-err2

ok apt-get install libcom-err2=1.44.5-1+deb10u3

I have now 2 kernels on this system because of driver problems, but went back to the older, "standard" Buster one

and then apt-mark hold libcom-err2

so that it doesn't update it

Ha, many thanks, worked without problems. So the system was not clever enough to find out on its own a combination that would work?

yeah something else in the chain was trying to force a more recent version of libcom-err2

so you just manually install it and then block any updates and voila

Alright. Now I can build the one true coin there is on this planet, Monero :)

using aptitude instead of apt helps with these conflicts

ErCiccione[m]: sometimes, yes

sometimes aptitude gets stuck in dependency hell just as badly

yeah, sometimes makes things worse :)

A manual fix is always the way to go when possible, in my experience

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

It's more vulnerable to asshole peers who drop dandelion txes. Other than that, it shouldn't be more that a few seconds.

If a peer doesn't know about dandelion, it will relay it normally, so it should be even faster until everyone's updadated.

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.

binaryFate: is it sluggish for you?

I did some testing between D++ nodes and didn’t notice any delay but that was before the network updated.

What delay is being seen?

Well sluggish is relative, I'm just wondering because of some feedback mentioning ~20s more than usual

Might be for any other reason, I just realized I never wondered what was the actual practical delay added by dandelion++ :)

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

also not sure if they're doing such timing data

Yep, we've got archival nodes

Studying impact of D++ would be interesting

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.

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

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

Btw I wanted to update 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

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

binaryFate: yep, can confirm that minko is super slow at the moment

takes like 1 minute for tx to show up

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?

vtnerd commented on this a while back because I have to ask the same

but have to look at backlog

I care mostly for xmrto instant transactions, for people using it in real life to pay for a bar or something like that

binaryFate: if it works correctly D++ should take 2-3 seconds (upper bound) according to vtnerd

in most cases less, unless someone "black holes" the tx

kinda what mooo said

Great! so I'll check things on xmrto/minko side, and I learned something, thanks guys

tested again between my two nodes and it took 1-2 sec

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.

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.

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.

The protocol specifically accounts for this

Oh cool, I've looked at it, but haven't done a thorough deep dive

If it doesn't see a stem transaction again within a window, it fluffs it and assumes the worst

Perfect.

That's a key part of D++

I figured/hoped there was probably some mechanism in place : )

indeed

moneromooo: btw oss-fuzz switched from travis to github actions, this might fix your travis issue

afaik you deactivated afl because it made travis fail

I did.

Thanks, that might help if the timeout on load is more leninet.

ffmpeg now passes all sanitizers

but I didn’t understand what made it fail in the first place