
BitcoinJS - markmassie
http://bitcoinjs.org/
======
benmanns
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.

[address]
[https://blockchain.info/address/17XBj6iFEsf8kzDMGQk5ghZipxX4...](https://blockchain.info/address/17XBj6iFEsf8kzDMGQk5ghZipxX49VXuaV)

[thief?]
[https://blockchain.info/address/1ENnzep2ivWYqXjAodTueiZscT6k...](https://blockchain.info/address/1ENnzep2ivWYqXjAodTueiZscT6kunAyYs)

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

[0]
[https://blockchain.info/address/14bZ7YWde4KdRb5YN7GYkToz3EHV...](https://blockchain.info/address/14bZ7YWde4KdRb5YN7GYkToz3EHVCvRxkF)

[1]
[https://bitcointalk.org/index.php?topic=655092.msg7358079#ms...](https://bitcointalk.org/index.php?topic=655092.msg7358079#msg7358079)

~~~
amaclin
Help me please to understand the following transactions:
[https://blockchain.info/address/1HcBw7XNKm6NoVJ4s5sSZPL9JGeB...](https://blockchain.info/address/1HcBw7XNKm6NoVJ4s5sSZPL9JGeB8a9STj)
(look from bottom to top) Send 0.0001 to 1HcBw7XNKm6NoVJ4s5sSZPL9JGeB8a9STj ,
then spend change to 1HcBw7XNKm6NoVJ4s5sSZPL9JGeB8a9STj, then spend change to
1HcBw7XNKm6NoVJ4s5sSZPL9JGeB8a9STj... etc 9 times. And the last transaction is
sending 9 utxos to 1Q76cQw9Rmw4TathPdYdR34GXSGKZKnLQy - the address of private
key which was published earlier on page
[https://www.npmjs.org/package/simplebtc](https://www.npmjs.org/package/simplebtc)

wtf?

------
mifreewil
how much overlap is there with BitPay's Bitcore? I do believe both projects
originated from Stefan Thomas' original work on BitcoinJS

~~~
sida
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:

[https://github.com/bitpay/bitcore/blob/master/lib/Hierarchic...](https://github.com/bitpay/bitcore/blob/master/lib/HierarchicalKey.js#L17-L54)

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...](https://github.com/bitcoinjs/bitcoinjs-
lib/blob/master/src/hdnode.js#L73-L75)

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.

------
indutny
Hey guys!

Still not considering to use
[https://github.com/indutny/elliptic](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...](http://blog.bitpay.com/2014/07/22/bitcore-3000-is-three-times-faster-
for-bitcoin-on-the-web.html)

~~~
jonpaul
Lead developer of [http://cryptocoinjs.com](http://cryptocoinjs.com) here.
Also maintainer of
[https://github.com/cryptocoinjs/ecurve](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.

~~~
cryptbe
I took a quick look at your implementation of ECDSA and I think it has a bug
at line 311 [1]. It looks like I could bypass the check if r or s is negative.

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....](https://github.com/cryptocoinjs/ecdsa/blob/master/lib/ecdsa.js#L311)
[2] [https://code.google.com/p/end-to-
end/source/browse/javascrip...](https://code.google.com/p/end-to-
end/source/browse/javascript/crypto/e2e/ecc/)

~~~
dcousens
Its not really a bug, the operations after it would still be valid (it is
almost immediately reduced to the field order), its just that those parameters
would not be akin to the SEC paper specification. I agree that the honus isn't
on the users to check that though, so I'm probably going to make a pull
request to change this.[1]

[1] [https://github.com/bitcoinjs/bitcoinjs-
lib/pull/250](https://github.com/bitcoinjs/bitcoinjs-lib/pull/250)

~~~
cryptbe
What might happen if r = s = -n? I think it's pure luck that this doesn't lead
to a signature forgery.

~~~
dcousens
You're not wrong.

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.

------
abrkn
It's been over a year since the team started with justmoon's bitcoinjs-lib and
I'm very impressed with the result. Good work, kyle, wei, and everyone!

------
loucal
I love the "Who's not?" section under who's using it ... -Your bank :)

------
chucknelson
This does not make sense to me:

> BitcoinJS 1.0 Released!

...further down the page...

> Documentation: Soon!

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

