mirrors/bitcoin-s
1
0
Fork 0
mirror of https://github.com/bitcoin-s/bitcoin-s.git synced 2024-11-19 18:02:54 +01:00
Code Issues Packages Projects Releases Wiki Activity
435aef7b0b
bitcoin-s/node
History
Torkel Rogstad 435aef7b0b Pass bloom filter to SPV node (#514) 
* Add getAddressInfo to Wallet API

* Add Bloom filter and event callbacks to SPV node

* Move wallet test trait to testkit

* Test for connecting SPV node with wallet

* Tune logging in SPV node

* Clean up BloomFilter

* Proper toString in inventory and inventorymessage

* Actually pass in callbacks to SPV node

* Fix rebase screwup and partially respond to code review

* Default to file based databases in tests

This is due to issues with deadlocks with
in-memory based databases. We need DBs
to stay alive between connections, but
not across tests.

In DB intensive chain validation tests we
use in-memory databases instead. This
seems like a reasonable tradeoff between
simplicity and speed.

* Make SpvNodeCallbacks contain sequence of functions within

* Make Bloom filter non-optional in SpvNode
2019-06-17 06:48:26 -05:00
..
src/main/scala/org/bitcoins/node Pass bloom filter to SPV node (#514) 2019-06-17 06:48:26 -05:00
README.md Node (#490) 2019-06-04 09:53:00 -05:00

README.md

State of the world

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 for compatability with other JVM based platforms
  • PeerMessageReceiver - this handles messages we receive on the p2p network. The only messages that are currently handled are VerackMessage and VersionMessage. As this project get's built out this is where we need to add code for calling other subsystems that handle transactions, blocks, peer related information etc. 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 lite 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

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