bitcoin-s/chain
Chris Stewart b0b1c1cc42 Start the process of refactoring our ChainHandler to be able to avoid… (#655)
* Start the process of refactoring our ChainHandler to be able to avoid database calls on TipValidation

WIP: Begin explicity passing state back and forth in return types of PeerMessageReceiver, P2PClient, , DataMessageHandler. This commit also implements the ability to keep our blockchain completely in memory. Previously when we were updating the tip of the chain, we had to make a database read to figure out what the best tips are. This is suboptimal for performance because a database read needs to be done for every block header we see, now we just keep the chain in memory

Fix bug in DataMessageHandler that pre-emptively sent a getheadersmsg to our peer. Make 'chainApiF' internal to our spvNode (not a parameter). This forces the chainApi to be created from disk everytime a new SpvNode is spun up. This keeps us in sync with the blockchain at disk at the cost of disk access and less modularity of SpvNode

Address torkel code review

Fix rebase issues

Address code review

Address nadav code review

* Rebase onto master, fix api changes
2019-08-06 13:31:54 -05:00
..
src/main/scala/org/bitcoins/chain Start the process of refactoring our ChainHandler to be able to avoid… (#655) 2019-08-06 13:31:54 -05:00
build.sbt Node (#490) 2019-06-04 09:53:00 -05:00
README.md Node (#490) 2019-06-04 09:53:00 -05:00

chain

This is meant to be a stand alone project that process a new block / transaction and stores it. It also provides a interface to query information related to a blockchain.

The design goal with this project is to be agnostic of how the project is receiving the blockchain data, just that it processes and stores it. For instance you could provide the blockchain data via

  • rpc
  • zmq
  • p2p
  • sattelite

This project just stores relevant block and transaction information and allows for it to be queried via a api.