<f​r33_yourself:monero.social> Isn't it better to just have a tighter block expansion algorithm instead of raising fees manually? Because tighter blocks allow genuine increase in fee market.

<r​ucknium:monero.social> fr33_yourself: IMHO, probably not because you're going into untested code and untested economics. Maybe, once the code and economics is tested better.

<r​ucknium:monero.social> Until a few months ago, Monero's default wallet didn't even automatically increase its fee once blocks became congested. It was unintentional behavior that was fixed in a patch. By "untested economics" I mean we would want to know answer to questions like "What is the demand elasticity for block size along almost the entire demand curve, and how does it evolve over time?", "How do<clipped message

<r​ucknium:monero.social> agents react when they cannot replace-by-fee their bids to include txs in blocks?", "How does the block space auction work when there are only 4 default bidding levels?"

<r​ucknium:monero.social> The 100-block median resets when there is a period (at any time!) of 50 blocks below the default maximum. You could have an increase that would permit more txs in a block, and then suddenly back to the default on a Sunday when tx volume is usually low.

<r​ucknium:monero.social> And we know now that nodes do not handle large txpools well. (To raise the block size, you need some txpool congestion.). I hope the stressnet will allow developers to investigate the cause and fix it.

<r​brunner7:monero.social> Regarding the issue of Monero daemons stopping to sync properly with a default of 20 blocks at at time, detected on stressnet, discussed in this week's MRL meeting: monero-project/monero #9388

I think it's just the timeout being too tight. Happens on mainnet on tor.

<r​brunner7:monero.social> Maybe that also plays a role, but I actually saw it go over that numbers of strings limit in the debugger, and throwing because of this. I just could not interpret properly *where* in the data it was deserializing when it happened.

Oh nvm, it looks like you investigated it, I just read.

If it is that, then it seems odd it happened (for me) on mainnet, a lot, but it was detected (by others) on stressnet (stagenet ?).

<r​brunner7:monero.social> Not sure blocks were ever big enough on mainnet to hit this particular limit ...

Anyway, I added the sanity checks and they were totally arbitrary chosen.

<r​brunner7:monero.social> Alright :)

True, could be I actually hit timeouts as I had assumed, and you did not.

These limits should probably grow together with the median block size

<b​oog900:monero.social> Transactions/ block blobs are stored as strings in epee, do you know what the average tx count is around those big blocks? I think anything around 800 txs/block would cause the limit to be hit

<b​oog900:monero.social> while syncing 20 blocks at a time

<r​ucknium:monero.social> boog900: About 1,000 IIRC

moneromooo "stressnet" is a recent testnet fork, specifically for spamming tx's / finding issues that require multiple peers and such, their first report here: reddit.com/r/Monero/comments/1doyde9/stressnet_first_week_report

<b​oog900:monero.social> thanks, FWIW pruned txs are stored as objects so we may need to increase that limit a bit more for those syncing pruned blocks

##monero-stressnet (double #)

<r​ucknium:monero.social> boog900: I updated my gist with the tx/block numbers: gist.github.com/Rucknium/f092b0ad5870f6038226c39af529152c . Block sync at the default 20 started having problems at height 2521510...which is exactly when the number of txs/block goes above 800.

<b​oog900:monero.social> ah nice :)

800... jesus. How far we have travelled...

crappy serializer code, how surprising ...