package p2p
- Alphabetic
- Public
- Protected
Type Members
- trait AddrMessage extends GossipAddrMessage
The addr (IP address) message relays connection information for peers on the network.
The addr (IP address) message relays connection information for peers on the network. Each peer which wants to accept incoming connections creates an addr message providing its connection information and then sends that message to its peers unsolicited. Some of its peers send that information to their peers (also unsolicited), some of which further distribute it, allowing decentralized peer discovery for any program already on the network.
- sealed trait AddrV2Message extends GossipAddrMessage
addrV2 relays information about a peer.
addrV2 relays information about a peer. It supports many different address types and networks.
- See also
https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
- case class BlockMessage(block: Block) extends DataPayload with Product with Serializable
The block message transmits a single serialized block
The block message transmits a single serialized block
- block
The block being transmitted inside of this message
- case class CJDNSAddrV2Message(time: UInt32, services: CompactSizeUInt, addrBytes: ByteVector, port: UInt16) extends AddrV2Message with Product with Serializable
addrv2 message that contains an CJDNS address
- case class CompactFilterCheckPointMessage(filterType: FilterType, stopHash: DoubleSha256Digest, filterHeaders: Vector[DoubleSha256Digest]) extends DataPayload with Product with Serializable
- See also
- case class CompactFilterHeadersMessage(filterType: FilterType, stopHash: DoubleSha256Digest, previousFilterHeader: DoubleSha256Digest, filterHashes: Vector[DoubleSha256Digest]) extends DataPayload with Product with Serializable
cfheadersis sent in response togetcfheaders.cfheadersis sent in response togetcfheaders. Instead of including the filter headers themselves, the response includes one filter header and a sequence of filter hashes, from which the headers can be derived. This has the benefit that the client can verify the binding links between the headers.TODO: doc on params
- See also
- case class CompactFilterMessage(filterType: FilterType, blockHash: DoubleSha256Digest, filterBytes: ByteVector) extends DataPayload with Product with Serializable
- See also
- sealed trait ControlPayload extends NetworkPayload
Represents a control message on this network https://bitcoin.org/en/developer-reference#control-messages
- sealed trait DataPayload extends NetworkPayload
Represents a data message inside of bitcoin core
Represents a data message inside of bitcoin core
- sealed trait ExpectsResponse extends AnyRef
- trait FeeFilterMessage extends ControlPayload
The feefilter message is a request to the receiving peer to not relay any transaction inv messages to the sending peer where the fee rate for the transaction is below the fee rate specified in the feefilter message.
The feefilter message is a request to the receiving peer to not relay any transaction inv messages to the sending peer where the fee rate for the transaction is below the fee rate specified in the feefilter message.
feefilter was introduced in Bitcoin Core 0.13.0 following the introduction of mempool limiting in Bitcoin Core 0.12.0. Mempool limiting provides protection against attacks and spam transactions that have low fee rates and are unlikely to be included in mined blocks. The feefilter messages allows a node to inform its peers that it will not accept transactions below a specified fee rate into its mempool, and therefore that the peers can skip relaying inv messages for transactions below that fee rate to that node.
- trait FilterAddMessage extends ControlPayload
The filteradd message tells the receiving peer to add a single element to a previously-set bloom filter, such as a new public key.
The filteradd message tells the receiving peer to add a single element to a previously-set bloom filter, such as a new public key. The element is sent directly to the receiving peer; the peer then uses the parameters set in the filterload message to add the element to the bloom filter.
- trait FilterLoadMessage extends ControlPayload
The filterload message tells the receiving peer to filter all relayed transactions and requested merkle blocks through the provided filter.
The filterload message tells the receiving peer to filter all relayed transactions and requested merkle blocks through the provided filter. This allows clients to receive transactions relevant to their wallet plus a configurable rate of false positive transactions which can provide plausible-deniability privacy.
- trait GetBlocksMessage extends DataPayload with ExpectsResponse
The
getblocksmessage requests an inv message that provides block header hashes starting from a particular point in the block chain.The
getblocksmessage requests an inv message that provides block header hashes starting from a particular point in the block chain. It allows a peer which has been disconnected or started for the first time to get the data it needs to request the blocks it hasn’t seen.- See also
[https://bitcoin.org/en/developer-reference#getblocks]]
- case class GetCompactFilterCheckPointMessage(filterType: FilterType, stopHash: DoubleSha256Digest) extends DataPayload with Product with Serializable
- See also
- case class GetCompactFilterHeadersMessage(filterType: FilterType, startHeight: UInt32, stopHash: DoubleSha256Digest) extends DataPayload with ExpectsResponse with Product with Serializable
getcfheadersis used to request verifiable filter headers for a range of blocksgetcfheadersis used to request verifiable filter headers for a range of blocks- See also
- case class GetCompactFiltersMessage(filterType: FilterType, startHeight: UInt32, stopHash: DoubleSha256Digest) extends DataPayload with ExpectsResponse with Product with Serializable
- See also
- case class GetDataMessage(inventoryCount: CompactSizeUInt, inventories: Seq[Inventory]) extends DataPayload with Product with Serializable
The getdata message requests one or more data objects from another node.
The getdata message requests one or more data objects from another node. The objects are requested by an inventory, which the requesting node typically previously received by way of an inv message.
- inventoryCount
The number of inventory enteries
- inventories
One or more inventory entries up to a maximum of 50,000 entries.
- trait GetHeadersMessage extends DataPayload with ExpectsResponse
The getheaders message requests a headers message that provides block headers starting from a particular point in the block chain.
The getheaders message requests a headers message that provides block headers starting from a particular point in the block chain. It allows a peer which has been disconnected or started for the first time to get the headers it hasn’t seen yet.
- sealed trait GossipAddrMessage extends ControlPayload
- case class HeadersMessage(count: CompactSizeUInt, headers: Vector[BlockHeader]) extends DataPayload with Product with Serializable
The headers message sends one or more block headers to a node which previously requested certain headers with a getheaders message.
The headers message sends one or more block headers to a node which previously requested certain headers with a getheaders message.
- count
Number of block headers up to a maximum of 2,000. Note: headers-first sync assumes the sending node will send the maximum number of headers whenever possible.
- headers
Block headers: each 80-byte block header is in the format described in the block headers section with an additional 0x00 suffixed. This 0x00 is called the transaction count, but because the headers message doesn’t include any transactions, the transaction count is always zero.
- case class I2PAddrV2Message(time: UInt32, services: CompactSizeUInt, addrBytes: ByteVector, port: UInt16) extends AddrV2Message with Product with Serializable
addrv2 message that contains an I2P address
- case class IPv4AddrV2Message(time: UInt32, services: CompactSizeUInt, addr: InetAddress, port: UInt16) extends AddrV2Message with Product with Serializable
addrv2 message that contains an IPv4 address
- case class IPv6AddrV2Message(time: UInt32, services: CompactSizeUInt, addr: InetAddress, port: UInt16) extends AddrV2Message with Product with Serializable
addrv2 message that contains an IPv6 address
- trait InetAddress extends AnyRef
- case class Inventory(typeIdentifier: TypeIdentifier, hash: DoubleSha256Digest) extends NetworkElement with Product with Serializable
These are used as unique identifiers inside the peer-to-peer network
These are used as unique identifiers inside the peer-to-peer network
- typeIdentifier
The type of object which was hashed
- hash
SHA256(SHA256()) hash of the object in internal byte order.
- trait InventoryMessage extends DataPayload
The inv message (inventory message) transmits one or more inventories of objects known to the transmitting peer.
The inv message (inventory message) transmits one or more inventories of objects known to the transmitting peer. It can be sent unsolicited to announce new transactions or blocks, or it can be sent in reply to a getblocks message or mempool message.
- case class MerkleBlockMessage(merkleBlock: MerkleBlock) extends DataPayload with Product with Serializable
The merkleblock message is a reply to a getdata message which requested a block using the inventory type MSG_MERKLEBLOCK.
The merkleblock message is a reply to a getdata message which requested a block using the inventory type MSG_MERKLEBLOCK. It is only part of the reply: if any matching transactions are found, they will be sent separately as tx messages.
- merkleBlock
The actual MerkleBlock that this message represents
- sealed trait MsgUnassigned extends TypeIdentifier
- case class NetworkHeader(network: NetworkParameters, commandName: String, payloadSize: UInt32, checksum: ByteVector) extends NetworkElement with Product with Serializable
Represents a message header on the peer-to-peer network
Represents a message header on the peer-to-peer network
- network
Each network has magic bytes indicating the originating network; used to seek to next message when stream state is unknown.
- commandName
ASCII string which identifies what message type is contained in the payload. Followed by nulls (0x00) to pad out byte count; for example: version\0\0\0\0\0.
- payloadSize
Number of bytes in payload. The current maximum number of bytes (MAX_SIZE) allowed in the payload by Bitcoin Core is 32 MiB—messages with a payload size larger than this will be dropped or rejected.
- checksum
Added in protocol version 209. First 4 bytes of SHA256(SHA256(payload)) in internal byte order. If payload is empty, as in verack and getaddr messages, the checksum is always 0x5df6e0e2 (SHA256(SHA256(""))).
- See also
https://bitcoin.org/en/developer-reference#message-headers
- sealed abstract class NetworkIpAddress extends NetworkElement
Encapsulated network IP address currently uses the following structure
Encapsulated network IP address currently uses the following structure
- See also
https://bitcoin.org/en/developer-reference#addr
- sealed abstract class NetworkMessage extends NetworkElement
Represents a P2P network message
- sealed trait NetworkPayload extends NetworkElement
Trait that represents a payload for a message on the Bitcoin p2p network
Trait that represents a payload for a message on the Bitcoin p2p network
- trait NotFoundMessage extends DataPayload with InventoryMessage
The notfound message is a reply to a getdata message which requested an object the receiving node does not have available for relay.
The notfound message is a reply to a getdata message which requested an object the receiving node does not have available for relay. (Nodes are not expected to relay historic transactions which are no longer in the memory pool or relay set. Nodes may also have pruned spent transactions from older blocks, making them unable to send those blocks.)
- trait PingMessage extends ControlPayload
The ping message helps confirm that the receiving peer is still connected.
The ping message helps confirm that the receiving peer is still connected. If a TCP/IP error is encountered when sending the ping message (such as a connection timeout), the transmitting node can assume that the receiving node is disconnected. The response to a ping message is the pong message.
- trait PongMessage extends ControlPayload
The pong message replies to a ping message, proving to the pinging node that the ponging node is still alive.
The pong message replies to a ping message, proving to the pinging node that the ponging node is still alive. Bitcoin Core will, by default, disconnect from any clients which have not responded to a ping message within 20 minutes.
- sealed trait ProtocolVersion extends NetworkElement
The peer to peer network has versions to allow for new operations Here are the currently protocol versions in the network
The peer to peer network has versions to allow for new operations Here are the currently protocol versions in the network
- trait RejectMessage extends ControlPayload
The reject message informs the receiving node that one of its previous messages has been rejected.
The reject message informs the receiving node that one of its previous messages has been rejected.
- sealed abstract class ServiceIdentifier extends NetworkElement
Indicates the services that are provided by a node on the P2P network
Indicates the services that are provided by a node on the P2P network
- See also
protocol.h in Bitcoin Core
- trait Tor2Address extends TorAddress
- trait Tor3Address extends TorAddress
- trait TorAddress extends InetAddress
- case class TorV2AddrV2Message(time: UInt32, services: CompactSizeUInt, addrBytes: ByteVector, port: UInt16) extends AddrV2Message with Product with Serializable
addrv2 message that contains a TorV2 address
- case class TorV3AddrV2Message(time: UInt32, services: CompactSizeUInt, addrBytes: ByteVector, port: UInt16) extends AddrV2Message with Product with Serializable
addrv2 message that contains a TorV3 address
- case class TransactionMessage(transaction: Transaction) extends DataPayload with Product with Serializable
The tx message transmits a single transaction in the raw transaction format.
The tx message transmits a single transaction in the raw transaction format. It can be sent in a variety of situations;
- transaction
The transaction being sent over the wire
- sealed trait TypeIdentifier extends NetworkElement
This indicates the type of the object that has been hashed for an inventory
This indicates the type of the object that has been hashed for an inventory
- See also
https://bitcoin.org/en/developer-reference#data-messages
- case class UnknownNetworkAddrV2Message(time: UInt32, services: CompactSizeUInt, networkId: Byte, addrBytes: ByteVector, port: UInt16) extends AddrV2Message with Product with Serializable
addrv2 message that contains an address from a network we do not understand
- sealed trait UnknownService extends ServiceIdentifier
Designated type for any service that does not have value of 0 or 1
- trait VersionMessage extends ControlPayload
The version message provides information about the transmitting node to the receiving node at the beginning of a connection.
The version message provides information about the transmitting node to the receiving node at the beginning of a connection. Until both peers have exchanged version messages, no other messages will be accepted. If a version message is accepted, the receiving node should send a verack message—but no node should send a verack message before initializing its half of the connection by first sending a version message. https://bitcoin.org/en/developer-reference#version
Value Members
- object AddrMessage extends Factory[AddrMessage]
The companion object for an AddrMessage
The companion object for an AddrMessage
- See also
https://bitcoin.org/en/developer-reference#addr
- object AddrV2Message extends Factory[AddrV2Message]
The companion object for an AddrV2Message
The companion object for an AddrV2Message
- See also
https://developer.bitcoin.org/reference/p2p_networking.html#addrv2
https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
- object BlockMessage extends Factory[BlockMessage] with Serializable
- object CompactFilterCheckPointMessage extends Factory[CompactFilterCheckPointMessage] with Serializable
- object CompactFilterHeadersMessage extends Factory[CompactFilterHeadersMessage] with Serializable
- object CompactFilterMessage extends Factory[CompactFilterMessage] with Serializable
- object FeeFilterMessage extends Factory[FeeFilterMessage]
- object FilterAddMessage extends Factory[FilterAddMessage]
- case object FilterClearMessage extends ControlPayload with Product with Serializable
The filterclear message tells the receiving peer to remove a previously-set bloom filter.
The filterclear message tells the receiving peer to remove a previously-set bloom filter. This also undoes the effect of setting the relay field in the version message to 0, allowing unfiltered access to inv messages announcing new transactions.
- object FilterLoadMessage extends Factory[FilterLoadMessage]
- case object GetAddrMessage extends ControlPayload with Product with Serializable
The getaddr message requests an addr message from the receiving node, preferably one with lots of IP addresses of other receiving nodes.
The getaddr message requests an addr message from the receiving node, preferably one with lots of IP addresses of other receiving nodes. The transmitting node can use those IP addresses to quickly update its database of available nodes rather than waiting for unsolicited addr messages to arrive over time.
- object GetBlocksMessage extends Factory[GetBlocksMessage]
This is the companion object for the GetBlocks network message on the p2p network
This is the companion object for the GetBlocks network message on the p2p network
- See also
https://bitcoin.org/en/developer-reference#getblocks
- object GetCompactFilterCheckPointMessage extends Factory[GetCompactFilterCheckPointMessage] with Serializable
- object GetCompactFilterHeadersMessage extends Factory[GetCompactFilterHeadersMessage] with Serializable
- object GetCompactFiltersMessage extends Factory[GetCompactFiltersMessage] with Serializable
- object GetDataMessage extends Factory[GetDataMessage] with Serializable
- object GetHeadersMessage extends Factory[GetHeadersMessage]
- object HeadersMessage extends Factory[HeadersMessage] with Serializable
- object InetAddress
- object Inventory extends Factory[Inventory] with Serializable
- object InventoryMessage extends Factory[InventoryMessage]
Creates an scala object that represents the inventory type on the p2p network
Creates an scala object that represents the inventory type on the p2p network
- See also
https://bitcoin.org/en/developer-reference#inv
- case object MemPoolMessage extends DataPayload with Product with Serializable
The mempool message requests the TXIDs of transactions that the receiving node has verified as valid but which have not yet appeared in a block.
The mempool message requests the TXIDs of transactions that the receiving node has verified as valid but which have not yet appeared in a block. That is, transactions which are in the receiving node’s memory pool. The response to the mempool message is one or more inv messages containing the TXIDs in the usual inventory format.
- object MerkleBlockMessage extends Factory[MerkleBlockMessage] with Serializable
- See also
https://bitcoin.org/en/developer-reference#merkleblock
- object NetworkHeader extends Factory[NetworkHeader] with Serializable
- object NetworkIpAddress extends Factory[NetworkIpAddress]
- object NetworkMessage extends Factory[NetworkMessage]
- object NetworkPayload
- object NotFoundMessage extends Factory[NotFoundMessage]
The companion object factory used to create NotFoundMessages on the p2p network
The companion object factory used to create NotFoundMessages on the p2p network
- See also
https://bitcoin.org/en/developer-reference#notfound
- object PingMessage extends Factory[PingMessage]
- object PongMessage extends Factory[PongMessage]
- object ProtocolVersion extends Factory[ProtocolVersion]
- case object ProtocolVersion106 extends ProtocolVersion with Product with Serializable
Added receive IP address fields to version message.
Added receive IP address fields to version message. Bitcoin Core 0.1.6 (Oct 2009)
- case object ProtocolVersion209 extends ProtocolVersion with Product with Serializable
Added checksum field to message headers.
Added checksum field to message headers. Bitcoin Core 0.2.9 (May 2010)
- case object ProtocolVersion311 extends ProtocolVersion with Product with Serializable
Added alert message Bitcion Core 0.3.11 (Aug 2010)
- case object ProtocolVersion31402 extends ProtocolVersion with Product with Serializable
Added time field to addr message.
Added time field to addr message. Bitcoin Core 0.3.15 (Oct 2010)
- case object ProtocolVersion31800 extends ProtocolVersion with Product with Serializable
Added getheaders message and headers message.
Added getheaders message and headers message. Bitcoin Core 0.3.18 (Dec 2010)
- case object ProtocolVersion60000 extends ProtocolVersion with Product with Serializable
BIP14: Separated protocol version from Bitcoin Core version Bitcoin Core 0.6.0 (Mar 2012)
- case object ProtocolVersion60001 extends ProtocolVersion with Product with Serializable
BIP31: Added nonce field to ping message, Added pong message Bitcoin Core 0.6.1 (May 2012)
- case object ProtocolVersion60002 extends ProtocolVersion with Product with Serializable
BIP35: Added mempool message.
BIP35: Added mempool message. • Extended getdata message to allow download of memory pool transactions Bitcoin Core 0.7.0 (Sep 2012)
- case object ProtocolVersion70001 extends ProtocolVersion with Product with Serializable
Added notfound message.
Added notfound message. BIP37: • Added filterload message. • Added filteradd message. • Added filterclear message. • Added merkleblock message. • Added relay field to version message • Added MSG_FILTERED_BLOCK inventory type to getdata message. Bitcoin Core 0.8.0 (Feb 2013)
- case object ProtocolVersion70002 extends ProtocolVersion with Product with Serializable
Send multiple inv messages in response to a mempool message if necessary BIP61: Add reject message Bitcoin Core 0.9.0 (Mar 2014)
- case object ProtocolVersion70012 extends ProtocolVersion with Product with Serializable
BIP130: Add sendheaders message Bitcoin Core 0.12.0
- case object ProtocolVersion70013 extends ProtocolVersion with Product with Serializable
Added feefilter message.
Added feefilter message. Removed alert message system. See Alert System Retirement Bitcoin Core 0.13.0 (August 2016)
- case object ProtocolVersion70014 extends ProtocolVersion with Product with Serializable
BIP152 Added sendcmpct, cmpctblock, getblocktxn, blocktxn messages Added MSG_CMPCT_BLOCK inventory type to getdata message.
BIP152 Added sendcmpct, cmpctblock, getblocktxn, blocktxn messages Added MSG_CMPCT_BLOCK inventory type to getdata message. Bitcoin Core 0.13.0 (August 2016)
- case object ProtocolVersion70015 extends ProtocolVersion with Product with Serializable
New banning behavior for invalid compact blocks #9026 in v0.14.0, Backported to v0.13.2 in #9048.
New banning behavior for invalid compact blocks #9026 in v0.14.0, Backported to v0.13.2 in #9048. Bitcoin Core 0.13.2 (January 2017)
- case object ProtocolVersion70016 extends ProtocolVersion with Product with Serializable
Indicates that a node prefers to relay transactions via wtxid, rather than txid.
Indicates that a node prefers to relay transactions via wtxid, rather than txid. Protocol version 70016 as described by BIP 339. Bitcoin Core 0.21.0 (December 2020)
- object RejectMessage extends Factory[RejectMessage]
- case object SendAddrV2Message extends ControlPayload with Product with Serializable
Sending such a message indicates that a node can understand and prefers to receive addrv2 messages instead of addr messages.
Sending such a message indicates that a node can understand and prefers to receive addrv2 messages instead of addr messages. I.e. "Send me addrv2".sendaddrv2 SHOULD be sent after receiving the verack message from the peer. For older peers, that did not emit sendaddrv2, keep sending the legacy addr message, ignoring addresses with the newly introduced address types.
- case object SendHeadersMessage extends ControlPayload with Product with Serializable
The sendheaders message tells the receiving peer to send new block announcements using a headers message rather than an inv message.
The sendheaders message tells the receiving peer to send new block announcements using a headers message rather than an inv message. There is no payload in a sendheaders message. See the message header section for an example of a message without a payload.
- object ServiceIdentifier extends Factory[ServiceIdentifier] with StringFactory[ServiceIdentifier]
- object Tor2Address
- object Tor3Address
- object TorAddress
- object TransactionMessage extends Factory[TransactionMessage] with Serializable
Companion factory object for the TransactionMessage on the p2p network
Companion factory object for the TransactionMessage on the p2p network
- See also
https://bitcoin.org/en/developer-reference#tx
- object TypeIdentifier extends Factory[TypeIdentifier]
- case object VerAckMessage extends ControlPayload with Product with Serializable
The verack message acknowledges a previously-received version message, informing the connecting node that it can begin to send other messages.
The verack message acknowledges a previously-received version message, informing the connecting node that it can begin to send other messages. The verack message has no payload; for an example of a message with no payload, see the message headers section.
- object VersionMessage extends Factory[VersionMessage]
- See also
https://bitcoin.org/en/developer-reference#version