- Flowee the Hub/
- Service API overview
- Service/Blockchain
- Service/Live Transactions
- Service/Mining
- Service/Util
- Service/RegTest
- Service/Hub Control
- Service/Indexer
- Service/AddressMonitor
- Service/TransactionMonitor
- Service/BlockNotification
- Service/Double Spend
- Service/System
- Protocol Spec
- Example Message
Flowee the Hub — API documentation
Service/TransactionMonitor
Transaction Monitor Service
This service, with service-id 20
is a subscription service. A connected
peer can subscribe to a list of TXIDs and as long as the
connection stays open the Hub will monitor incoming transactions and blocks
for matches, which it will report by sending messages to the peer.
The service ID for this service is 20
.
Messages
Subscribe
We use a TXID tag which is a sha256, send as a 32-byte bytearray. subscriptions and detection happens on the transaction-id of the entire transaction.
Hub / API. sId=20 mId=0 | ||
---|---|---|
TxId: 4 | bytearray | 32-byte sha256 hash |
SubscribeReply
Hub / API. sId=20 mId=1 | ||
---|---|---|
Result: 21 | positive-number | the amount of txids found in the subscribe message |
ErrorMessage: 20 | string | Human readable error message |
Unsubscribe
Hub / API. sId=20 mId=2 | ||
---|---|---|
TxId: 4 | bytearray | 32-byte sha256 hash |
TransactionFound
These messages are initiated by the service and don’t require a reply. The service sends a message for each transaction that matches one of the subscribed ids. One message is sent to the client if accepted into mempool, another when accepted in a block.
TransactionFound on initial subscription (or) when matched in mempool
On initial subscribe we check the mempool for a hit but also we keep monitoring the mempool as the connection stays open. If there is a mempool match the below message is sent.
Hub / API. sId=20 mId=3 | ||
---|---|---|
Matched TxId: 4 | bytearray | 32-byte sha256 hash |
TransactionFound on block-mined
When a block is mined and a match is included, this message is sent.
Notice that multiple TxId
/ OffsetInBlock
pairs can be included in the
message if there are multiple subscriptions.
Hub / API. sId=20 mId=3 | ||
---|---|---|
Matched TxId: 4 | bytearray | 32-byte sha256 hash |
OffsetInBlock: 8 | natural-number | Key useful for GetTransaction (only when confirmed) |
BlockHeight: 7 | number | Height of the block in the chain. |
DoubleSpendFound
These messages are initiated by the service and don’t require a reply. The service sends a message for each double spend that touches one of the transactions.
A double spend notification is useful for unconfimed transactions because the network will only ever mine one of the two. What gets mined does not have to be the first transaction you have seen. (more), this message serves as a warning to be aware of the issue. Receiving parties might want to wait for a confirmation before they release the goods.
DoubleSpendFound based on transactions
When a node itself detects a double spend it will have both transactions available
and you will be able to get the full transaction that double spends one in the mempool.
API users can naturally use the livetx
service to
fetch that transaction too.
Hub / API. sId=20 mId=4 | ||
---|---|---|
Matched TxId: 4 | bytearray | 32-byte sha256 hash |
Full raw transaction: 23 | bytearray | A full transaction
DoubleSpendFound based on double-spend-proof
Peers exchange double spend proof messages so even if the node you are connected to didn’t observe two conflicting transactions we still get a notification of such an event happening.
A double spend proof holds cryptographic proof that the sender created two conflicting transactions spending the same money.
Hub / API. sId=20 mId=4 | ||
---|---|---|
Matched TxId: 4 | bytearray | 32-byte sha256 hash |
Double Spend Proof Data: 22 | bytearray | A full dsproof |