Has your mempool sorting also been slow recently?

[piotr_n]

Is it just a problem with my implementation, or is there some sort of attack going on, exploiting the Child-Pays-For-Parent sorting algorithm?

The sorting (of the existing mempool) takes far too long.

[1715270093]

1715270093

[1715270093]

1715270093

[1715270093]

1715270093

[1715270093]

1715270093

[DaveF]

I have not noticed a change on any of the nodes I pay attention to.
There are a few low power ones I run that are RPi based that I play with but do not really do much with that might be having an issue.

I just checked one of the RPi now when I saw this post but the mempool had just cleared so nothing to report.
If i have time during the day I'll remote home and see if anything is up.

-Dave

[piotr_n]

I'm not sure if the sorting function is actually used if you're not mining on the node.

Eventually, it can be called when you exceed the mempool size limit, but that would not be a case recently.

[piotr_n]

What I found so far.

I cant really find the relevant code in the current bitcoin core sources, but the code I am using myself was once based on what core was doing (at least that was the idea).

So the first stage of sorting is finding the packages.
A package is a child tx with all its (unconfirmed) parent txs.

What I am seeing now is mempool of 5851 transactions.
This comes down to 4142 packages...
But inside these 4142 packages there is a total of 5773388 parent txs.

I'd say that it is quite a lot and it takes my PC over one second to build the package list.
Either my function to look for the packages has suddenly turned out to be screwed up, or the recent content of the mempool has been deliberately engineered to cause such a behavior.
If it is the second, then bitcoin core (at least the mining nodes) might be suffering from it as well.

Someone please look into this.

[DaveF]

You might be better off posting this as an issue to github. For things like this you will probably get a bit more support.
With that being said, I am spinning up the VM that I have a pool on with a node, will let you know if I see anything when it finishes syncing. It's been off for a few weeks.

-Dave

[ABCbits]

I'm not sure if it help, but my node's RAM, CPU and HDD I/O usage remains low on default configuration. I don't experience lag when i open multiple application at same time.

[DaveF]

So booted and synced my "lottery pool" yesterday and had a miner pointing at it all night till just now.
I am looking at all the utilization monitoring I saw no unusual spikes and no unusual activity.

I also have a mempool.space explorer sitting on the same VM as the pool & node and it was performing fine also.
 
So for this limited test it *seems* to point to something on your end OR something I am just not seeing here.

-Dave

[achow101]

Nope. getblocktemplate seems to be pretty fast. Dunno how long it used to take, but it's not currently a noticeable time to execute.

Code:

> time src/bitcoin-cli getblocktemplate '{"rules":["segwit"]}' > /dev/null

________________________________________________________
Executed in   39.05 millis    fish           external 
   usr time    7.65 millis  272.00 micros    7.38 millis 
   sys time    0.02 millis   24.00 micros    0.00 millis 

[piotr_n]

Thanks. Must be something i screwed up with porting the code.

Perhaps you could help ma to figure it out.

At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:

Code:

UpdatePackagesForAdded(inBlock, mapModifiedTx);

It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.

[aliashraf]

Thanks. Must be something i screwed up with porting the code.

Perhaps you could help ma to figure it out.

At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:

Code:

UpdatePackagesForAdded(inBlock, mapModifiedTx);

It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.

Please check you are porting the optimized version of both addPackageTxs and UpdatePackagesForAdded as it has been proposed and merged after pull request #9959

[achow101]

Thanks. Must be something i screwed up with porting the code.

Perhaps you could help ma to figure it out.

At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:

Code:

UpdatePackagesForAdded(inBlock, mapModifiedTx);

It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.

It's built by AddPackageTxs which calls AddToBlock repeatedly. It's used if AddPackageTxs is called multiple times.

[piotr_n]

OK, thank you everybody.

I fixed it - my bad