Followup analysis of transaction confirmation delays. Four major pools set their block update template configurations to be every 10-20 seconds. Now the time to first confirmation is 60 seconds faster for the average Monero transaction:

nice

And for those interested in nonce patterns, the change shows up there too: imgur.com/a/wEzoEbE

<Rucknium[m]> "Followup analysis of transaction..." <- Is there any research going on how to improve the tx/block propagation time post-Dandelion? I understand that Dandelion implies that a certain delay has to be present but we often get support tickets related to issues with P2P tx/block propagation

Block propagation is not related to dandelion though.

In the BTC network people see unconfirmed txs almost instantly, whereas in XMR it takes minutes sometimes.

Alex | LocalMonero | AgoraDesk: sech1 made some improvements to block propagation recently. And maybe 9 months ago SethForPrivacy found a transaction construction slowdown that was fixed IIRC.

Transaction construction can be slow if you are using a remote node since you have to communicate with the node to create the transaction. You need the decoy output public keys, etc. rbrunner7 has a patch that speeds things up too IIRC.

With bitcoin and most other transparent blockchains you don't need to directly talk with a node to build transactions as long as you have the tx's public keys (addresses) stored in the wallet locally.

According to the original Dandelion++ paper, D++ is not supposed to slow down tx propagation very much.

Rucknium[m]: Wasn't talking about construction, just mempool propogation

I've said this a while back when dandelion++ was added to the protocol that tx mempool propagation had become noticeably slower. The problem persists to this day.

s/propogation/propagation/

In my original blog post ( rucknium.me/posts/monero-pool-transaction-delay/#data ) I said: "About 50 percent of all transactions arrived at all five Monero nodes within a two-second interval. 95 percent all transactions arrived at all five Monero nodes within a five-second interval."

I left it out of the Reddit post since it got into deeper details of data collection and management

^ But the delay between nodes probably would only show "fluff" phase delay. Stem delay would not appear in the data there, probably

Users don't always know the difference between tx construction and mempool propagation

Most probably do not

this "95% within 5 seconds" is for transactions which are already in the fluff phase

when they are in the stem phase, it's unlikely any of your nodes would see them

and stem phase can take 30 seconds easily

I use tx-proxy with the disable_noise flag to bypass dandelion altogether

Alex | LocalMonero | AgoraDesk:

sech1: Yes that's what I tried to say. The original D++ paper moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=122 says

"We show that Dandelion++ does not increase latency significantly compared to current methods for broadcasting transactions, and it is robust to node failures and misbehavior."

From their Figure 11 it looks like it takes about 8 seconds to enter fluff phase

if some node drops a transaction in the stem phase, this transaction will be delayed a lot, depending on timeout

8 seconds is not bad, but this is average

it can be much higher for unlucky transactions

Yeah I don't know where y'all are getting 5 seconds but as a real world business I can tell you that it's certainly not 5 seconds.

There's a tx propagation delay and there's a block propagation delay, both of which may have different root causes but lead to plenty of points of friction.

<ofrnxmr[m]> "I use tx-proxy with the disable_..." <- Wouldn't that be a privacy compromise?

4+

Id argue still more private then dsndelion, because the tx are relayed over onions

Alex | LocalMonero | AgoraDesk: The 5 seconds isn't meant to measure the time between a user sending a tx and it reaching all nodes. It was to see if different mining nodes are seeing different txs at different times.

I needed to make sure that I didn't somehow have bias in my calculations due to which nodes i was using to collect mempool data

ofrnxmr[m]: Onions are slow usually, how quickly do you see a tx on a wallet connected to another, random node?

s/a/that/

In my experience, 2-3 seconds

(Sending to an exchange )

Oh, nice. Might try it out.

This is gold, thanks!

I can add that I also use i2p for broadcasting and have noticed practically no delay e.g. between sending to someone and them seeing the TX

that's with noise still on too

<Alex|LocalMonero> "Onions are slow usually, how..." <- Onions actually are pretty fast relative to that proxy thing

Dandelion

Yeah testing it out to see if we get better propagation.

Ok

Oh yeah, it helped as fuck

Should be recommended practice universally.

Alex | LocalMonero | AgoraDesk: Other nodes will be able to determine that transactions originated from LocalMonero nodes. It's your decision, but make sure you understand the privacy implications of this type of choice.

Rucknium[m]: On tor?

Possibly yes if the LocalMonero transaction volume is much higher than other people using Onion nodes

And there is the Tor DDoS to consider, too

Is there no clearnet ddos?

vtnerd: What do you think about the privacy implications of using Tor vs. Dandelion++ to broadcast transactions?

selsta:

> Possibly yes if the LocalMonero transaction volume is much higher than other people using Onion nodes... (full message at <libera.ems.host/_matrix/media/v3/do…cd3ff987a312fb7cd3a46f8decb9c5c8bc5>)

vtnerd is best to answer this but tx-proxy is always preferred over clearnet, even with noise disabled

<selsta> "vtnerd is best to answer this..." <- So it's ore private *and* faster? That's a great trade-off.

s/ore/more/, s/*and*/_and_/