Thanks, both of you!
Also keep in mind this post of mine from last year:
https://bitcointalk.org/index.php?topic=5200716Your list of unconfirmed transactions is not "the" list of unconfirmed transactions it is "a" list of unconfirmed transactions and can vary between nodes.
Didn't actually pay attention to that myself till I noticed and asked about it.
-Dave
Not sure I understood this properly. Is it safe to say there is some kind of "delay"? Let's say I have two nodes, and I'm getting the mempool txs in both of them, and then I find that
node_A has 50 more transactions than
node_B. Where are these 50 transactions exactly? If I make a second request to get a list of unconfirmed transactions using
node_B, would that allow me to see the missing 50 transactions that node_A have?
Also, if there is that much gap, how come we never encounter errors while checking our transactions in block explorers? I mean, if not all nodes have your transaction, you should at least not be able to find it in a few block explorers right?
This is why occasionally you can't see an unconfirmed TX on some explorers for a bit longer then others.
As far as I can tell it's part propagation, and part validation time. Node "A" sees a tx, while it's thinking about it (milliseconds) it may or may not accept another TX so yeah it can probably accept many per second if it hits at the wrong time it just does not see it.
This is a very very simplified version as it was explained to me. May or may not be 100% accurate.
What was explained to me as accurate is that there are certain non optimal ways that core / reference client do things. But it allows for more stability. i.e. not accepting a transaction is better then stacking them up and building a large backlog of things to process. Because if a block is found it still has to go though the backlog to get all the transactions and then throw out the ones that were in the block since they are now in a block.
-Dave
