mirror of
https://github.com/bitcoin/bitcoin.git
synced 2025-01-10 11:57:28 -03:00
Merge bitcoin/bitcoin#23471: doc: Improve ZMQ documentation
9544ab60ce
doc: Improve ZMQ documentation (node01) Pull request description: This PR intends to clarify: . when ZMQ notifications occur . the message structure of each topic Closes https://github.com/bitcoin/bitcoin/issues/23452#issue-1046579585 ACKs for top commit: theStack: ACK9544ab60ce
Tree-SHA512: 3b1314ad5eb8c359ffabd91ce9b47cf6cf8efa69be083a3bb5d865833ac67d7a88a8e012c4a4f59f2cd2a0e7f491e828897e85e9d01bae72ee83c4a6ad459f6e
This commit is contained in:
commit
6c04b505b4
1 changed files with 23 additions and 4 deletions
27
doc/zmq.md
27
doc/zmq.md
|
@ -91,9 +91,11 @@ For instance:
|
|||
Each PUB notification has a topic and body, where the header
|
||||
corresponds to the notification type. For instance, for the
|
||||
notification `-zmqpubhashtx` the topic is `hashtx` (no null
|
||||
terminator) and the body is the transaction hash (32
|
||||
bytes) for all but `sequence` topic. For `sequence`, the body
|
||||
is structured as the following based on the type of message:
|
||||
terminator). These options can also be provided in bitcoin.conf.
|
||||
|
||||
The topics are:
|
||||
|
||||
`sequence`: the body is structured as the following based on the type of message:
|
||||
|
||||
<32-byte hash>C : Blockhash connected
|
||||
<32-byte hash>D : Blockhash disconnected
|
||||
|
@ -102,7 +104,24 @@ is structured as the following based on the type of message:
|
|||
|
||||
Where the 8-byte uints correspond to the mempool sequence number.
|
||||
|
||||
These options can also be provided in bitcoin.conf.
|
||||
`rawtx`: Notifies about all transactions, both when they are added to mempool or when a new block arrives. This means a transaction could be published multiple times. First, when it enters the mempool and then again in each block that includes it. The messages are ZMQ multipart messages with three parts. The first part is the topic (`rawtx`), the second part is the serialized transaction, and the last part is a sequence number (representing the message count to detect lost messages).
|
||||
|
||||
| rawtx | <serialized transaction> | <uint32 sequence number in Little Endian>
|
||||
|
||||
`hashtx`: Notifies about all transactions, both when they are added to mempool or when a new block arrives. This means a transaction could be published multiple times. First, when it enters the mempool and then again in each block that includes it. The messages are ZMQ multipart messages with three parts. The first part is the topic (`hashtx`), the second part is the 32-byte transaction hash, and the last part is a sequence number (representing the message count to detect lost messages).
|
||||
|
||||
| hashtx | <32-byte transaction hash in Little Endian> | <uint32 sequence number in Little Endian>
|
||||
|
||||
|
||||
`rawblock`: Notifies when the chain tip is updated. Messages are ZMQ multipart messages with three parts. The first part is the topic (`rawblock`), the second part is the serialized block, and the last part is a sequence number (representing the message count to detect lost messages).
|
||||
|
||||
| rawblock | <serialized block> | <uint32 sequence number in Little Endian>
|
||||
|
||||
`hashblock`: Notifies when the chain tip is updated. Messages are ZMQ multipart messages with three parts. The first part is the topic (`hashblock`), the second part is the 32-byte block hash, and the last part is a sequence number (representing the message count to detect lost messages).
|
||||
|
||||
| hashblock | <32-byte block hash in Little Endian> | <uint32 sequence number in Little Endian>
|
||||
|
||||
**_NOTE:_** Note that the 32-byte hashes are in Little Endian and not in the Big Endian format that the RPC interface and block explorers use to display transaction and block hashes.
|
||||
|
||||
ZeroMQ endpoint specifiers for TCP (and others) are documented in the
|
||||
[ZeroMQ API](http://api.zeromq.org/4-0:_start).
|
||||
|
|
Loading…
Reference in a new issue