Cool project. btcd is going to make projects like this so much easier in the future, I think.
The old school way of doing something like serving notifications over websockets without using a hacky solution like bitcoind's walletnotify to a script, or new, well-engineered solution like btcd, is to create an actual lightweight Bitcoin node in the language of your websocket server. Traditionally, people have used artforz's old Python half-a-node for this purpose[1].
I recently updated this old half-a-node, also using code from jeffgarzik's python-bitcoinlib, to run on Python 3's new asyncio instead of the old asyncore. I have then have it tapping into PyZMQ to scale up and serve websockets on multiple Tornado servers. I've open sourced the asyncio part and may open source the rest soon[2]. In the full project, Tornado provides the main event loop for asyncio, but also smoothly integrates the ZMQ event loop using eventloop.ioloop.
I used this to create a backend for a realtime Bitcoin POS application, but I'm not convinced there's a real market yet for it, so I've not yet moved forward with it. Fun stuff.
I had the luck of working on a Scala-akka project recently, and enjoyed it enough, wouldn't mind playing with it again.
It is odd that something based on the actor model could be so overengineered though. This is in spite of the fact that messages are untyped!
The library did feel very solid though, our project was deployed on a pretty big network and we had no issues on the akka side concerning messaging, and this was with some extremely heavy traffic message-wise.
It seems that typed actor support it somewhat incomplete. Once you wanted to use typed actors with routers and resizing, there was no documentation. There were some mailing lists posts with suggestions that don't work. I don't know if anything changed in the meanwhile, but this blog post suggests that it's still not well-supported:
One thing that I dislike about the Akka implementation of actors is that they can't block, because this would block a thread in the thread pool. Quasar's implementation of actors allow you to block on e.g. I/O, because Quasar can preempt fibers that are parked. This makes Quasar's actor framework much more powerful and more Erlang-like.
I agree on the part that working with Scala and akka is enjoyable! :)
About being over-engineered... well, it is quite extensive for what it does but I'm not sure I agree with it being over-engineered...
I also found that it's a bit difficult to debug, since I often have request-response chains (like: get raw transaction (1) of an incoming transaction, get raw transaction (2) of the input, create a new transaction using the output of (2)...) and one chain of messages gets mixed up with another chain of messages. So it gets somewhat confusing in the logs. But I guess that's a common problem of event-driven programming...
The README for the btcwallet library says that it needs to decrypt the root key every time it needs to derive a new address. With hierarchical deterministic keys, you can derive a public-only key, which lets you derive new public keys without needing to enter the password every time.
This has the benefit of less time for the unencrypted key to be vulnerable in memory and also ease-of-use since it can automatically search the blockchain for keys generated by the user. For application servers this adds a huge layer of security since you can accept money with the private keys fully airgapped.
Where do you see this? In a conformal README or another README for this scala project? Because it is not necessary to derive the root private key to create a new public address. Instead, the next public key can be chained from the previous public key and the chaincode (seed). When pubkeys and addresses are created this way, the private keys are not immediately created, but are recovered the next time the wallet is unlocked. So while this is not an HD wallet (it's essentially the same as Armory's current file format, and there is no hierarchy), it does have some of the same deterministc address chaining properties.
I think I misunderstood your README: "Unencrypted wallets are unsupported and are never written to disk. This design decision has the consequence of generating new wallets on the fly impossible: a frontend is required to provide a wallet encryption passphrase."
this makes some of the things mark mentioned a bit less painful, e.g. marshal/unmarshaling the JSON, error handling, async replies. it is in go, so it might not be immediately useful to scala devs.
Wow, nice to see you commenting here! btcd / btcwallet was an obvious choice since I wanted notification support. It's an impressive piece of work that you've created, and I really like the modular project design. At first I was worried that there was no documentation (yet) for btcwallet but the code is simple enough to understand even though I didn't know Go before.
btcctl is also really helpful. I only found out about it today though. Before that I've used curl and httpie and that was not very convenient.
The old school way of doing something like serving notifications over websockets without using a hacky solution like bitcoind's walletnotify to a script, or new, well-engineered solution like btcd, is to create an actual lightweight Bitcoin node in the language of your websocket server. Traditionally, people have used artforz's old Python half-a-node for this purpose[1].
I recently updated this old half-a-node, also using code from jeffgarzik's python-bitcoinlib, to run on Python 3's new asyncio instead of the old asyncore. I have then have it tapping into PyZMQ to scale up and serve websockets on multiple Tornado servers. I've open sourced the asyncio part and may open source the rest soon[2]. In the full project, Tornado provides the main event loop for asyncio, but also smoothly integrates the ZMQ event loop using eventloop.ioloop.
I used this to create a backend for a realtime Bitcoin POS application, but I'm not convinced there's a real market yet for it, so I've not yet moved forward with it. Fun stuff.
1. https://github.com/jgarzik/pynode/tree/mini-node
2. https://github.com/esbullington/pynode-asyncio