/block/hash for already present blocks is not working

Disable the recursion and select the best peer with the major last_seen

Offer the blockchain parsing/serializing code in an external library useful for other projects.

The "actual" blockchain state include also:

- A. blocks in the main branch: the transactions in these blocks are considered at least tentatively confirmed

- B. blocks on side branches off the main branch: these blocks have at least tentatively lost the race to be in the main branch

- C. orphan blocks: these are blocks which don't link into the main branch, normally because of a missing predecessor or nth-level predecessor



We need to save them, they are used for fork-detection and data verification. A better abstraction for the storage code could help storing A/B blocks, while we can prune orphan blocks.



https://en.bitcoin.it/wiki/Protocol_rules#Blocks

The shutdown procedure should avoid data corruption; we need to handle the exit signal and execute this procedure:

• Empty the blockchain queue
• Finish the current step of the blockchain loop
• Close the database
• Disconnect all peers

The opam version is outdated, modify travis-sh to pin dev version.

The addresses are always converted with mainnet prefixes; we first need to fix this: dakk/bitcoinml#13

Then, in storage, we need to pass the correct address prefix

Add some command line arguments:

• chain = "BTC | XTN"
• version
• help

Serialize and parsing should never fail; If fail even for one Tx in a block, there is a problem. A block / tx parsing could fail only for new block, new tx

• Create an empty test suite
• Chain fork situation handling

Unit tests

• Branch parsing / serialization

Ideas

• Check for bitcoin-core test suite

This is necessary for:

• Height of a block hash
• Confirmations of transaction

Blocked by dakk/bitcoinml#9

Disable peer message by default

Don't parse the full block when received, parse it only if the the header is valid and only when the node need this data

Implement pruning by:

• specifying a prune interval in blocks (IE 4096)
• saving the pruning window in the chainstate
• removing blocks outside the pruning window

With:

• balance
• sent
• received

If last n received headers messages are empty, assume that the node is in sync

Maybe a blacklist problem, or unhandled messages; in particular we need to reply to getheaders and getdata messages, mainly sent on connection startup.

We should use bc functions instead (or move api to blockchain)

#We need to integrate these validity tests for blocks, headers and txs:
https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages
https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages

• Header validation
• Header validation - prev block
• Header validation - nbits pow
• Header validation - nbits and diff
• Header validation - median timestamp
• Header validation - future timestamp
• Header validation - checkpoints
• Block validation
• Block validation - Header validation (optional)
• Block validation - Txs > 0 validation
• Block validation - Coinbase validation
• Block validation - Merkle root
• Tx validation
• Loggable assert function (atm if the verification fail, it didn't display any hint about the problem)

• Base structure
• Insert new tx
• Remove tx
• Push tx api
• Tx broadcast to all
• Api for mempool stats
• Handle gettx message

Related to #33 , letchain needs a better storage abstraction to handle main branch and other branchs. A git-like model could be a good idea, but still using leveldb as data backend.
The snapshot feature of leveldb could help storing and handling different branches.

• Network info
• Tx push
• Raw tx api
• Block info
• Header info
• Last blocks summary
• Mempool status on chainstate call

Network is just a data provider; we can abstract from this by providing other data sources, like bindings to another node softwares. Data sources should implement a threading instance which reads and write in the request / response queues.
Another useful datasource could be a torrent backup of first years of chain

The IO is always at 99% when receiving blocks; try to reduce the amount of r/w by using caching and batch operations

The last part of the fork detector, is the branch handler; at every step of the blockchain thread:

• Check if a branch is too old (to many blocks behind), then delete it
• Check if a branch need updates (some blocks behind) (HBLOCKS)
• Check if a branch is longer than the best chain
• Revert block from the last to the fork block
• Move old main and put them in a branch
• Push branch headers to the main branch
• Delete the old branch

The number of requested blocks should be dynamic and should depend on the speed of block processing

The crash occurs with a 100% cpu usage (maybe from the network thread).

It could be a problem with the find_peer during a WAITPING operation; a possible fix could be to check the available peer number before trying the find_peer.

Crash occurs only on certain PING