Bitcoin Forum
November 20, 2017, 11:34:20 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: bitcoind mempool - surviving a restart?  (Read 1274 times)
kano
Legendary
*
Offline Offline

Activity: 2268


Linux since 1997 RedHat 4


View Profile
June 11, 2012, 01:01:44 PM
 #1

I've been looking through the code recently Smiley

The mempool is not in any way recorded (yep it's a memory pool Smiley) 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)

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511220860
Hero Member
*
Offline Offline

Posts: 1511220860

View Profile Personal Message (Offline)

Ignore
1511220860
Reply with quote  #2

1511220860
Report to moderator
1511220860
Hero Member
*
Offline Offline

Posts: 1511220860

View Profile Personal Message (Offline)

Ignore
1511220860
Reply with quote  #2

1511220860
Report to moderator
1511220860
Hero Member
*
Offline Offline

Posts: 1511220860

View Profile Personal Message (Offline)

Ignore
1511220860
Reply with quote  #2

1511220860
Report to moderator
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1050


View Profile WWW
June 11, 2012, 01:05:26 PM
 #2

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
kano
Legendary
*
Offline Offline

Activity: 2268


Linux since 1997 RedHat 4


View Profile
June 11, 2012, 02:36:14 PM
 #3

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 Smiley )

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.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!