06:16:12 <m-relay> <j​effro256:monero.social> Selsta: sorry open what against release branch ?
06:17:10 <m-relay> <j​effro256:monero.social> Sech and moneromooo and 0xfffc: will try this out later thank you for the pointers
10:17:24 <selsta> jeffro256: tests bug fix
12:26:57 <xFFFC0000> if anybody interested in performance measurement of monerod, DM me. I tried bolt on monerod successfully, but I want to measure long term performance improvement. https://github.com/llvm/llvm-project/tree/main/bolt 
14:08:51 <m-relay> <a​lex:agoradesk.com> How long will it take for the block size to adjust to the current tx volume, more or less?
14:11:09 <selsta> someone shared a graphic in the regular monero channel
14:12:05 <sech1> it grows very slowly because the spammer uses minimal fees
14:13:40 <sech1> a rule of thumb will be ~1.5 kB median size growth every 50 blocks
14:15:24 <sech1> right now, if you use any fee higher than the minimal, your tx will be confirmed in the first block
14:47:19 <selsta> .merge+ 9214 9217
14:47:19 <xmr-pr> Added
14:47:21 <selsta> .merges
14:47:22 -xmr-pr- 9166 9167 9168 9169 9170 9179 9184 9187 9195 9214 9217
15:28:15 <m-relay> <j​effro256:monero.social> Sorry to pile on another commit before the next release, but this one-line PR might be important to include: https://github.com/monero-project/monero/pull/9218
15:28:29 <m-relay> <j​effro256:monero.social> Props to boog900 for bringing up the issue
15:30:15 <sech1> hmm, interesting
15:30:40 <sech1> not a big impact though, because nodes have many connections between each other, and only one of them will drop
15:35:34 <m-relay> <j​effro256:monero.social> Depends on which nodes have which tx in a double spend. If the constructor can propagate 2 txs at the same time at about the same-ish rate, then worst case the network gets partitioned into 2 big chunks
15:36:09 <m-relay> <j​effro256:monero.social> In practice, probably easier said than done but still..
15:40:31 <m-relay> <j​effro256:monero.social> Actually WORST case is attacker sends a different double spend tx to each individual node and everyone disconnects from everyone else
15:41:44 <sech1> Dandelion++ will reduce the scale of it because it's not broadcasted until after a few intermediate nodes
15:42:40 <m-relay> <j​effro256:monero.social> only for txs in stem phase right? (which is controllable by attacker)
15:43:51 <sech1> yes
15:44:26 <m-relay> <j​effro256:monero.social> In fact, dandelion++ might make the attack worse since if I do put the tx into stem phase, that gives me more time to set up more double spends before fluff relay begins
15:44:38 <sech1> but if you broadcast right away, you will just increase the chance of only your direct peers separating from the rest of the network
15:44:58 <sech1> it needs testing
15:45:30 <sech1> I suspect that nodes having at least 10-20 connections will have at least a few of them surviving, so network will not split
15:45:44 <sech1> IIRC we have 12 outgoing by default
15:47:33 <m-relay> <j​effro256:monero.social> I only increase the chance for separating just my direct peers *IF* I don't leverage the fact that there's nothing stopping me from making 1000+ connections directly to all nodes I know about (besides my service speed)
15:48:37 <sech1> the nodes that really matter are mining pool nodes
15:48:44 <sech1> no need for 1000+ connections
17:35:41 <selsta> moneromoooo: do you remember what the default priority (0) should mean? automatically selected so that it gets in the next block? or something else?
18:21:34 <m-relay> <s​gp_:monero.social> iirc, default chooses either the lowest or normal depending on network conditions. I don't think it goes above normal
20:03:29 <m-relay> <s​gp_:monero.social> The state of Cake's monero nodes, in case you didn't see them: https://twitter.com/tannerdsilva/status/1765778590883328056
20:03:55 <m-relay> <s​gp_:monero.social> I'm sure Tanner could help dig into logs to help discover the stress points
20:05:51 <selsta> it's likely the large txpool that causes this
20:14:41 <Lyza> mine is chugging along nicely ^.^
20:15:07 <selsta> it's a combination of a lot of connections per node and large txpool
20:15:37 <Lyza> 138 peers using like 1 core of a 12yo server cpu
20:15:44 <selsta> i mean rpc connections
20:15:45 <Lyza> not nearly the rpc traffic thwy have obvs
20:15:55 <selsta> or do you have 138 rpc connections?
20:16:03 <Lyza> on because every rpc user gets the whole mempool
20:16:08 <Lyza> no no I peeant p2p
20:16:11 <Lyza> meant*
20:24:14 <selsta> increasing the interval between refreshes in cake wallet could reduce the the load on nodes
20:45:51 <rbrunner> Hmm, if my "incremental" pool query code is working correctly, refresh intervals should hardly make any difference, because only deltas are transferred
20:46:11 <rbrunner> Assumining that enough wallets and daemons already use the code of course
21:16:58 <moneromoooo> IIRC what sgp_ said. 0 auto adapts betwen normal and low.
22:19:58 <m-relay> <f​reestatemag:matrix.org> Hey guys, I wandered in here awhile back(few years?)and you all were discussing a project that was in the works. It was a dex built on top, or around monero. I cant remember the name but I do remember seeing that at one point there was discussion about forking another dex infrastructure, I think it may have been bisq? I was just wondering if that project is still in the works?
22:20:29 <selsta> checkout haveno on irc / matrix
22:23:16 <m-relay> <f​reestatemag:matrix.org> Thanksa
23:01:27 <m-relay> <d​olores.sabaneta:matrix.org> What do the checkpoints in the checkpoints.cpp file do ? Is it some kind of hardcoded block height below which the blockchain can't be changed and on which PoW does not apply ? Could all the nodes prune the blockchain below the highest checkpoint ?
23:02:43 <selsta> nodes can't prune below the highest checkpoint
23:03:35 <selsta> it's simply a hardcoded transaction hash to a specific height which can't be changed