Pages:
Author

Topic: Bitcoin Mempool Mismatch Between Nodes - page 3. (Read 628 times)

member
Activity: 104
Merit: 120
October 03, 2023, 12:17:37 PM
#7
Thanks for all the replies everyone.  


@n0nce ,

IMO opinion the mempool difference in size isn't due to the two different nodes getting the transactions at slightly different times as they have been having a very similar discrepancy for the last several months and their sizes have been quite different for most (if not all) of that timeframe.  That in contrast to the few years I've been running them this way beforehand with no notable discrepancy in size other than the last two months and I don't recall changing any settings in either.



@o_e_l_e_o ,

Please note that my I did just upgrade y v 20.0 to 20.2 (the one behind the VPN) two days ago yet I'm still seeing the same discrepancy after over 48 hours of running them. Presently the 20.2 node running behind the VPN not accepting inbound connections has the following getmempoolinfo output:


{
  "loaded": true,
  "size": 5649,
  "bytes": 19164914,
  "usage": 95340400,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00001000,
  "minrelaytxfee": 0.00001000
}

Vs. my 20.1 which is accepting inbounds:


{
  "loaded": true,
  "size": 13601,
  "bytes": 21971612,
  "usage": 107492160,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00001000,
  "minrelaytxfee": 0.00001000
}


@DaveF ,

Technically they are both on the same LAN but one is behind a VPN connection not accepting inbound connections (the recently updated v20.2) and the other is open with inbound connections.

All,

I'm starting to wonder if perhaps this may be related to the transactions in the mempool being increased to higher than my nodes default 300 MB size and somehow my nodes picked different transactions to store locally when the levels dropped below that level however wouldn't of imagined this is possible as shouldn't they be prioritizing them the same way?  Either way from what I gather the mempool is below 300 MB now and the deltas between the two nodes continue to persist which would seem to invalidate my theory.

Also while I certainly appreciate all of the suggestions to try and correct the issue, the real reason for me bringing up this matter isn't to get my two nodes synched up so that they have the same mempool but to rather it's to understand why there is a discrepancy in the first place as this may somehow be some kind of attack that we aren't aware of presently that needs to be looked at (call me paranoid but we are competing with the most powerful and best funded organizations in the history of the planet, right?).  

Thanks all.
legendary
Activity: 3458
Merit: 6231
Crypto Swap Exchange
October 02, 2023, 07:48:02 AM
#6
Are both these nodes on the same private internal network?
If so can you do an addnode command between the 2 of them?

They should at that point talk to each other and although the mempool will never be the same everything else being equal they really should be a lot closer.

-Dave
legendary
Activity: 2268
Merit: 18509
October 02, 2023, 07:39:28 AM
#5
This could be more related to your devices rather than the mempools themselves.

Use getmempoolinfo on your two nodes and compare the outputs. "Size" is the number of transactions in your mempool, and "bytes" is the raw size of these transactions. I would expect these numbers to be fairly similar if your nodes are both running with similar mempool settings and similar uptimes.

"Usage" on the other hand, which is the 158 MB and 195 MB you are referring to, is the amount of RAM those unconfirmed transactions are using after they have been deserialized. This is also what the default 300 MB limit refers to, and not to the raw size of the transactions. The deserialized RAM usage will vary due to a number of factors external to the size of the mempool, such as the version of Core, the hardware of the system, the OS, and so on.
hero member
Activity: 882
Merit: 5818
not your keys, not your coins!
October 02, 2023, 06:29:14 AM
#4
Either way I'm stumped here and hope there's nothing more sinister going on here. Thank you for the reply and hopefully others can chime in on this subject as well as it would be great to understand what's currently going on here. 
Your 2 nodes might just have very different sets of peers and thus get certain transactions earlier or later.
You could try logging the mempool size over the course of a few days and see if one is consistently smaller than the other or just at a certain point in time.

Another thing to try would be manually making the 2 machines peers, so they should exchange information between each other fairly frequently.

