Add CHANGELOG

[dcousens]

We can decide 1 of two things, we can add a CHANGELOG to the repository.
Or we can put it in the changes in the milestone itself?

Thoughts?

[jprichardson]

I've always thought that a repo/project without a CHANGELOG is a repo/project that doesn't want users. Definitely in favor of this. Dropping this here for posterity: http://keepachangelog.com/.

Anyway, let's start with just CHANGELOG.md file at minimum. Thoughts on a cohesive workflow i.e. should the changelog be updated per commit or each release? Thoughts on 2.0 release time frame? This will probably be a bit painful with 2.0.

[weilu]

@dcousens I thought we listed the interface changes in one of the issues. I can't seem to find it. Do you recall?

[dcousens]

I can't seem to find it.

Excellent point. Ha. I managed to find it after a search.
If it was hard for me to find...

Backward incompatible changes:

__removed__
- `bitcoin.crypto.HmacSHA256 ` // use `require('crypto').createHmac` instead
- `bitcoin.crypto.HmacSHA512 ` // use `require('crypto').createHmac` instead
- `bitcoin.base58check` // use `require('bs58check')` instead
- `bitcoin.ecdsa` // use `require('ecurve')` if you know what you're doing
- `bitcoin.Wallet` // build your own
- `bitcoin.HDNode.fromBuffer` // use `bitcoin.HDNode.fromBase58` instead
- `bitcoin.HDNode.fromHex` // use `bitcoin.HDNode.fromBase58` instead
- `bitcoin.HDNode.toBuffer` // use `bitcoin.HDNode.toBase58` instead
- `bitcoin.HDNode.toHex` // use `bitcoin.HDNode.toBase58` instead
- `bitcoin.Transaction.prototype.sign` // use `bitcoin.TransactionBuilder.prototype.sign` instead
- `bitcoin.Transaction.prototype.signInput` // use `bitcoin.TransactionBuilder.prototype.sign` instead
- `bitcoin.Transaction.prototype.validateInput` // use `hashForSignature` and `ECPair.verify`

__updated__
- `bitcoin.Message` -> `bitcoin.message`
- `bitcoin.HDNode.toBase58(isPrivate)` -> `bitcoin.HDNode.prototype.neutered().toBase58()` for exporting a extended public key and `bitcoin.HDNode.prototype.toBase58()` for exporting an extended private key
- `bitcoin.scripts.dataOutput ` -> `bitcoin.scripts.nullDataOutput`
- `Transaction.prototype.hashForSignature(prevOutScript, inIndex, hashType)` -> `Transaction.prototype.hashForSignature(inIndex, prevOutScript, hashType)` 
- `Transaction.prototype.addInput(hash, ...)`: `hash` could be a string, Transaction or Buffer -> `hash` can now **only** be a `Buffer`. 
- `Transaction.prototype.addOutput(scriptPubKey, ...)`: `scriptPubKey ` could be a string, `Address` or `Buffer` -> `scriptPubKey` can now **only** be a `Buffer`. 
- `TransactionBuilder` API unchanged.

Its not complete by any means, I think I'll go through each PR before 2.0.0 and make a cohesive change log, in a PR, so we can all ACK before release.

[dcousens]

• bitcoin.scripts.dataOutput -> bitcoin.scripts.nullDataOutput

I'm not sure this is a rationale change, what was the reasoning for it?

[weilu]

To be consistent I suppose? 62e86e0

[dcousens]

@weilu seems that it was also a synonym adopted by the community.