<j​effro256:monero.social> Selsta: sorry open what against release branch ?

<j​effro256:monero.social> Sech and moneromooo and 0xfffc: will try this out later thank you for the pointers

jeffro256: tests bug fix

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. github.com/llvm/llvm-project/tree/main/bolt

<a​lex:agoradesk.com> How long will it take for the block size to adjust to the current tx volume, more or less?

someone shared a graphic in the regular monero channel

it grows very slowly because the spammer uses minimal fees

a rule of thumb will be ~1.5 kB median size growth every 50 blocks

right now, if you use any fee higher than the minimal, your tx will be confirmed in the first block

.merge+ 9214 9217

Added

.merges

<j​effro256:monero.social> Sorry to pile on another commit before the next release, but this one-line PR might be important to include: monero-project/monero #9218

<j​effro256:monero.social> Props to boog900 for bringing up the issue

hmm, interesting

not a big impact though, because nodes have many connections between each other, and only one of them will drop

<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

<j​effro256:monero.social> In practice, probably easier said than done but still..

<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

Dandelion++ will reduce the scale of it because it's not broadcasted until after a few intermediate nodes

<j​effro256:monero.social> only for txs in stem phase right? (which is controllable by attacker)

yes

<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

but if you broadcast right away, you will just increase the chance of only your direct peers separating from the rest of the network

it needs testing

I suspect that nodes having at least 10-20 connections will have at least a few of them surviving, so network will not split

IIRC we have 12 outgoing by default

<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)

the nodes that really matter are mining pool nodes

no need for 1000+ connections

moneromoooo: do you remember what the default priority (0) should mean? automatically selected so that it gets in the next block? or something else?

<s​gp_:monero.social> iirc, default chooses either the lowest or normal depending on network conditions. I don't think it goes above normal

<s​gp_:monero.social> The state of Cake's monero nodes, in case you didn't see them: twitter.com/tannerdsilva/status/1765778590883328056

<s​gp_:monero.social> I'm sure Tanner could help dig into logs to help discover the stress points

it's likely the large txpool that causes this

mine is chugging along nicely ^.^

it's a combination of a lot of connections per node and large txpool

138 peers using like 1 core of a 12yo server cpu

i mean rpc connections

not nearly the rpc traffic thwy have obvs

or do you have 138 rpc connections?

on because every rpc user gets the whole mempool

no no I peeant p2p

meant*

increasing the interval between refreshes in cake wallet could reduce the the load on nodes

Hmm, if my "incremental" pool query code is working correctly, refresh intervals should hardly make any difference, because only deltas are transferred

Assumining that enough wallets and daemons already use the code of course

IIRC what sgp_ said. 0 auto adapts betwen normal and low.

<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?

checkout haveno on irc / matrix

<f​reestatemag:matrix.org> Thanksa

<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 ?

nodes can't prune below the highest checkpoint

it's simply a hardcoded transaction hash to a specific height which can't be changed