The part about this that interests me the most is that it makes the Bitcoin protocol more understandable. The code is very readable and it contains a lot of comments.

It's funny, strong type systems are really about explicit documentation. I'm sure the comments are good but translating a spec into Haskell types is a form of strong and explicit documentation that is also functional.

Awesome library, but I'm a bit worried that they chose to implement their own crypto(mostly ECDSA), instead of using an existing implementation known to be correct.

I am one of the authors of Haskoin. We have had internal discussions on this topic. It was agreed that we wanted to minimize dependencies to code written in another programming language, which was the reason we did not choose one of the existing C++ crypto libraries, such as OpenSSL. My colleague Philippe, who wrote the crypto code, deemed the existing Haskell crypto libraries unsuitable. Hence we rolled our own ECDSA.

It's not really a problem, as long as you've got extensive test cases (perhaps with millions of randomly generated samples) to show that the implementation always has the exact same results as OpenSSL's.

Or even better, since ECDSA is used in bitcoin-qt, just show that the full bitcoin implementation has the same results as bitcoin-qt, with millions of samples.

I don't see any of that in your package though.

The correctness of the implementation is not worrying me at this point. ECDSA is not too complex to implement. We have QuickCheck tests, and many others that make us confident that the code works well, or at least that it does what it intends.

I'm more worried about more sophisticated attacks, like timing attacks, for example. But I don't see how that can be used to attack this particular application.

In my opinion, timing attacks are a major issue with cryptographic schemes written in Haskell. Perhaps there is some way to leverage the type system to create provably constant run times for particular chunks of code. I'm not sure how far this idea could be extended - perhaps it could even be implemented as a GHC extension, so that regions of compiled code contain cache timing attack mitigation.

Essentially, the problem here is that any decision based on secret information must act exactly the same regardless of the result, e.g. a secure string comparison should examine the entire string before concluding that the strings are different. Additionally, any decision based on another decision involving secret information must also follow the same rule - secret information contaminates regular information. So perhaps the solution is to give secret information its own type, incompatible with regular information, unless explicitly interacted with using a special interface.

This in an isightful comment. Lazy evaluation combined with the level of abstraction in Haskell could make this micromanagement somewhat hard to implement. It is in our roadmap to revisit the cryptography implementation.

Be careful when running the code in a way that can lead to an attacker finding a way to use a timing attack. Anywhere where signatures are done automatically could lead to potential problems. This is also true for Electrum, that implements its own crypto too, and browser-based clients.

I wish there was a comparison in the performance benchmark. What was its purpose if we cannot compare it to the mainstream Bitcoin software's performance?

Why would performance be a concern for a bitcoin API? I think this projects main goal is tot provide an easily auditable typesafe implementation.

looks nice. I wonder when we will be able to see a real type safe BTC exchange

How long did this take to write? How large is your team?

We've been working on haskoin for about one year now. At the start we were two, and now we are three.

I guess the name is understandable since it is an implementation of a protocol in Haskell. But I wonder if the day Haskell becomes a mainstream language is the day when few of the apps and such built with Haskell aren't play on words or references to Haskell terminology. :)

Most JavaScript libraries end with .js: Angular.js, Ember.js, Backbone.js, Knockout.js... And yes, JavaScript is a mainstream language (in the browser, at least).

A lot of Python libraries contain "Py", are named after snakes, or are references to Monty Python, and that's certainly a mainstream language.

It's certainly not weird for libraries to be references to the language or culture of the language itself. Not to mention that the name can refer to relevant technical details that are related to the language - for example, if a parser library uses applicative parsers, maybe the name of the library has some reference to applicative in the title.

I was referring to using this kind of terminology in more user-facing applications - for example xmonad (I don't know what monads have to do with tiling window managers. Maybe it has something to do with how the configuration library of xmonad is structured).

Admittedly, maybe Haskoin was a bad example in this regard.

At least xmonad starts with an "x". Alternatives like "ratpoison", "enlightenment", "metacity" or "sawfish" have names which are arguably even less meaningful to end users.

In my view there's really no tension between naming things after implementation details and giving them abstract unrelated names -- all that really matters in the long term is that a name is memorable, and memorable names can and do come from either approach.