
Haskoin – Haskell implementation of the Bitcoin specifications - jc123
https://github.com/haskoin/haskoin
======
oakwhiz
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.

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

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

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

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

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

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

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

------
espadrine
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?

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

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

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

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

------
Dewie
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. :)

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

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

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

------
smrtinsert
80 columns - I'm surprised to see this honestly.

