I'm starting to collect mempool data and I saw something interesting. Maybe this is already a known fact.

It looks like mining pool operators update the block template that they send to client miners only once: when the previous block has been found. If true, that means that any transactions broadcast on the network (and confirmed by a mining pool) have to wait two blocks for their first confirmation, not one block.

That would mean that transactions are on average taking 2 minutes longer to confirm, on average, than the ideal with an instant template update.

p2pool updates its block template every 10 seconds. In a quick spot check, p2pool's found blocks do seem to have been updated with new txs more frequently.

This also means that pool operators are, individually, leaving money on the table. It's not a lot of money because tx fee revenue is low for now.

I wonder if this is the default behavior of jtgrassie 's monero-pool software. Can it be changed?

This is all based on preliminary data analysis.

p2pool updates whenever a new sidechain block is found (10 secnds on average), and it has a forced update after 30 seconds

nanopool force updates templates every minute

you can just run xmrig, connect to a pool of your interest, and watch the last number in "new job" lines in console - it has the number of transactions in the template

and if you run with fixed difficulty, you can also check how often pool sends you new jobs

p2pool also has 10 second delay for every new transaction before it gets included, to account for tx propagation delays

sech1: Thanks for the info. Do you think my hypothesis about most pools is correct?

yes, I noticed it before too

big pools can't send new jobs very often, they have 10s of thousands of miners connected

not because of the traffic, but because of the load on DB

each job for each miner needs to be saved

Looks like we can get a big improvement in tx confirmation times if pools change their block template update behavior. It's in their self interest to do so, too.

not just miner wallet, but each connected xmrig

Yes I was wondering about the computational/bandwidth cost

p2pool has an advantage, it doesn't need to save anything and it doesn't need to handle everything in one database

it can also force send new job to miners if an especially fat (high fee) transaction is received (this logic is not implemented yet)

which is logical because whoever pays high fee, wants it to be mined fast

Deviations from economic rationality like this make me slightly worried about the dynamic block size and fee mechanisms that we have in place.

Pools just use whatever transaction picking algorithm is in monerod

p2pool uses its own algorithm which is a bit more advanced, but it always makes better (higher block reward) choices

and it tends to settle at 301500 bytes block size when mempool is full (+1500 bytes over median)

Is the logic for either algorithm documented anywhere?

no, it's only in the source code

but the general logic is "sort by fee per byte and select the highest first"

The difficult part is to decide when to start pushing the block size up and then through the block reward penalty threshold.

monerod just keeps adding as long as the block reward increases

p2pool tries to shuffle and replace other transactions to hit that sweet spot of block size and get higher reward

there's also an algorithm that finds an optimal solution (it's a discrete knapsack problem), but it's too slow for real use

I can confirm that some mining pools update block template more often

MoneroOcean in particular -- I think they have customized the pool software to a good degree

or maybe I'm dumb and looking at the wrong number ignore me, looks like 1 update per block, never noticed

Rucknium[m]: code segment that implements it in p2pool which is lightly commented fair enough github.com/SChernykh/p2pool/blob/4b…1f/src/block_template.cpp#L263-L552

to test the vs the optimal one #define TEST_MEMPOOL_PICKING_ALGORITHM 1

Thanks!

Rucknium[m]: "I wonder if this is the default behavior of jtgrassie 's monero-pool" <- No, not quite

monero-pool updates the template when either the network height changes or on a configurable timer

which is typically set to 30 seconds, though can be whatever the pool op desires

jtgrassie: Thank you. I tried to find a config option in the code, but couldn't. Can you tell me where a pool operator can set the timer?

Rucknium[m]: my appologies, as I just mentioned is not pushed. The public version is just fetching every 120s or on height change

A pool op can trigger a new template by sending a signal (SIGUSR1) which can be done on a cron job or whatever.

It's not for optimizing tx fees though as new jobs won't get created unless there's a height change