As an experiment I sent 0.0005 BTC to the address corresponding to the private key in the documentation (L1uyy5qTuGrVXrmrsvHWHgVzW9kKdrp27wBC7Vs6nZDTF2BRUVwy -> 17XBj6iFEsf8kzDMGQk5ghZipxX49VXuaV). Within seconds someone had already transferred it out to 1ENnzep2ivWYqXjAodTueiZscT6kunAyYs.
Wow! Tried it with the other private key[0] and the same thing happened. Upon some searching it looks like the recipient belongs to a Russian named amaclin on the Bitcoin forum[1] who has a script running to empty published private keys as soon as a transaction hits the network.
You can also send coins to any brainwallet (using the simple sha256(sha256(input))) that is under 10 characters or so and see the coins immediately get swept. Someone's obviously monitoring the blockchain for new transactions to known keys for sweeping.
You are correct. Both projects come from Stefan Thomas's original BitcoinJS.
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:
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.
Bitcore and BitcoinJS achieve a lot of the same basic functions like generating addresses (and now multi-signature addresses), building, and signing transctions. You will still need to be able to connect to a Bitcoind peer (via an API or run your own) to promulgate the transaction on the Bitcoin network.
http://cryptocoinjs.com/ is another library that performs some of these functions. Rubyists may be interested in https://github.com/lian/bitcoin-ruby
Lead developer of http://cryptocoinjs.com here. Also maintainer of https://github.com/cryptocoinjs/ecurve (what bitcoinjs-lib) uses for EC operations. I've worked with the lead developers of bitcoinjs-lib on ecurve so I think that I'd be qualified to answer this.
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.
We're game to make any library changes. I did want to say though, that raw performance is not a high priority for BitcoinJS. We're far more interested in good testing and correctness than in performance (though performance certainly is a good thing).
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). :)
Bitpay does like your work. Will you sometimes contribute to one of the existing projects or prefer that they keep integrating your work? The former is sometimes more efficient, possibly more impactful. I don't think it will be great for community if there are too many JS bitcoin libs: 3 might be ok but IMO it's close to a reasonable practical limit.
Why not? 1.0.0 is yet another version number. We have significant API changes since the original 0.1.3 tag. The sooner we get on 1.0.0, the sooner we can move on with proper semver in our lives.
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.
I don't think the maintainers posted this HN post. So this is a premature launch. Given that they have an upcoming release with their transaction builder. I think they would have liked to do a Show HN later
[+] [-] benmanns|11 years ago|reply
[address] https://blockchain.info/address/17XBj6iFEsf8kzDMGQk5ghZipxX4...
[thief?] https://blockchain.info/address/1ENnzep2ivWYqXjAodTueiZscT6k...
[+] [-] benmanns|11 years ago|reply
[0] https://blockchain.info/address/14bZ7YWde4KdRb5YN7GYkToz3EHV...
[1] https://bitcointalk.org/index.php?topic=655092.msg7358079#ms...
[+] [-] httpagent|11 years ago|reply
meta: http://www.reddit.com/r/bestof/comments/296zn4/
original context: http://np.reddit.com/r/Bitcoin/comments/295las/35_of_my_btc_...
[+] [-] sneak|11 years ago|reply
[+] [-] ogig|11 years ago|reply
[+] [-] mifreewil|11 years ago|reply
[+] [-] sida|11 years ago|reply
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.
[+] [-] chicagomint|11 years ago|reply
[+] [-] indutny|11 years ago|reply
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...
[+] [-] jonpaul|11 years ago|reply
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.
[+] [-] kyledrake|11 years ago|reply
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!
[+] [-] jc123|11 years ago|reply
[+] [-] abrkn|11 years ago|reply
[+] [-] loucal|11 years ago|reply
[+] [-] chucknelson|11 years ago|reply
> BitcoinJS 1.0 Released!
...further down the page...
> Documentation: Soon!
[+] [-] weilu|11 years ago|reply
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.
[+] [-] sida|11 years ago|reply
[+] [-] k__|11 years ago|reply