I cannot vouch for the quality of this model, but I remembered I had bookmarked this tweet, having wondered the same:

https://twitter.com/anderssandberg/status/145528744318439424...

Exposing the LAN address is less of a concern than exposing the real IP address of people using a VPN or proxy for anonymity.

I assume 12000 iterations by the looks of that $ delimited string, I assume they're storing the parameters as,

hash_func$iterations$salt$derived_key

I like the sound of most of that, especially the two-factor authentication on all accounts. One thing wasn't clear to me,

"Wallets (and private keys) are stored using AES-256 encryption."

Are individual users wallets stored with a key derived from the users password? Or, rather, could you act, under coercion say, to transfer my funds without my password? (i.e. in a "bank robbery" situation)

Oh and we just added a link to an email signup in the text:

https://docs.google.com/spreadsheet/viewform?formkey=dDdGcHE...

There is some pretty cool stuff in there for a point release. It's cool that monad comprehensions are back in, but I'm most excited about Safe Haskell, which should enable enable some new types of application (safely running untrusted code).

As I keep telling people, 'Safe Haskell' is not as generally useful as they think it is. Mueval (http://hackage.haskell.org/package/mueval) has to do a lot more than just be careful with its imports before it can safely run arbitrary untrusted code.

An amusing analogy, sure, but I can't help be reminded of this xkcd http://xkcd.com/568/ - "you'll never find a programing language that frees you from the burden of clarifying your ideas". Haskell just makes that trade-off more 'up front'. Obviously it's not the right tool for every job mind, of course sometimes quick and dirty scripts win.

Well, sure, but frequently I don't want to clarify all my ideas up front. I want to dip my toe in and see if my ideas have any legs at all. (Wow, tortured metaphor.)

I actually like Haskell. But I do think it's the wrong tool for a lot of the work that people here on HN tend to do.

Yes, the argument presented for point one is pretty weak, but I do agree with it. Having the lazy I/O, and especially lazy bytestring option is great IMO. Although Oleg style left-fold enumerators as used by warp are superior in many respects, typically as a user you don't need to interact at that level; iirc you don't in Yesod, which is built on warp. As an example of approachability LBS approach, checkout this two line "wc -l" implementation, which beats "wc -l" by 64x, apples and pears no doubt, but shows fast enough,(from http://www.mail-archive.com/haskell@haskell.org/msg18878.htm...):

> import qualified Data.ByteString.Lazy.Char8 as L

> main = L.getContents >>= print . L.count '\n'

edit: actually it beats "wc", and is roughly same speed as "wc -l".

That's really cool, and is the kind of good benchmark I was referring to. I'm curious to see how it compares to an iteratee approach. I suspect in this case that there wouldn't be much of a difference, because iteratees are suited especially well for handling multiple concurrent streams, and this deals with only one.

That's right, but your co-founder(s) can sponsor you, and indeed you them. Provided that you could in theory be fired (a three person board for example) then you can be classed as an employee for the purposes of the H1-B.

I don't really see why you'd need that. In those sorts of circumstances I'd either add the new version of the function with a new name, or rename the function and add an oldFunc = undefined line to keep the type checker happy.