

Show HN: bitcoin-akka – a btcwallet client, written in Scala and built on akka - goldmar
https://github.com/goldmar/bitcoin-akka/

======
eric_bullington
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.

1\. [https://github.com/jgarzik/pynode/tree/mini-
node](https://github.com/jgarzik/pynode/tree/mini-node)

2\. [https://github.com/esbullington/pynode-
asyncio](https://github.com/esbullington/pynode-asyncio)

------
rtpg
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.

~~~
pkuki
In Akka you can use typed actors as well:
[http://doc.akka.io/docs/akka/snapshot/scala/typed-
actors.htm...](http://doc.akka.io/docs/akka/snapshot/scala/typed-actors.html)

~~~
danieldk
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:

[http://blog.codacy.com/2014/01/29/typed-actors-with-
routing/](http://blog.codacy.com/2014/01/29/typed-actors-with-routing/)

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.

------
mappum
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.

~~~
joshrickmar
Primary btcwallet dev here.

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.

The code for performing this pubkey chaining can be found here:
[https://github.com/conformal/btcwallet/blob/8795534408b47685...](https://github.com/conformal/btcwallet/blob/8795534408b47685518ad6fa47265bda2eb1fcfe/wallet/wallet.go#L207-243).

~~~
mappum
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."

------
conformal
nice to see btcd getting more usage, goldmar :)

for the related blog entry with some more details, check out

[http://markgoldenstein.com/building-websocket-client-
btcwall...](http://markgoldenstein.com/building-websocket-client-btcwallet-
using-scala-akka/)

we just recently released a small library that makes using the JSON-RPC much
easier, and it should work with both bitcoind and btcd

[https://github.com/conformal/btcrpcclient](https://github.com/conformal/btcrpcclient)

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.

~~~
goldmar
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.

