bitcoin-s/node
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/node Start the process of refactoring our ChainHandler to be able to avoid… (#655) 2019-08-06 13:31:54 -05:00
README.md Service identifier and node cleanup (#522) 2019-06-17 14:27:51 -05:00

Bitcoin-S SPV node

This module is a Bitcoin SPV (simplified payment verification) node that peers with a Bitcoin Core node over the P2P network. It syncs block headers and does as much verification as possible with the data it has available.

The node supports bloom filters, and provides optional callbacks that notify consumers on events such as new blocks, filtered merkle blocks and transactions.

Caveats:

  1. This is a heavy work in progress, and should not be used for anything serious yet
  2. The node can only peer with one node on the P2P network right now, and that node must be passed in on startup. Eventually we want to support peer discovery through DNS seeds, as well as supporting multiple peers at the same time.
  3. The majority of the P2P code was written in late 2017, and as a consequence does not handle some of the newer P2P messages and functionality (including SegWit related messages).

Interesting files

Currently this project is a heavy WIP. The most important files are

  • Client - this handles all of the networking code. Currently this uses Akka but the plan is to move away from Akka in the future and use a networking library with a smaller classpath footprint.
  • PeerMessageReceiver - this handles messages we receive on the P2P network. All messages are algebraic data types, so we can easily pattern match on them and implement features in PeerMessageReceiver.handleControlPayload and PeerMessageReceiver.handleDataPayload
  • PeerMessageReceiverState - the states that our peer message receiver can be in. It transitions through these states during the connect/disconnect process with our peer.
  • PeerMessageSender - this handles sending messages to our peer on the P2P network. Since we are a light client, we probably won't be sending a lot of messages to peers so this isn't that interesting.
  • PeerHandler - this combines a PeerMessageReceiver and a PeerMessageSender into a pair.
  • Peer - The low level socket details need to connect to a peer

Interesting tests

There is still a lot of code commented out on the project, but the tests should pass for the ones that are not. Interesting tests are

Main method

There's a main method available in SpvNodeMain.scala. Currently (June 17th, 2019) the node peers with a locally running bitcoind. It does not do much interesting beyond that, although you can make it more interesting if you modify the logging levels (look in common-logback.xml) and pass in some callbacks to the node on startup.