16:52:51 <Rucknium[m]> 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:
16:52:53 <Rucknium[m]> https://www.reddit.com/r/Monero/comments/11nu4aj/monero_transaction_confirmations_are_now_60/
17:18:03 <hyc> nice
17:23:15 <merope> And for those interested in nonce patterns, the change shows up there too: https://imgur.com/a/wEzoEbE
17:41:47 <Alex|LocalMonero> <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 
17:42:48 <Alex|LocalMonero> Block propagation is not related to dandelion though.
17:43:18 <Alex|LocalMonero> In the BTC network people see unconfirmed txs almost instantly, whereas in XMR it takes minutes sometimes.
17:58:45 <Rucknium[m]> 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.
18:00:06 <Rucknium[m]> 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.
18:01:15 <Rucknium[m]> 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.
18:02:37 <Rucknium[m]> According to the original Dandelion++ paper, D++ is not supposed to slow down tx propagation very much.
18:03:03 <Alex|LocalMonero> Rucknium[m]: Wasn't talking about construction, just mempool propogation
18:04:10 <Alex|LocalMonero> 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.
18:04:29 <Alex|LocalMonero> s/propogation/propagation/
18:04:42 <Rucknium[m]> In my original blog post ( https://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."
18:05:31 <Rucknium[m]> I left it out of the Reddit post since it got into deeper details of data collection and management
18:06:09 <Rucknium[m]> ^ But the delay between nodes probably would only show "fluff" phase delay. Stem delay would not appear in the data there, probably
18:07:02 <Rucknium[m]> Users don't always know the difference between tx construction and mempool propagation
18:07:03 <Rucknium[m]> Most probably do not
18:08:34 <sech1> this "95% within 5 seconds" is for transactions which are already in the fluff phase
18:08:50 <sech1> when they are in the stem phase, it's unlikely any of your nodes would see them
18:09:03 <sech1> and stem phase can take 30 seconds easily
18:09:22 <ofrnxmr[m]> I use tx-proxy with the disable_noise flag to bypass dandelion altogether
18:09:54 <ofrnxmr[m]> Alex | LocalMonero | AgoraDesk: 
18:13:31 <Rucknium[m]> sech1: Yes that's what I tried to say. The original D++ paper https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=122 says
18:13:44 <Rucknium[m]> "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."
18:14:25 <Rucknium[m]> From their Figure 11 it looks like it takes about 8 seconds to enter fluff phase
18:15:05 <sech1> if some node drops a transaction in the stem phase, this transaction will be delayed a lot, depending on timeout
18:16:06 <sech1> 8 seconds is not bad, but this is average
18:16:15 <sech1> it can be much higher for unlucky transactions
18:17:23 <Alex|LocalMonero> 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.
18:19:27 <Alex|LocalMonero> 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.
18:19:46 <Alex|LocalMonero> <ofrnxmr[m]> "I use tx-proxy with the disable_..." <- Wouldn't that be a privacy compromise?
18:20:05 <dEBRUYNE> 4+
18:20:45 <ofrnxmr[m]> Id argue still more private then dsndelion, because the tx are relayed over onions
18:21:28 <Rucknium[m]> 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. 
18:21:59 <Rucknium[m]> 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
18:22:25 <Alex|LocalMonero> ofrnxmr[m]: Onions are slow usually, how quickly do you see a tx on a wallet connected to another, random node?
18:22:44 <Alex|LocalMonero> s/a/that/
18:22:45 <ofrnxmr[m]> In my experience, 2-3 seconds
18:22:51 <ofrnxmr[m]> (Sending to an exchange )
18:23:12 <Alex|LocalMonero> Oh, nice. Might try it out.
18:24:51 <ofrnxmr[m]> https://monerologs.net/monero-dev/20201107#c155018
18:26:48 <Alex|LocalMonero> This is gold, thanks!
19:34:19 <LyzaLittle> 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
19:35:35 <LyzaLittle> that's with noise still on too
20:38:32 <ghostway[m]> <Alex|LocalMonero> "Onions are slow usually, how..." <- Onions actually are pretty fast relative to that proxy thing
20:40:23 <ghostway[m]> Dandelion 
20:43:58 <Alex|LocalMonero> Yeah testing it out to see if we get better propagation.
20:44:37 <ghostway[m]> Ok
20:48:53 <Alex|LocalMonero> Oh yeah, it helped as fuck
20:49:26 <Alex|LocalMonero> Should be recommended practice universally.
20:50:39 <Rucknium[m]> 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.
20:51:06 <Alex|LocalMonero> Rucknium[m]: On tor?
20:51:57 <Rucknium[m]> Possibly yes if the LocalMonero transaction volume is much higher than other people using Onion nodes
20:52:17 <Rucknium[m]> And there is the Tor DDoS to consider, too
20:52:47 <Alex|LocalMonero> Is there no clearnet ddos?
20:54:58 <Rucknium[m]> vtnerd: What do you think about the privacy implications of using Tor vs. Dandelion++ to broadcast transactions?
20:56:04 <ofrnxmr[m]> selsta: 
21:06:06 <ofrnxmr[m]> > Possibly yes if the LocalMonero transaction volume is much higher than other people using Onion nodes... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/a164ecd3ff987a312fb7cd3a46f8decb9c5c8bc5>)
22:57:10 <selsta> vtnerd is best to answer this but tx-proxy is always preferred over clearnet, even with noise disabled
23:10:18 <Alex|LocalMonero> <selsta> "vtnerd is best to answer this..." <- So it's ore private *and* faster? That's a great trade-off.
23:10:30 <Alex|LocalMonero> s/ore/more/, s/*and*/_and_/