Safe Haskell | None |
---|
This package provides all of the basic types used for the Bitcoin networking protocol together with Data.Binary instances for efficiently serializing and de-serializing them. More information on the bitcoin protocol is available here: http://en.bitcoin.it/wiki/Protocol_specification
- data Block = Block {
- blockHeader :: !BlockHeader
- blockCoinbaseTx :: !CoinbaseTx
- blockTxns :: ![Tx]
- type BlockLocator = [BlockHash]
- data GetBlocks = GetBlocks {}
- data BlockHeader = BlockHeader {
- blockVersion :: !Word32
- prevBlock :: !BlockHash
- merkleRoot :: !Word256
- blockTimestamp :: !Word32
- blockBits :: !Word32
- bhNonce :: !Word32
- data GetHeaders = GetHeaders {}
- data Headers = Headers {
- headersList :: ![BlockHeaderCount]
- type BlockHeaderCount = (BlockHeader, VarInt)
- data GetData = GetData {
- getDataList :: ![InvVector]
- data Inv = Inv {}
- data InvVector = InvVector {}
- data InvType
- = InvError
- | InvTx
- | InvBlock
- | InvMerkleBlock
- data NotFound = NotFound {
- notFoundList :: ![InvVector]
- data Tx = Tx {}
- data CoinbaseTx = CoinbaseTx {
- cbVersion :: !Word32
- cbPrevOutput :: !OutPoint
- cbData :: !ByteString
- cbInSequence :: !Word32
- cbOut :: ![TxOut]
- cbLockTime :: !Word32
- data TxIn = TxIn {
- prevOutput :: !OutPoint
- scriptInput :: !ByteString
- txInSequence :: !Word32
- data TxOut = TxOut {
- outValue :: !Word64
- scriptOutput :: !ByteString
- data OutPoint = OutPoint {
- outPointHash :: !TxHash
- outPointIndex :: !Word32
- data MerkleBlock = MerkleBlock {
- merkleHeader :: !BlockHeader
- merkleTotalTxns :: !Word32
- mHashes :: ![Word256]
- mFlags :: ![Bool]
- data BloomFlags
- data BloomFilter = BloomFilter {
- bloomData :: !(Seq Word8)
- bloomHashFuncs :: !Word32
- bloomTweak :: !Word32
- bloomFlags :: !BloomFlags
- newtype FilterLoad = FilterLoad {}
- newtype FilterAdd = FilterAdd {}
- newtype VarInt = VarInt {}
- newtype VarString = VarString {}
- data NetworkAddress = NetworkAddress {}
- data Addr = Addr {
- addrList :: ![NetworkAddressTime]
- type NetworkAddressTime = (Word32, NetworkAddress)
- data Version = Version {}
- newtype Ping = Ping {}
- newtype Pong = Pong {}
- data Alert = Alert {}
- data Reject = Reject {}
- data RejectCode
- reject :: MessageCommand -> RejectCode -> String -> Reject
- data Message
- = MVersion !Version
- | MVerAck
- | MAddr !Addr
- | MInv !Inv
- | MGetData !GetData
- | MNotFound !NotFound
- | MGetBlocks !GetBlocks
- | MGetHeaders !GetHeaders
- | MTx !Tx
- | MBlock !Block
- | MMerkleBlock !MerkleBlock
- | MHeaders !Headers
- | MGetAddr
- | MFilterLoad !FilterLoad
- | MFilterAdd !FilterAdd
- | MFilterClear
- | MPing !Ping
- | MPong !Pong
- | MAlert !Alert
- | MReject Reject
- data MessageHeader = MessageHeader {
- headMagic :: !Word32
- headCmd :: !MessageCommand
- headPayloadSize :: !Word32
- headChecksum :: !CheckSum32
- data MessageCommand
- = MCVersion
- | MCVerAck
- | MCAddr
- | MCInv
- | MCGetData
- | MCNotFound
- | MCGetBlocks
- | MCGetHeaders
- | MCTx
- | MCBlock
- | MCMerkleBlock
- | MCHeaders
- | MCGetAddr
- | MCFilterLoad
- | MCFilterAdd
- | MCFilterClear
- | MCPing
- | MCPong
- | MCAlert
- | MCReject
Blocks
Data type describing a block in the bitcoin protocol. Blocks are sent in
response to GetData
messages that are requesting information from a
block hash.
Block | |
|
type BlockLocator = [BlockHash]Source
Data type representing a GetBlocks message request. It is used in the
bitcoin protocol to retrieve blocks from a peer by providing it a
BlockLocator
object. The BlockLocator
is a sparse list of block hashes
from the caller node with the purpose of informing the receiving node
about the state of the caller's blockchain. The receiver node will detect
a wrong branch in the caller's main chain and send the caller appropriate
Blocks
. The response to a GetBlocks
message is an Inv
message
containing the list of block hashes pertaining to the request.
GetBlocks | |
|
Block Headers
data BlockHeader Source
Data type recording information on a Block
. The hash of a block is
defined as the hash of this data structure. The block mining process
involves finding a partial hash collision by varying the nonce in the
BlockHeader
and/or additional randomness in the CoinbaseTx
of this
Block
. Variations in the CoinbaseTx
will result in different merkle
roots in the BlockHeader
.
BlockHeader | |
|
data GetHeaders Source
Similar to the GetBlocks
message type but for retrieving block headers
only. The response to a GetHeaders
request is a Headers
message
containing a list of block headers pertaining to the request. A maximum of
2000 block headers can be returned. GetHeaders
is used by thin (SPV)
clients to exclude block contents when synchronizing the blockchain.
GetHeaders | |
|
The Headers
type is used to return a list of block headers in
response to a GetHeaders
message.
Headers | |
|
type BlockHeaderCount = (BlockHeader, VarInt)Source
BlockHeader
type with a transaction count as VarInt
Requesting data
The GetData
type is used to retrieve information on a specific object
(Block
or Tx
) identified by the objects hash. The payload of a GetData
request is a list of InvVector
which represent all the hashes for which a
node wants to request information. The response to a GetBlock
message
wille be either a Block
or a Tx
message depending on the type of the
object referenced by the hash. Usually, GetData
messages are sent after a
node receives an Inv
message to obtain information on unknown object
hashes.
GetData | |
|
Invectory vectors represent hashes identifying objects such as a Block
or a Tx
. They are sent inside messages to notify other peers about
new data or data they have requested.
Data type identifying the type of an inventory vector.
InvError | Error. Data containing this type can be ignored. |
InvTx | InvVector hash is related to a transaction |
InvBlock | InvVector hash is related to a block |
InvMerkleBlock | InvVector has is related to a merkle block |
A NotFound
message is returned as a response to a GetData
message
whe one of the requested objects could not be retrieved. This could happen,
for example, if a tranasaction was requested and was not available in the
memory pool of the receiving node.
NotFound | |
|
Transactions
Data type representing a bitcoin transaction
data CoinbaseTx Source
Data type representing the coinbase transaction of a Block
. Coinbase
transactions are special types of transactions which are created by miners
when they find a new block. Coinbase transactions have no inputs. They have
outputs sending the newly generated bitcoins together with all the block's
fees to a bitcoin address (usually the miners address). Data can be embedded
in a Coinbase transaction which can be chosen by the miner of a block. This
data also typically contains some randomness which is used, together with
the nonce, to find a partial hash collision on the block's hash.
CoinbaseTx | |
|
Data type representing a transaction input.
TxIn | |
|
Data type representing a transaction output.
TxOut | |
|
The OutPoint is used inside a transaction input to reference the previous transaction output that it is spending.
OutPoint | |
|
Merkle trees and bloom filters
data MerkleBlock Source
MerkleBlock | |
|
Bloom Filter
data BloomFlags Source
The bloom flags are used to tell the remote peer how to auto-update the provided bloom filter.
BloomUpdateNone | Never update |
BloomUpdateAll | Auto-update on all outputs |
BloomUpdateP2PubKeyOnly | Only auto-update on outputs that are pay-to-pubkey or pay-to-multisig. This is the default setting. |
data BloomFilter Source
A bloom filter is a probabilistic data structure that SPV clients send to other peers to filter the set of transactions received from them. Bloom filters are probabilistic and have a false positive rate. Some transactions that pass the filter may not be relevant to the receiving peer. By controlling the false positive rate, SPV nodes can trade off bandwidth versus privacy.
BloomFilter | |
|
newtype FilterLoad Source
Set a new bloom filter on the peer connection.
Add the given data element to the connections current filter without requiring a completely new one to be set.
Network types
Data type representing a variable length integer. The VarInt
type
usually precedes an array or a string that can vary in length.
Data type for variable length strings. Variable length strings are
serialized as a VarInt
followed by a bytestring.
data NetworkAddress Source
Data type describing a bitcoin network address. Addresses are stored in
IPv6. IPv4 addresses are mapped to IPv6 using IPv4 mapped IPv6 addresses:
http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses. Sometimes,
timestamps are sent together with the NetworkAddress
such as in the Addr
data type.
Provides information on known nodes in the bitcoin network. An Addr
type is sent inside a Message
as a response to a GetAddr
message.
Addr | |
|
type NetworkAddressTime = (Word32, NetworkAddress)Source
Network address with a timestamp
When a bitcoin node creates an outgoing connection to another node,
the first message it will send is a Version
message. The other node
will similarly respond with it's own Version
message.
Version | |
|
A Ping message is sent to bitcoin peers to check if a TCP/IP connection is still valid.
A Pong message is sent as a response to a ping message.
Data type describing signed messages that can be sent between bitcoin nodes to display important notifications to end users about the health of the network.
Alert | |
|
The reject message is sent when messages are rejected by a peer.
Reject | |
|
data RejectCode Source
reject :: MessageCommand -> RejectCode -> String -> RejectSource
Convenience function to build a Reject message
Messages
The Message
type is used to identify all the valid messages that can be
sent between bitcoin peers. Only values of type Message
will be accepted
by other bitcoin peers as bitcoin protocol messages need to be correctly
serialized with message headers. Serializing a Message
value will
include the MessageHeader
with the correct checksum value automatically.
No need to add the MessageHeader
separately.
data MessageHeader Source
Data type representing the header of a Message
. All messages sent between
nodes contain a message header.
MessageHeader | |
|
data MessageCommand Source
A MessageCommand
is included in a MessageHeader
in order to identify
the type of message present in the payload. This allows the message
de-serialization code to know how to decode a particular message payload.
Every valid Message
constructor has a corresponding MessageCommand
constructor.