Merge pull request #576 from eordano/feature/doc3

Some words about encoding

docs/Block.md

@@ -0,0 +1,51 @@
+# Block
+
+A Block instance represents the information on a block in the bitcoin network.
+Note that creating it takes some computing power, as the tree of transactions
+is created or verified.
+
+Given a hexa or base64 string representation of the serialization of a block
+with its transactions, you can instantiate a Block instance. It will calculate
+and check the merkle root hash (if enough data is provided), but transactions
+won't neccesarily be valid spends, and this class won't validate them. A binary
+representation as a `Buffer` instance is also valid input for a Block's
+constructor.
+
+```javascript
+assert(Block.isValidHeader(data);
+assert(Block.isValidBlock(data);
+
+var block = new Block(hexaEncodedBlock);
+assert(block.id && block.hash && block.id === block.hash);
+assert(block.version === Block.CurrentVersion);
+assert(block.prevHash);
+assert(block.timestamp);
+assert(block.nonce);
+assert(block.size);
+assert(block.transactions[0] instanceof Transaction);
+```
+
+## Navigating through transactions
+
+The set of transactions in a block can be explored by iterating on the block's
+`transactions` member.
+
+```javascript
+for (var transaction in block.transactions) {
+  // ...
+}
+```
+
+It is also possible to explore a block's Merkle tree of transaction hashes.
+Head to the [Merkle tree](./DataStructures.html#MerkleTree) documentation for
+more information:
+
+```javascript
+var root = block.tree.root;
+assert(root instanceof bitcore.DataStructures.MerkleTree.Node);
+assert(root.hash === block.id);
+assert(root.isLeaf === false);
+assert(root.left instanceof bitcore.DataStructures.MerkleTree.Node);
+assert(root.right instanceof bitcore.DataStructures.MerkleTree.Node);
+assert(root.left.left.left.left.content === block.transactions[0]);
+```

docs/Crypto.md

@@ -0,0 +1,36 @@
+# Crypto
+
+The cryptographic primitives (ECDSA and HMAC) implementations in this package
+have been audited by:
+
+* The BitPay engineering team
+
+## random
+
+The `bitcore.Crypto.Random` namespace contains a single function, named
+`getRandomBuffer(size)` that returns a `Buffer` instance with random bytes. It
+may not work depending on the engine that bitcore is running on (doesn't work
+with IE versions lesser than 11).
+
+## bn
+
+The `bitcore.Crypto.BN` class contains a wrapper around
+[bn.js](https://github.com/indutny/bn.js), the bignum library used internally
+in bitcore.
+
+## point
+
+The `bitcore.Crypto.Point` class contains a wrapper around the class Point of
+[elliptic.js](https://github.com/indutny/elliptic.js), the elliptic curve
+library used internally in bitcore.
+
+## hash
+
+The `bitcore.Crypto.Hash` namespace contains a set of hashes and utilities.
+These are either the native `crypto` hash functions from `node.js` or their
+respective browser shims as provided by the `browserify` library.
+
+## ecdsa
+
+`bitcore.Crypto.ECDSA` contains a pure javascript implementation of the
+elliptic curve DSA signature scheme. 

docs/Encoding.md

@@ -0,0 +1,20 @@
+# Encoding
+
+The `bitcore.Encoding` namespace contains utilities for encoding information in
+common formats in the bitcoin ecosystem.
+
+## Base58
+
+Two classes are provided: `Base58` and `Base58Check`. The first one merely
+encodes/decodes a set of bytes in base58 format. The second one will also take
+the double `sha256` hash of the information and append the last 4 bytes of the
+hash as a checksum when encoding, and checking this checksum when decoding.
+
+## BufferReader & BufferWriter
+
+These classes are used internally to write information in buffers.
+
+## Varint
+
+The bitcore implementation uses a quite complex way of compressing integers
+representing the size of fields.

docs/Hierarchical.md

@@ -0,0 +1,12 @@
+# Hierarichically Derived Keys
+
+Bitcore provides full support for
+[BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki),
+allowing for many key management schemas that benefit from this property.
+Please be sure to read and understand the basic concepts and the warnings on
+that BIP before using these classes.
+
+## HDPrivateKey
+
+This class initially meant to share the interface of
+[PrivateKey](http://missing-link) but add the ability to derive new keys.

docs/Input.md

@@ -0,0 +1 @@
+# Input

docs/Networks.md

@@ -0,0 +1,23 @@
+# Networks
+
+Bitcore provides support for both the main bitcoin network as well as for
+`testnet3`, the current test blockchain. We encourage the use of
+`Networks.livenet` and `Networks.testnet` as constants. Note that the library
+sometimes may check for equality against this object. Avoid creating a deep
+copy of this object and using that.
+
+## Setting the default network
+
+Most project will only need to work in one of either networks. The value of
+`Networks.defaultNetwork` can be set to `Networks.testnet` if the project will
+needs only to work on testnet (the default is `Networks.livenet`).
+
+## Network constants
+
+The functionality of testnet and livenet is mostly similar (except for some
+relaxed block validation rules on testnet). They differ in the constants being
+used for human representation of base58 encoded strings. These are sometimes
+referred to as "version" constants.
+
+## Source
+TODO: Include source here

docs/Opcode.md

@@ -0,0 +1 @@
+# Opcode

docs/Output.md

@@ -0,0 +1 @@
+# Output

docs/Script.md

@@ -0,0 +1 @@
+# Script

docs/Signature.md

@@ -0,0 +1 @@
+# Signature

docs/Transaction.md

@@ -49,6 +49,7 @@ You can take a look at the javadocs for the [Transaction class here](link
 missing). This document will go over the expected high level use cases.
 
 * from(utxo)
+* fromMultisig(utxo, pubkeys, threshold)
 * change(address)
 * fee(amount)
 * usingStrategy(strategy)