- 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/AddressMonitor
Address Monitor Service
This service, with service-id 17
is a subscription service. A connected
peer can subscribe to a list of bitcoin-addresses 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 17
.
Messages
Subscribe
We use a BitcoinScriptHashed tag which is a sha256, send as a 32-byte bytearray. subscriptions and detection happens, not exactly on address, but on the entire output-script. The entire output script is hashed giving a nice constant size identifier we use instead of an address.
The API is not meant to be user-facing, as such things like address encoding, cash-address etc are irrelevant to this API.
You need to convert the address to an actual script (typically starting with OP_DUP) and hash that in order to get to the BitcoinScriptHashed.
Hub / API. sId=17 mId=0 | ||
---|---|---|
BitcoinScriptHashed: 9 | sha256 | sha256 (single) hash of the script-out (32 bytes) |
SubscribeReply
Hub / API. sId=17 mId=1 | ||
---|---|---|
Result: 7 | positive-number | the amount of addresses found in the subscribe message |
ErrorMessage: 9 | string | Human readable error message |
Unsubscribe
Hub / API. sId=17 mId=2 | ||
---|---|---|
BitcoinScriptHashed: 9 | sha256 | sha256 (single) hash of the script-out (32 bytes) |
TransactionFound
These messages are initiated by the service and don’t require a reply. The service sends a message for each transaction that touches one of the subscribed addresses. One message is sent to the client if accepted into mempool, another when accepted in a block.
Hub / API. sId=17 mId=3 | ||
---|---|---|
TxId: 4 | bytearray | 32-byte sha256 hash |
BitcoinScriptHashed: 9 | sha256 | sha256 (single) hash of the script-out (32 bytes) |
Amount: 6 | natural-number | Amount of Satoshi received |
BlockHeight: 7 | number | Height of the block in the chain. |
OffsetInBlock: 8 | natural-number | Key useful for GetTransaction (only when confirmed) |
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 subscribed addresses.
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=17 mId=4 | ||
---|---|---|
Matched BitcoinScriptHashed: 9 | sha256 | sha256 (single) hash of the script-out (32 bytes) |
Amount: 6 | natural-number | Amount of Satoshi received |
Mempool 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=17 mId=4 | ||
---|---|---|
Matched BitcoinScriptHashed: 9 | sha256 | sha256 (single) hash of the script-out (32 bytes) |
Amount: 6 | natural-number | Amount of Satoshi received |
Mempool TxId: 4 | bytearray | 32-byte sha256 hash |
Double Spend Proof Data: 22 | bytearray | A full dsproof |