Quote from: monero_badcaca on Today at 10:56:29 AM

Quote from: dragonvslinux on November 13, 2020, 08:18:57 PM

I'm looking forward to seeing some evidence behind these claims.

Simple. Use Monero, find out if you are on the list.

dragonvslinux, I think that by now it’s obvious that badcaca has nothing except s’kiddie-tier bragging, bluffing, and spamming the shit out of this forum with long lists of txids, randomly selected peer IPs, and annotations of what are probably just his own porn fantasies.

Proof: Simple. Ask him some technical questions, find out if he has an answer.

Quote from: nullius on November 13, 2020, 05:55:37 AM

I suggest reading the paper.

Quote from: nullius on November 12, 2020, 07:41:02 AM

Having read the actual Dandelion++ paper when it came out, I can safely call this ridiculous.

[...]

Quote from: monero_badcaca on November 12, 2020, 05:48:44 PM

You are confusing cause and effect here. Transaction sitting in node's mempool is caused by it being intercepted and then rebroadcast.

Quote from: monero_badcaca on November 12, 2020, 06:57:05 PM

There is no such thing as a public mempool on a p2p network level. What you are seeing on the website is a snapshot of one node's mempool. The way dandelion++ works is that the transaction will be put into the original node's mempool, broadcast in stem phase, and if the node doesn't see it again, it will be broadcast in fluff phase. The "not seeing it again" part is the cause of the delay.

Based on a reasonable inference of what you seem to be suggesting that you are trying to do: The Dandelion++ authors were way ahead of you. That is an admittedly low standard, because you don’t know what the hell you are doing. You are listing the IP addresses of random peers, exactly as I said!

§4.4 at p. 17 of the Dandelion++ paper speaks thusly:

If you claim to be defeating Dandelion++’s random timers, then please show your work with maths and stuff. (LOL, as if.)