Internalize Block Tracking

[wtogami]

Proposed Details

• Add an internal representation of recent blocks to Baron's database. type: block contains at least...
  • blockhash
  • previous blockhash
  • next blockhash
  • array of relevant incoming transactions contained within this block
  • height
• When a block is X confirmations in the past there is no reason to keep it any longer. Allow for a configurable pruning threshold?
• Instead of gettransaction, the # of confirmations can be calculated from latest block height minus the height of the block containing the transaction. The status of previous transactions need not be queried again if their blockhash remains valid (within the best chain).
• If a known block becomes invalid, walk to previous until a valid block is found. Any Baron-relevant transactions within blocks that have become invalid have their status changed as part of a reorg.

[akinsey]

If we delete older blocks we should store the block height within the payment as well. This will allow us to continue to count confirmations after deleting older blocks.

[wtogami]

That's a very good point.

[wtogami]

We still want to do this but perhaps much later.