And right about there/here is where I end up going back to check whether Open Transactions has yet gotten around to fixing its self-admitted problem of not using secure enough crypto/hash.
It looks to me more and more the case that until Open Transactions actually uses the level of crypto it claims to need for real use it would be crazy to attempt to go much farther than games and/or trivial amounts of bitcoin in developing open source financial software intended to handle huge amounts of money. Meanwhile tell the billionaires, millionaires, probably even those throwing around only a few hundred thousand - even in the aggregate, such as a very small numberof customers each throwing around only a few thousands or tens of thousands - to please simply use bitcoin itself, directly, to do their trading person to person, "heck it *is* a person to person currency, y'know".
There (is? was?) a wild west element to the potential for a rags to riches story rich enough to put together enough capitol to simply throw money at the problem(s), and maybe MtGox might even be such a story or close to such a story. Two more recent entries to the niche seem to at least be giving an appearance of being "old money" (maybe even so old that it predates the "early adopter windfall new-rich"? Not sure).
Have we learned enough yet that a project could be started with the goal of making a reference implementation "secure" exchange and/or trading and/or minting and/or banking site?
Maybe if devcoins take off it might become possible to throw money at getting Open Transactions to use the math it apparently believes it should be using, which I keep seeming to end up coming back to as about the only serious way forward that seems to be in reasonably plain sight...
I'm writing from the beautiful desert land of Sedona, AZ, where I'm on vacation for a few days.
I wanted to address this quote. FYI, Open-Transactions currently generates 1024-bit keys by default. Ultimately I would prefer that it uses 4096-bit keys instead of 1024, but that is not a terribly difficult fix to make. As more software is released based on OT, and as entities move closer towards actual production use, the keysize will be increased. (In other words, I wouldn't look at this as a deal-breaker, but rather as one of a long series of security fixes that naturally occur in this sort of project as it nears production.)
Similarly, the (untraceable) digital cash currently uses Lucre, which uses Wagner's algorithm and incorporates the SHA-1 hash. SHA-1 has had weaknesses uncovered over the past few years, though I'm not sure of their implications towards Chaumian blinding. This is fine: the whole idea of OT is similar to PGP: that it's easy to swap in new algorithms as the old ones expire. So on OT, it's not difficult to make new subclasses of OTToken and OTMint that use new algorithms.
(FYI, I have already obtained the source code for 2 new cash algorithms--Chaum and Brands--so these will be available within OT at some point in the future. Again, this is the sort of easy change that will probably happen once OT starts nearing production use.)