bitcoind mempool - surviving a restart?

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Yes that explains the 0-confirm transactions. Thanks.

I guess I need to look through the code a determine what initiates a retransmission of txns
I'd guess maybe a new block missing the txn?

( though, of course, the memory pool is needed for getwork

)

However, I also seem to be missing where the actual transactions in a block come from that are not in the memory pool.
i.e. if bitcoind gets a block that uses transactions that are not in the memory pool the debug.log doesn't report how it gets them (or usually even anything about them at all)
I guess bitcoind must then request the missing txns from other bitcoind's but it doesn't report this in debug.log either
(though I'm also not exactly sure what gets sent out with a found block - certainly it is the full header plus the merkle tree plus the coinbase txn, but I don't know if it includes all the other actual txn details in the same transmission)

Edit: discussing with luke-jr in IRC - it is the block that includes all txn's with it - but just debug.log doesn't report any of those txn details.

Pieter Wuille

legendary

Activity: 1072

Merit: 1181

When a transaction comes in that depends on an unconfirmed transaction (for example one that was recently in the memory pool, but that was cleared due to a restart), it is simply rejected.

This is not a problem. Even if the entire network would regularly wipe their memory pool, the sender & receiver of the transaction will keep rebroadcasting it until it is accepted into a block, including all its unconfirmed dependencies. The fact that a thing like the memory pool even exists is just an optimization in this sense.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

I've been looking through the code recently

The mempool is not in any way recorded (yep it's a memory pool

) so when you stop a bitcoind and restart it, it has nothing in mempool.

When a block comes in with transactions that should have been in the mempool (from before the restart) the debug.log doesn't clearly report how it resolved these missing transactions.
Anyone know exactly where in the code this is resolved?

The relevance is in respect to any transaction system that is looking for transactions.

In the case of normal transactions, (>0 confirm) I take it that code would normally have to backtrack to earlier blocks based on when the system went down and find the payments (but I'm not sure what happens to these missing txn's i.e. where in the debug.log explains it)
I'd guess the transactions simply just sneak into the system (i.e. the debug.log doesn't report them) but I'm not sure.

In the case of 0-confirms I take this to mean it isn't possible to backtrack until they reach 1 confirm.

Any explanations greatly appreciated
(and I'd guess that anyone who has written a BTC transaction system has already come across and dealt with/understands how to deal with these issues)

Topic: bitcoind mempool - surviving a restart? (Read 1393 times)