Bitcoin Forum
December 09, 2016, 01:58:23 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: bitcoind mempool - surviving a restart?  (Read 1133 times)
kano
Legendary
*
Offline Offline

Activity: 1932


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 BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
1481291903
Hero Member
*
Offline Offline

Posts: 1481291903

View Profile Personal Message (Offline)

Ignore
1481291903
Reply with quote  #2

1481291903
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481291903
Hero Member
*
Offline Offline

Posts: 1481291903

View Profile Personal Message (Offline)

Ignore
1481291903
Reply with quote  #2

1481291903
Report to moderator
1481291903
Hero Member
*
Offline Offline

Posts: 1481291903

View Profile Personal Message (Offline)

Ignore
1481291903
Reply with quote  #2

1481291903
Report to moderator
1481291903
Hero Member
*
Offline Offline

Posts: 1481291903

View Profile Personal Message (Offline)

Ignore
1481291903
Reply with quote  #2

1481291903
Report to moderator
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


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: 1932


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 BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
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!