https://bitcoincore.org/en/doc/25.0.0/rpc/network/addnode/
member
Activity: 104
Merit: 120
September 29, 2023, 03:56:30 PM
#3
Thanks @Findingnemo,

I just checked the config file on both nodes and oddly enough the only option that might be related was the dbcache value which was set to 10000 for the one with less transactions in it's mempool vs 5000 for the one with more.  Other than that there didn't appear to be any values in there that should affect the amount of memory for the mempool and I don't' even know if dbcache is even a value that does as it seems the one with the larger amount has less transactions that the other. I did however also note that the one with more transactions (v 20.0) was started ~ 5 hours earlier 11 days ago but I wouldn't imagine that would be an issue this much time into the future as I've never noticed it before the ordinals / incriptions spam and I've run nodes for years.


Either way I'm stumped here and hope there's nothing more sinister going on here. Thank you for the reply and hopefully others can chime in on this subject as well as it would be great to understand what's currently going on here. 
hero member
Activity: 2310
Merit: 757
Bitcoin = Financial freedom
September 29, 2023, 03:31:54 PM
#2
I don't know the exact reason for this but it may be due to the difference in the configuration setting, so check if there is any difference in mempool related setting using bitcoin.conf.

That however was never an issue before the last several months. Perhaps it has something to do with the ordinals spamming?
Possibly yes, because Stale blocks formed in the main chain but don't belong to the chain now so one of your nodes picked up the spam blocks and the other didn't pick those broadcasted from peers so the difference in numbers maybe the reason as well.

Still, let the experts of technical knowledge to find the actual reason.

Meanwhile, you can check this out that explains about stale blocks
Quote
The difference in size is due to the number of stale blocks that your node stores. Stale blocks are blocks that once formed the part of the main chain but is not belong to the main chain now.

For example, if say two blocks are mined at height 102 at the same time. When the miner relays the block through the gossip network, the network that is closer to miner 1 will receive its block (102a) first as compared to block mined by miner 2 (102b). Bitcoin core adds the first received valid block to the tip of the chain. The blocks received at the same height after that are not deleted but kept in the database just in case a reorganization happens. So, if the next block 103 is mined on top of block 102b then the node that received 102a first will reorganize its chain to one that contains 102b as shown below.

101 -->102a
    \
     \    
       102b --> 103 -->104

Bitcoin Core does not delete any valid block that it receives from its peers. It is stored in your database forever in the file blocks/blk****.dat (which is also same for blocks in the main chain). However, the software does not relay stale blocks. In order to receive stale blocks, you need to be online at the time when your peer broadcasted a block to you from different chain view. Peers will only broadcast those blocks that they view form the current active chain from their perspective. So you will only have the stale blocks that you received when you were online. This also mean you will need to be connected to peers that view one the tip of the chain that is different from other peers. Due to this variability, many nodes will have different view of the sizes of the Bitcoin blockchain
member
Activity: 104
Merit: 120
September 29, 2023, 02:59:20 PM
#1
I've noticed over the last few weeks that there's been a fairly notable discrepancy between my two nodes that are both running on windows with respect to the size of the mempool. Presently I'm running a version 20 and a 20.1 and note that there is about 195 MB of memory usage for the mempool on the older version versus 158 MB on the newer version. That really seemed odd to me considering that they both booted up on the same date (11 days ago). I've also noticed how fairly frequently the men pool has been exceeding 300 MB which is the default amount of memory that the nodes keep unconfirmed transactions in. Has anybody else out there noticed this discrepancy? Better yet, does anybody out there have an idea about why this might be happening or how?

I should probably add that version 20.1 is not operating behind a VPN and is allowing for inbound connections versus the one running version 20 that is behind a VPN and unable to receive inbound connection. That however was never an issue before the last several months. Perhaps it has something to do with the ordinals spamming?

Thanks in advance for any feedback.
Pages:
Jump to: