bitcoin-elixir v0.0.1 API Reference

Modules

256-bit target threshold in the block header is encoded in a 32-bit space (compact bits a.k.a nBits). This module provides functions to encode and decode compact bits

List of constants associated with the Bitcoin mainnet

List of constants associated with the Bitcoin testnet (v3)

GenServer representing a single running Bitcoin node

Inventory module is responsible for fetching missing data from peers, and broadcasting it forward after validation. Fetched data should be added to storage / mempool

Keeps database of known network nodes

Connection handler. Manages peer state, sends mesasges, responds to pings etc

In memory storage to use for tests and playing with in dev env

https://en.bitcoin.it/wiki/Protocol_documentation#Message_structure

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

An alert message. https://en.bitcoin.it/wiki/Protocol_documentation#alert

The block message is sent in response to a getdata message which requests transaction information from a block hash

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours

Return an inv packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an inv packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not)

Return a headers packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The getheaders command is used by thin clients to quickly download the block chain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients may provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch

The headers packet returns block headers in response to a getheaders packet

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to getblocks

The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node’s mempool.mempool

notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set

The ping message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer

The pong message is sent in response to a ping message. In modern protocol versions, a pong response is generated using a nonce included in the ping

The reject message is sent when messages are rejected

tx describes a bitcoin transaction, in reply to getdata

The verack message is sent in reply to version. This message consists of only a message header with the command string “verack”

When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version

Network address type from the Bitconi protocol ( https://en.bitcoin.it/wiki/Protocol_documentation#Network_address )

var_int type from the Bitcoin protocol ( https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer )

Bitcoin Script interpreter

Handler for Pay to Script Hash scripts

Functions associated with a Bitcoin transaction