bitcoin-ruby 0.0.6 → 0.0.7

data/doc/CONFIG.rdoc

@@ -1,66 +0,0 @@
-= Config
-
-All commands accept configuration, either via config file, or at the command line.
-
-== Locations
-
-There are 3 default locations where configfiles are loaded from:
-
-* /etc/bitcoin-ruby.yml
-* ~/.bitcoin-ruby.yml
-* ./bitcoin-ruby.yml
-
-Files are loaded in order (if they exist) and override each others settings.
-
-To specify a different config file use the +--config+ option.
-
-== Files
-
-Inside a config file, you can put options for the different commands, separated
-into categories.
-
- all:
-   network: bitcoin
-   storage: sequel::postgres:/bitcoin
-   command: 127.0.0.1:1234
- blockchain:
-   max:
-     connect: 30
- wallet:
-   keystore: "simple::file=keys.json"
-
-Options in the +all+ category are loaded by every command, and are loaded first
-(so command-specific options will override them).
-
-Other categories are loaded by the corresponding command and may override options
-from the +all+ category (ie. +bitcoin_wallet+ loads +all+ and +wallet+).
-
-== Default Values
-
- all:
-   network: bitcoin                       # network identifier ("bitcoin", "testnet3", "namecoin")
-   command: "127.0.0.1:9999"              # IP:Port to listen for incomming command connections
-   listen: "0.0.0.0:8332"                 # IP:Port to listen for incoming peer connections
-   connect: ""                            # List of IP:Port,IP:Port of nodes to connect to
-   storage: "sequel::sqlite://~/.bitcoin-ruby/<network>/blocks.db" # storage backend to use (see STORAGE)
- node:
-   headers_only: false                    # download/store only block headers (experimental)
-   dns: true                              # query peers from dns server
-   epoll: false
-   epoll_limit: 10000
-   epoll_user: nil
-   log:                                   # log levels (debug, info, warn, error, fatal)
-     network: info
-     storage: info
-   max:
-     connections: 32                      # number of peer connections
-     addr: 1024                           # peer-address store size
-     queue: 500                           # storage-queue size
-     inv: 500                             # inventory-queue size
-   intervals:
-     queue: 5                             # work storage queue
-     inv_queue: 5                         # work inventory queue
-     addrs: 15                            # collect new peer addrs
-     connect: 30                          # connect to new peers
- wallet:
-   keystore: "simple::file=~/.bitcoin-ruby/<network>/keys.json" # keystore to use

data/doc/EXAMPLES.rdoc

@@ -1,13 +0,0 @@
-= Examples
-
-There are a few demo scripts in `examples/` that might give you an idea where to start.
-
-connect.rb::       Connect to a network node and chat a little.
-verify_tx.rb::     Fetch a transaction from local storage and verify signatures.
-bbe_verify_tx.rb:: Fetch transaction from blockexplorer.com and verify signatures.
-balance.rb::       Display balance/transactions for given address.
-relay_tx.rb::      Relay transaction to the network.
-generate_tx.rb::   Create a transaction.
-validate_tx.rb::   Verify transaction signatures.
-simple_network_monitor_and_util:: Connects to the network and lets you monitor and query blocks/txs.
-forwarder.rb::     Waits for tx sent to your address and forwards them to another address.

data/doc/NAMECOIN.rdoc

@@ -1,34 +0,0 @@
-= Namecoin
-
-Namecoin is almost fully supported.
-* connect to the network,
-* store and query the blockchain
-* transact NMC
-* create/handle name_new/first/update transaction types
-
-The AuxPow is parsed from the block header, the only thing missing is actually verifying it.
-
-== Usage
-
-It should suffice to just set the network to :namecoin when running the node/wallet.
-
- bitcoin_node -n namecoin
-
- bitcoin_wallet -n namecoin list
- bitcoin_wallet -n namecoin send address:NCme95FewQEjTeBhBfXTyqjz1GTxw4bo56:1.0 0.1
-
- bitcoin_wallet -n namecoin name_show d/bitcoin
- bitcoin_wallet -n namecoin name_history d/bitcoin
-
- bitcoin_wallet -n namecoin name_new d/bitcoin
- bitcoin_wallet -n namecoin name_firstupdate d/bitcoin abcdef '{"foo": "bar"}'
- bitcoin_wallet -n namecoin name_update d/bitcoin '{"bar": "baz"}'
- bitcoin_wallet -n namecoin name_update d/bitcoin 'transferring...' NCme95FewQEjTeBhBfXTyqjz1GTxw4bo56
-
-== Implementation Details
-
-All the differences from regular bitcoin behaviour should be in separate modules inside
-Bitcoin::Namecoin. (this is still a work in progress)
-
-The AuxPow parsing is implemented in the Bitcoin::Protocol/::Block, because there might
-be other altchains using it one day.

