Merge pull request #576 from eordano/feature/doc3
Some words about encoding
This commit is contained in:
commit
3f594d28f9
|
@ -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]);
|
||||||
|
```
|
|
@ -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.
|
|
@ -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.
|
|
@ -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.
|
|
@ -0,0 +1 @@
|
||||||
|
# Input
|
|
@ -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
|
|
@ -0,0 +1 @@
|
||||||
|
# Opcode
|
|
@ -0,0 +1 @@
|
||||||
|
# Output
|
|
@ -0,0 +1 @@
|
||||||
|
# Script
|
|
@ -0,0 +1 @@
|
||||||
|
# Signature
|
|
@ -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.
|
missing). This document will go over the expected high level use cases.
|
||||||
|
|
||||||
* from(utxo)
|
* from(utxo)
|
||||||
|
* fromMultisig(utxo, pubkeys, threshold)
|
||||||
* change(address)
|
* change(address)
|
||||||
* fee(amount)
|
* fee(amount)
|
||||||
* usingStrategy(strategy)
|
* usingStrategy(strategy)
|
||||||
|
|
Loading…
Reference in New Issue