Isthmus: please share on Reddit

selsta : just went through this backlog finally - Bitcoin does not have a Dandelion++ implementation, only a Dandelion (afaik)

which is why I mildly trolled some Bitcoin fork trolling us about "finally" getting Dandelion ... waiting for them to write their own code for D++

vtnerd_: dandelion-org/bitcoin d043e36

That’s the version all Bitcoin forks use, any quick way to check if it is D or D++?

selsta: ping me to make a ranked-choice poll once we have more ideas :)

sgp_: Should we post to Reddit before or after you created the poll?

just 2 names to choose from?

Neptune

selsta: how urgent is this?

sgp_: We still have a couple of days

but would like to tag at the end of week

niocbrrrrrr: noo you can also suggest names

sorry I should learn to read

but I was too lazy to come up with my own

selsta: probably best to post on Reddit then to get ideas, then I'll make the poll in a day or two

oh look fluffy also suggested Neptune

thx :)

selsta: I can post to reddit if you want

okk

:)

Done

Also the testing thread is up

Thanks, I'll post on reddit shortly : )

I went through code previously, its the original dandelion protocol

the selection for fluff vs stem is done per tx in that commit, as opposed to "epoch" (per time period)

vtnerd_: interesting, thanks for looking

theres a few other differences too, but thats just a quick one

the thing is some of the forks probably don't have the devs to alter the protocol, so its just going to be word salad warfare

digibyte claiming D++ while only having D

correct, they were the ones I am thinking of in particular

DId you also look at Zcoin?

I cross-checked their code, it had no changes from this branch (at least at the time of one of my tweets)

I have not

I'm fairly certain grin has D++. I haven't checked their code, but their GitHub discussions indicated they at least understood some of the differences and were debating how to implement the protocol in practice

IIRC they made some updates to bring their original code more in line with the paper's specifications

grin? yes that was part of the discussion. the embargo timer was fairly short

FWIW the original Dandelion paper's results were based on very simplifying assumptions (I know that vtnerd knows this already) that don't hold in practice

This is one reason why D++ came about

one other intesting is that the paper for D++ was submitted to arxiv.org one may 28 2018 but the reference implementation (from dandelion-org) was comitted on may 9 2018. the authors wouldve/couldve known about the new protocol and released the code first, but the time would see backwards

*timing woudl seem

Jitsi fixed the issue where Chrome screenshare couldn't be done with a high framerate, which we observed during the Moneroversary (I used Firefox instead)

vtnerd_: are you willing to give a short presentation about your efforts adding Dandelion++ to Monero? The history, work, challenges, easy parts, benefits, drawbacks, etc? Could be useful to people

I think it could be very useful to explain particularly how the interaction between clearnet and non-clearnet are tricky and subtle to get right

and that "just add D++" isn't quite so simple

hmm. sounds useful, it would be at a higher level than my ramblings at monerokon last year. For some event in particular, or just for youtube?

zerocoin appears to be the same reference Dandelion code that digibyte is using

I wouldn’t be surprised if they don’t even know which version they have

selsta read my book

Guiz, dunno if you heard, but I'm not on vacation anymore.

So if you want me to do something please continue doing it yourself and leaving me alone. K thx.

sarang vtnerd_: I'm not thinking about a Breaking Monero-type episode. More of a debrief

Doesn't need to be for a particular event, just YouTube explaining what you did and why, what was difficult, etc.

I was inspired by the Jitsi call today where they talked about their infrastructure a bit and dealing with scaling it while it was on fire under ready load

sgp: Is there some definition of what number of streams a Jitsi server can support? I read comments from a radom guy stating that it's weak in that way, poor scaling to thousands.

It must be a big headache determining performance limits when comparing a lot of platforms.

I have no idea where the performance limit is. There are many things that can still be improved, such as the old VP8 codec

VP9 has been pretty standard for 6 years, no?

Interesting, but the impression I got was that when comparing Jitsi to other platforms (probably with similar codec strategy) the others win. I'm probably wrong about this, just an impression that made me think.

Discord is even worse when video is used, the AltspaceVR (thing that rehrar found) was way ahead with twenty thousand or something, maybe because it's vector? I don't know.

Quite a depressing mess.

I guess BlackHat is using on24, which scales great but I've never heard of it.