data/doc/NODE.rdoc

@@ -1,225 +0,0 @@
-= NODE
-
-Bitcoin Node. Connects to the network and downloads the blockchain into local storage.
-
-== Usage
-
-To run the node with the default options (download the blockchain into ./bitcoin.db
-using the sequel::sqlite3 STORAGE backend):
-
- bitcoin_node
-
-You can specify options (see +--help+) or pass a config file with +--config+ (see CONFIG).
-
-Some common options you might want to use:
-
-<tt>-n --network</tt> <i><name></i>::
-  Network to use. Usually +bitcoin+. Support for +namecoin+ is also quite good.
-  Use +testnet+ for development.
-
-<tt>-c --config</tt> <i><file></i>::
-  Read options from config file. See also CONFIG.
-
-<tt>--connect</tt> <i><ip:port></i>::
-  List of peers to connect to.
-
-<tt>-s --storage</tt> <i><backend-string></i>::
-  Storage backend to use. See also STORAGE.
-
-<tt>--import</tt> <i><blockchain dir></i>::
-  Import blockchain in bitcoind/qt format from given directory.
-
-<tt>--skip-validation</tt>::
-  Skip validation of received blockchain data. Can be used to speed up import/sync when
-  blockchain data is received from a trusted source.
-
-<tt>--check-blocks <i><count></i></tt>::
-  Check consistency of the +count+ most recent blocks. Pass -1 to check all blocks.
-
-<tt>-v --verbose</tt>::
-  Display debug output.
-
-<tt>-h --help</tt>::
-  Display all available options.
-
-It will take a long time to download/store the entire blockchain at first, so be patient ;)
-
-
-== Command socket
-
-The node opens a separate command socket which you can connect to and query statistics
-or get notified about new blocks/tx, etc. See below for a list of available commands.
-For more details, see Bitcoin::Network::CommandHandler.
-
-=== CLI interface
-
-The `bitcoin_node_cli` command can be used to interface with a running node, send it commands
-and subscribe to notifications about new blocks/txs, etc.
-The easiest way is to just call `bitcoin_node_cli` in the same way you started
-`bitcoin_node`, but with extra command arguments:
-
- bitcoin_node_cli info
- bitcoin_node_cli -c config.yml info
- bitcoin_node_cli monitor "block tx"
-
-
-=== CommandClient
-
-If you are programming in an EventMachine context, you might find the
-Bitcoin::Network::CommandClient convenient.
-
-=== Raw socket
-
-Of course you can also connect to the socket by any other means you like, just
-your commands as valid JSON, like:
-
- {"id": 0, "method": <command>, "params": <params>}
-
-and you'll receive responses in the form:
-
- {"id": <id>, "method": <method>, "result": <result>}
-
-For example:
-
- $ echo -e '{"id": 1, "method": "tslb", "params": {}}\0' | nc 127.0.0.1 9999
- {"id":1,"method":"tslb","result":{"tslb":10}}
-
-
-=== Commands
-
-==== info
-
-Get various statistics.
-
- bitcoin_node_cli info
-
-==== config
-
-Get the currently active configuration.
-
- bitcoin_node_cli config
-
-==== connections
-
-Get currently connected peers.
-
- bitcoin_node_cli connections
-
-==== connect
-
-Connect to given peer(s).
-
- bitcoin_node_cli connect <ip>:<port>[,<ip>:<port>]
-
-==== disconnect
-
-Disconnect given peer(s).
-
- bitcoin_node_cli disconnect <ip>:<port>[,<ip>,<port>]
-
-==== getblocks
-
-Trigger the node to ask its peers for new blocks.
-
- bitcoin_node_cli getblocks
-
-==== getaddr
-
-Trigger the node to ask its for new peer addresses.
-
- bitcoin_node_cli getaddr
-
-==== addrs
-
-Get known peer addresses (used by bin/bitcoin_dns_seed)
-
- bitcoin_node_cli addrs [count]
-
-==== tslb
-
-Get Time Since Last Block.
-
- bitcoin_node_cli tslb
-
-==== create_tx
-
-Create a transaction, collecting outputs from given +keys+, spending to +recipients+
-with an optional +fee+.
-Keys is an array that can contain either privkeys, pubkeys or addresses.
-When a privkey is given, the corresponding inputs are signed. If not, the
-signature_hash is computed and passed along with the response.
-After creating an unsigned transaction, one just needs to sign the sig_hashes
-and send everything to #assemble_tx, to receive the complete transaction that
-can be relayed to the network.
-
- bitcoin_node_cli create_tx 'keys=[<addr|pub|priv>, <...>]' 'recipients=[[<addr>, <amount>], ...]'
-
-==== assemble_tx
-
-Assemble an unsigned transaction from the +tx+ and +sig_pubkeys+ params and return
-a valid transaction that can be relayed to the network.
-The +tx+ is the regular transaction structure, with empty input scripts
-(as returned by #create_tx when called without privkeys).
-+sig_pubkeys+ is an array of [signature, pubkey] pairs used to build the input scripts.
-
- bitcoin_node_cli assemble_tx tx=<hex> 'sig_pubkeys=[[<sig>, <pub>], ...]'
-
-==== relay_tx
-
-Relay given transaction (in hex).
-
- bitcoin_node_cli relay_tx <tx in hex>
-
-==== store_block
-
-Validate and store given block (in hex) as if it was received by a peer.
-
- bitcoin_node_cli store_block <block in hex>
-
-==== store_tx
-
-Store given transaction (in hex) as if it was received by a peer.
-
- bitcoin_node_cli store_tx <tx in hex>
-
-==== stop
-
-Stop the bitcoin node.
-
- bitcoin_node_cli stop
-
-==== help
-
-List all available commands.
-
- bitcoin_node_cli help
-
-
-=== Monitors
-
-==== block
-
-Monitor new blocks that are accepted into the main chain.
-If +last+ parameter is given, it will send all blocks since then.
-
- bitcoin_node_cli monitor channel=block
- bitcoin_node_cli monitor channel=block last=1234
-
-==== tx
-
-Monitor new transactions.
-If +conf+ parameter is given, it will only send txs with at least that many confirmations.
-If +last+ parameter is given, it will send all txs since then.
-
- bitcoin_node_cli monitor channel=tx
- bitcoin_node_cli monitor channel=tx conf=1 last=b187505ce2acbafcb02948657c0cadb855fbcbf0491f12670f9ff8d271de1983
-
-==== output
-
-Monitor transaction outputs.
-If +conf+ parameter is given, it will only send outputs with at least that many confirmations.
-If +last+ parameter is given, it will send all outputs since then.
-If +addresses+ parameter is given, it will only send outputs related to those addresses.
-
- bitcoin_node_cli monitor channel=output
- bitcoin_node_cli monitor channel=output conf=1 last=b187505ce2acbafcb02948657c0cadb855fbcbf0491f12670f9ff8d271de1983:0

data/doc/STORAGE.rdoc

@@ -1,33 +0,0 @@
-= Storage
-
-There is support for different storage backends, currently there are two. Each backend can be used with sqlite, postgres or mysql.
-
-== Backends
-
-=== UTXO
-
-The `utxo` backend stores only the minimum amount of information needed to validate new blocks, namely the `Unspent TX Outputs`. So it can be used to independently validate the whole blockchain as it goes, but it cannot query old data or serve blocks to peers. There is however a way to tell it specific addresses for which it will keep the history (the ones in your wallet).
-
-=== Sequel
-
-The `sequel` backend stores the whole blockchain into a fully normalized SQL DB. It can be used to run arbitrary queries on the blockchain data, but the database gets huge and it takes a very long time to do an initial sync.
-
-It is used to run http://webbtc.com and there are also postgres dumps to get you started faster on http://dumps.webbtc.com.
-
-
-== Config
-
-For examples that require storage backends, you can specify them using
-a string containing the backend name and a configuration string.
-The default backend is +utxo::sqlite:~/.bitcoin-ruby/<network>blocks.db+, which is a sqlite database called +blocks.db+ in a directory named after the network you're using, inside your homedir.
-
- sequel::sqlite:/ # in-memory
- sequel::sqlite://bitcoin.db
- sequel::sqlite:///tmp/bitcoin.db
- sequel::postgres:/bitcoin
- sequel::postgres://<user>:<pass>@<host>:<port>/<database>
-
-== Custom Backends
-
-To implement a custom backend you need to inherit from Bitcoin::Storage::Backends::StoreBase
-and implement the methods defined there. When returning blocks/tx, you should wrap them in Bitcoin::Storage::Models objects. See the `dummy` backend for a simple example.

data/doc/WALLET.rdoc

@@ -1,102 +0,0 @@
-= WALLET
-
-The wallet stores your keys/addresses, knows which transactions belong to them,
-can create transactions, etc.
-
-== Keystores
-
-A keystore is responsible for storing/accessing your keys/addresses.
-
-The +simple+ keystore (Bitcoin::Wallet::SimpleKeyStore) will create one key
-and put it into the given file. You can later ask it to generate more keys
-or add labels to the keys.
-
-The +deterministic+ keystore (Bitcoin::Wallet::KeyGenerator) uses the seed
-(which should be a large, unique, random string!) and generates the given number
-of keys. The nonce is optional, it just speeds up finding the first key.
-Note: Currently this keystore is not usable because it doesn't support labels yet.
-
-
-== Config
-
-To use the wallet you should create a configfile. It's not required but more convenient.
-See CONFIG for details.
-
- wallet:
-   keystore: "simple::file=keys.json"
-   # keystore: "deterministic::seed=foo,nonce=2116,keys=7"
-
-
-== Usage
-
-Then you can list all addresses in the wallet:
-
- bitcoin_wallet list
-
-Display transaction history for a specific address:
-
- bitcoin_wallet list <address>
-
-Create new keys/addresses:
-
- bitcoin_wallet new
-
-Import keys from base58 format:
-
- bitcoin_wallet import <base58>
-
-Export keys to base58 format:
-
- bitcoin_wallet export <address>
-
-== Transactions
-
-Transactions consist of multiple inputs and outputs. Inputs are selected
-automatically, and you can define outputs of different types.
-Each output has a +value+ (specified in base units/"satoshis"), and script represented by
-the script type (see below) and one or more recipients (addresses or public keys).
-
-Outputs can be specified as a combination of type, recipient(s) and value.
-
- bitcoin_wallet send <type>:<recipients>:<value> [<fee>]
-
-This will create and sign a transaction and display it, asking for confirmation.
-If you accept, it will be sent to your node and relayed to the rest of the network.
-
-
-There are different script types:
-
-
-=== Address
-
-Specify address/hash160 of the public key needed to spend the output again.
-This is the most commonly used transaction type at the moment.
-
- bitcoin_wallet send address:1GQkkFvAFW2ts3YLnEvMnu76WyCB6yDb4d:0.1 0.005
-
-
-=== Pubkey
-
-Specify public key needed to spend the output.
-Somewhat deprecated (because of the higher long-term storage requirements compared
-to address-transactions).
-
- bitcoin_wallet send pubkey:<pubkey in hex>:1.0 0.005
-
-
-=== Multisig
-
-Specify multiple addresses needed to spend the output.
-
- bitcoin_wallet send <type>:<m>:<key>:<key>:<amount> [<fee>]
- bitcoin_wallet send multisig:1:1GQkkFvAFW2ts3YLnEvMnu76WyCB6yDb4d:1C5uWeXorS46ZubciCLN4zyR7sAqeNJfLD:1.0 0.005
-
-You can give up to 3 addresses/keys and +m+ specifies how many of them are required to spend
-the output.
-
-Note: Currently you need to have all keys in the same wallet for this to work.
-
-
-=== P2SH
-
-# TODO