This PR intends to clarify:
. when ZMQ notifications occur . the message structure of each topic
Closes #23452#issue-1046579585
111+
112+ hashtx <32-byte transaction hash>
113+
114+`rawblock`: notifies when a the block tip is updated. The body of the message is the raw block in hexadecimal format.
115+
116+`hashblock`: notifies when a the block tip is updated. The body of the message is structured in the following way:
nit:
0`rawblock`: notifies when the block tip is updated. The body of the message is the raw block in hexadecimal format.
1
2`hashblock`: notifies when the block tip is updated. The body of the message is structured in the following way:
Concept ACK
The description looks good and helps the reader understand the topics in better detail. I agree with these changes. However, there is a minor nit that needs to be addressed.
103@@ -102,7 +104,17 @@ is structured as the following based on the type of message:
104
105 Where the 8-byte uints correspond to the mempool sequence number.
106
107-These options can also be provided in bitcoin.conf.
108+`rawtx`: notifies when a transaction is added to mempool. The body of the message is the raw transaction in hexadecimal format.
0`rawtx`: notifies when a transaction is added to mempool. The body of the message is the serialized transaction.
103@@ -102,7 +104,17 @@ is structured as the following based on the type of message:
104
105 Where the 8-byte uints correspond to the mempool sequence number.
106
107-These options can also be provided in bitcoin.conf.
108+`rawtx`: notifies when a transaction is added to mempool. The body of the message is the raw transaction in hexadecimal format.
109+
110+`hashtx`: notifies when a transaction is added to mempool. The body of the message is structured in the following way:
111+
112+ hashtx <32-byte transaction hash>
hashtx
is not contained in the payload. The messages are ZMQ multipart messages with three parts. The first part is the topic (here hashtx
), the second part is the 32-byte transaction hash, and the last part is a sequence number (to detect lost messages; this is already documented).
I’d personally prefer a documentation similar to the following:
0| hashtx | <32-byte transaction hash in Little Endian> | <uint32 sequence number in Little Endian>
108+`rawtx`: notifies when a transaction is added to mempool. The body of the message is the raw transaction in hexadecimal format.
109+
110+`hashtx`: notifies when a transaction is added to mempool. The body of the message is structured in the following way:
111+
112+ hashtx <32-byte transaction hash>
113+
rawtx
and hashtx
notify about all transactions. Mempool and transactions in blocks. This means it could happen that a transaction is published multiple times. First when it enters the mempool and then again in each block that includes it. This should be documented.
109+
110+`hashtx`: notifies when a transaction is added to mempool. The body of the message is structured in the following way:
111+
112+ hashtx <32-byte transaction hash>
113+
114+`rawblock`: notifies when a the block tip is updated. The body of the message is the raw block in hexadecimal format.
0`rawblock`: notifies when a the chain tip is updated. The body of the message is the serialized block.
113+
114+`rawblock`: notifies when a the block tip is updated. The body of the message is the raw block in hexadecimal format.
115+
116+`hashblock`: notifies when a the block tip is updated. The body of the message is structured in the following way:
117+
118+ hashblock <32-byte block hash>
see comments for hashtx
above (remove hashblock and mention Little Endianess)
Concept ACK on improving the documentation. Thanks for picking this up!
I left a few comments below that I think should be addressed.
103@@ -102,7 +104,20 @@ is structured as the following based on the type of message:
104
105 Where the 8-byte uints correspond to the mempool sequence number.
106
107-These options can also be provided in bitcoin.conf.
108+`rawtx`: notifies about all transactions, whether when they are added to mempool or when a new block arrives. This means it could happen that a transaction is published multiple times. First when it enters the mempool and then again in each block that includes it. The body of the message is the serialized transaction.
-zmqpubrawtx
instead of rawtx
? (same thing below)
I am not sure. I think that rawtx
is the ZMQ topic that the subscriber receives notification about and -zmqpubrawtx
is the argument used to set the network address of this topic in node daemon (bitcoind
).
If that is not the case, I can change them to -zmq*
.
rawtx
(the topic). This sections starts in line 96 with The topics are:
.
We should mention that this is a multipart message too.
0`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 (to detect lost messages).
1
2| rawtx | <serialized transaction> | <uint32 sequence number in Little Endian>
ACK 079576e2060f9702d69657b5b0c0a286d72cdcb7
Changes since my last review:
There are no critical grammatical mistakes in the updated PR, and I find the expanded description to be logically sound and easy to understand. Great Work @mbildwic!
103@@ -102,7 +104,20 @@ is structured as the following based on the type of message:
104
105 Where the 8-byte uints correspond to the mempool sequence number.
106
107-These options can also be provided in bitcoin.conf.
108+`rawtx`: notifies about all transactions, whether when they are added to mempool or when a new block arrives. This means it could happen that a transaction is published multiple times. First when it enters the mempool and then again in each block that includes it. The body of the message is the serialized transaction.
109+
110+`hashtx`: is triggered in the same way as in the previous topic, when any transaction is identified, either in the mempool or in a new block. 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 (to detect lost messages).
I think it’s fine to just repeat the first part of the rawtx
documentation here. If the ordering is changed or a new topic is added, the ‘previous topic’ might change.
0`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 (to detect lost messages).
112+ | hashtx | <32-byte transaction hash in Little Endian> | <uint32 sequence number in Little Endian>
113+
114+
115+`rawblock`: is triggered when the chain tip is updated. The body of the message is the serialized block.
116+
117+`hashblock`: is triggered in the same way as in the previous topic. The messages are also 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 (to detect lost messages).
0`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 (to detect lost messages).
110+`hashtx`: is triggered in the same way as in the previous topic, when any transaction is identified, either in the mempool or in a new block. 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 (to detect lost messages).
111+
112+ | hashtx | <32-byte transaction hash in Little Endian> | <uint32 sequence number in Little Endian>
113+
114+
115+`rawblock`: is triggered when the chain tip is updated. The body of the message is the serialized block.
0`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 (to detect
1lost messages).
2
3| rawblock | <serialized block> | <uint32 sequence number in Little Endian>
reACK 8ce9f74ae944f163cb1bbd030e062e2ac47d0cb2
Changes since my last review:
hashtx
and hashblock
topics. This is done to make the description more robust if there is an ordering change of topics in the future.rawtx
and rawblock
is added, along with the previously added syntax of hashtx
and hashblock
.I agree with the updated changes.
However, I think the description has become too lengthy, with a lot of repeated content in succession. I don’t exactly know how to tackle this. Maybe bolding or italicizing the main difference between topics might help, but I don’t know if that would be the right approach.
103@@ -102,7 +104,24 @@ is structured as the following based on the type of message:
104
105 Where the 8-byte uints correspond to the mempool sequence number.
106
107-These options can also be provided in bitcoin.conf.
108+`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 data size to detect lost messages).
nit: missing space between sentences
0`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 data size to detect lost messages).
(representing the data size to detect lost messages)
I’m not sure “data size” clarifies much here. I would associate that with sizes in bytes. Maybe “message count”?
Co-authored-by: 0xB10C <19157360+0xB10C@users.noreply.github.com>
Co-authored-by: Sebastian Falbesoner <sebastian.falbesoner@gmail.com>
This PR adds solid clarifications about the ZMQ topics that will be very helpful for all potential users of the ZMQ interface – this would have also saved me quite some time in the past. Kudos for expicitely mentioning the fact that rawtx
/hashtx
notifications appear both when added to the mempool or in new blocks. LGTM!
ACK 9544ab60ce212a29306f021c2cc6721c34485b54