BitcoinJS
bitcoinjs.org
bitcoinjs.org
[address] https://blockchain.info/address/17XBj6iFEsf8kzDMGQk5ghZipxX4...
[thief?] https://blockchain.info/address/1ENnzep2ivWYqXjAodTueiZscT6k...
[0] https://blockchain.info/address/14bZ7YWde4KdRb5YN7GYkToz3EHV...
[1] https://bitcointalk.org/index.php?topic=655092.msg7358079#ms...
wtf?
Future experiments best to use testnet
(edit to fix format)
62^10 (case insensitive alphanumeric) * 16 byte hashes = 13.4 exabytes of storage.
This why rainbow tables are pretty much irrelevant these days for anything using password-derived keys.
Your solution to just stores the hashes and uses their position to calculate the key. Saving 10 bytes out of (10byte key+16byte hash.) However, you would then need to check every hash in order which is slow at look up time.
Next thought is sorting the hashes so lookups are fast. Notice that the first byte is repeated frequently so break the list up into 256 lists and you don't need to save the first byte. Continuing this idea you end up a tree data structure: http://en.wikipedia.org/wiki/Radix_tree. Problem is it's still a lot of data.
However, look up is now so fast you don't need to full key any more store say 8 bytes and test the next 2. Wait, do we really need ASCII key values or just a number to reduce the search space 2 bytes cuts things from 1 day to (1/256^2) or ~1second. But wait, we don't need to store the full hash just enough that false positives are low. A 4 byte hash + 3 bytes in a radix tree gives means ~1 in 256^4th hashes match and you spend 1/200th of a second looking at each match, which seems vary reasonable. Unfortunately even at ~1/4 the storage it's still to much space.
Continuing this idea of the trade off between storage and speed, you might end up with a rainbow table. http://en.wikipedia.org/wiki/Rainbow_table
meta: http://www.reddit.com/r/bestof/comments/296zn4/
original context: http://np.reddit.com/r/Bitcoin/comments/295las/35_of_my_btc_...
Both projects (bitcore vs bitcoinjs) are very similar. I would say the main difference you will find is mostly at a DSL level. I find that bitcoinjs has nicer syntax than bitcore.
Bitcore has a fairly loose syntax. And a function can takes many different types of argument. As an example:
https://github.com/bitpay/bitcore/blob/master/lib/Hierarchic...
If you pass no argument, it defaults to a new BIP32 key on mainnet. Or you can pass in a network argument, or you can pass in a string private key.
Bitcoinjs-lib on the other hand, enforces fairly strict typing on functions. Functions often only take one particular type, as an example: https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/h...
This function only takes a string key in base58 format.
In my experience of using both, it is easy to have programmer error in bitcore, because its syntax is so loose. Whereas it is a lot harder to make programmer errors in bitcoinjs-lib. Given that this is financial software, I prefer the bitcoinjs-lib approach.
For example, One problem I encountered with bitcore was I made a mistake in the derivation path of a bip32 key. Instead path of 'M/1/0/1', I mistakenly used 'M/1/0/1/undefined'. Bitcore happily derived a key for me. This is the type of errors you don't tend to get with bitcoinjs.
Still not considering to use https://github.com/indutny/elliptic for your EC operations? It seems like Bitcore has moved to it, and are quite fine with the results: http://blog.bitpay.com/2014/07/22/bitcore-3000-is-three-time...
The main reason was that (1-2 months) ago when we were cleaning up ecurve, we had considered using your elliptic library, but we had problems with such simple operations in bn.js (your big integer library that elliptic depends upon) where arithmetic was incorrect for simple operations like -1 + 2 = -3 (don't quote me on that exact one). So at the time, we felt it wasn't battle tested. But they (we?) have every intention of switching to elliptic in the future.
One thing that I don't understand is why big integer libraries developed exclusively for crypto need negative numbers. The library [2] that I contribute to doesn't need them, and it works just fine. Actually I could argue that having only non-negative numbers make it simpler and faster.
[1] https://github.com/cryptocoinjs/ecdsa/blob/master/lib/ecdsa.... [2] https://code.google.com/p/end-to-end/source/browse/javascrip...
Thanks for pointing this out, thankfully the implementation already failed on a negative s value, but you're correct in that it wasn't definitive.
I also whole-heartedly agree with your comment about the unnecessary inclusion of a bignum that allows for negative values. The lack of typing in this (and other cases) has lead to several problematic scenarios for users to the point we have littered the code with assertions to enforce whatever we can.
Thanks for a definite answer!
Which is not to say that your library is incorrect or has bad testing, just to say that the way to our hearts is to convince us that elliptic is better than what we're using, not that it is faster, which it certainly is (and that's awesome). :)
Pull requests, of course, always welcome!
> BitcoinJS 1.0 Released!
...further down the page...
> Documentation: Soon!
Documentation is still lacking for bitcoinjs-lib. PRs and volunteers welcome =) Meanwhile, developers can reference our tests for examples; and join IRC #bitcoinjs-dev if you have any questions.