SLPDB Readme

Last Updated: 2020-03-22

Current SLPDB Version: 1.0.0-rc6

• 1. What is SLPDB?
• 2. Do you need to install SLPDB?
• 3. How do I query for SLP data?
  • 3.1. Working with Large Numbers (Decimal128 and BigNumber)
• 4. Installation & Setup Instructions
  • 4.1. Prerequisites
  • 4.2. Full Node Settings for bitcoin.conf
  • 4.3 BCHD & gRPC Support
  • 4.4. Testnet Support
  • 4.5. Running SLPDB
  • 4.6. Updating SLPDB
  • 4.7. Filtering for Specific Token ID
  • 4.8. Pruning
• 5. Real-time Notifications
  • 5.1. ZeroMQ (ZMQ)
  • 5.2. HTTP Gateways
• 6. MongoDB Collections & Data Schema
  • 6.1. DB Collections
• 7. Test Harnesses
  • 7.1 Parser Tests
  • 7.2 Input Tests
  • 7.3 Regtest Network Tests
• 8. Change Log

1. What is SLPDB?

SLPDB is an indexer service for storing all data related to the Simple Ledger Protocol with realtime transaction and block notifications. Users can build block explorers (e.g., https://simpleledger.info), track token burn and mint history, track mint baton status, generate token holder lists at any block height, and easily determine state for script based smart contracts. Web sites and services can easily create new routes for SLP data when using the SlpServe and SlpSockServe http gateways.

SLPDB records all SLP token data, but it can be easily configured to only look at a specified subset of tokens using the token filtering feature. Filtering for your specific needs can drastically improve realtime notification speed, reduce initial db sync time, and reduce the db footprint.

Live status of nodes running slpdb can be found at: https://status.slpdb.io.

2. Do you need to install SLPDB?

Most likely you do not need to install SLPDB. Most users will be better off using someone else's publicly shared SLPDB instance like https://slpdb.fountainhead.cash or https://slpdb.bitcoin.com. You only need to install SLPDB, SlpServe, and/or SlpSockServe if any of the following is true:

• You cannot rely on a third-party for your SLP data.
• The rate limits imposed by slpdb.fountainhead.cash or slpdb.bitcoin.com are too restrictive for your needs.
• Realtime event notifications available at slpsocket.fountainhead.cash are not fast enough for your needs.

NOTE: If you are going to operate your own SLPDB instance you should join the telegram group for help and updates: https://t.me/slpdb

3. How do I query for SLP data?

Queries into SLPDB data are made using bitquery which allows MongoDB queries and jq queries over HTTP. Here are some example SLPDB queries:

• Get details of all token IDs (example)
• Get token details for single token ID (example)
• Get addresses for a single token ID (example)
• Get token balances for an address (example)
• Get utxos for a single token ID (example)
• Get transaction history by token ID (example)
• Get transaction history by address (example)
• Get transaction history by address and token ID (example)
• Get all invalid token transactions (w/ SLP op_return) (example)
• Get transaction counts for each token (w/ time range) (example)
• Get SLP usage per day (w/ time range) (example)
• List input/output amount total for each valid transaction (example)

Users should utilize the SlpServe and SlpSockServer projects in order to conveniently query for the SLP data produced by SLPDB.

3.1. Working with Large Numbers (Decimal128 and BigNumber)

Some of the values used in SLP require 64 or more bits of precision, which is more precision than number type can provide. To ensure value precision is maintained values are stored in collections using the Decimal128 type. Decimal128 allows users to make database queries using query comparison operators like $gte.

The services SlpServe and SlpSockServer return query results as a JSON object with Decimal128 values converted to string type so that readability is improved for the query consumer, as opposed to being returned as an awkward $DecimalNumber JSON object. The string type also maintains the original value precision. If a user wants to perform math operations on these string values the user will need to first convert them to a large number type like BigNumber or Decimal128 (e.g., Decimal128.fromString("1000.123124") or using bignumber.js npm library via new BigNumber("1000.00000001")).

4. Installation Instructions

4.1. Prerequisites

• Node.js 12
• MongoDB 4.0+
• BitcoinABC, BitcoinUnlimited, BCHD, or other Bitcoin Cash full node with:
  • RPC-JSON (or gRPC) and
  • ZeroMQ event notifications

4.2. Full Node Settings for bitcoin.conf

The following settings should be applied to your full node's configuration. NOTE: The settings presented here are matched up with the default settings presented in config.ts, you should modify these settings and use environment variables (shown in config.ts) if you need a custom setup.

• txindex=1
• server=1
• rpcuser=bitcoin
• rpcpassword=password
• rpcport=8332
• rpcworkqueue=10000
• rpcthreads=8
• zmqpubhashtx=tcp://*:28332
• zmqpubrawtx=tcp://*:28332
• zmqpubhashblock=tcp://*:28332
• zmqpubrawblock=tcp://*:28332
• Optional: testnet=1

4.3. BCHD & gRPC Support

High speed gRPC is supported with BCHD 0.15.2+ full nodes in place of JSON RPC and incoming ZMQ notifications. To enable, add the environment variables grpc_url and grpc_certPath. See the example.env file in this project and the BCHD documentation for more details. For instructions on installing a self-signed certificate see guidance here.

4.4. Testnet Support

To use SLPDB with Testnet simply set your full node to the testnet network (e.g., set testnet=1 within bitcoin.conf) and SLPDB will automatically instantiate using proper databases names according to the network. For informational purposes the database names are as follows:

• Mainnet
  • Mongo db name = slpdb
  • LevelDB directory = ./_leveldb
• Testnet
  • Mongo db name = slpdb_testnet
  • Testnet diectory = ./_leveldb_testnet

4.5. Running SLPDB

1) Run MongoDB (config.ts default port is 27017)

2) Run Bitcoin Cash full node using bitcoin.conf settings from above.

• BitcoinABC
• BitcoinBU

3) Install SLPDB dependencies using npm install at the command-line

4) Start SLPDB using npm start at the command-line and wait for sync process to complete (monitor status in the console).

• SLPDB will need to crawl the blockchain to save all previous SLP transaction data to MongoDB

• After crawling SLPDB will build token graphs for each token using either the raw transaction data or a previously saved token graph state.

5) Install and run slpserve and/or slpsocket to access SLP token data and statistics

4.6. Updating SLPDB

1) Execute git pull origin master to update to latest version.

2) Execute npm install to update packages

3) Execute npm run migrate up to run latest migrations.

4) Restart SLPDB.

4.7. Filtering SLPDB to specific Token IDs

Modify the example-filters.yml file to suit your needs and then rename it as filters.yml to activate the filtering. Currently, include-single is the only filter type available, reference the example file for useage requirements.

4.8. Pruning

Pruning removes totally spent and aged transactions from the global transaction cache, the token graph, and the validator cache. Pruning occurs after a transaction has been totally spent and is aged more than 10 blocks. At this time there is no custom configuration available for pruning.

5. Real-time Notifications

5.1. ZeroMQ (ZMQ)

SLPDB publishes the following notifications via ZMQ and can be subscribed to by binding to http://0.0.0.0:28339. The following events can be subscribed to:

• mempool
• block

Each notification is published in the following data format:

{
    "tx": {
        h: string; 
    };
    "in": Xput[];
    "out": Xput[];
    "blk": { 
        h: string; 
        i: number; 
        t: number; 
    };
    "slp": {
        valid: boolean|null;
        detail: {
            transactionType: SlpTransactionType;
            tokenIdHex: string;
            versionType: number;
            symbol: string;
            name: string;
            documentUri: string; 
            documentSha256Hex: string|null;
            decimals: number;
            txnContainsBaton: boolean;
            txnBatonVout: number|null;
        } | null;
        outputs: { address: string|null, amount: Decimal128|null }[]|null;|null;
        invalidReason: string|null;
        schema_version: number;
    };
}

5.2 HTTP Gateways

Realtime SLP notifications can be accessed via HTTP server-sent events (SSE) by utilizing SlpSocketServe. A good alternative to SLPDB based realtime notifications is SlpStream which utilizes the gs++ backend.

6. MongoDB Collections & Data Schema

Three categories of information are stored in MongoDB:

1. Valid and invalid SLP token transactions,
2. Statistical calculations about each token, and
3. Token graph state

6.1. DB Collections

Four MongoDB collections used to store these three categories of data, they are as follows:

• confirmed = c and unconfirmed = u

  • Purpose: These two collections include any Bitcoin Cash transaction containing the "SLP" Lokad ID and passes all filters set in filters.yml. The collection used depends on the transaction's confirmation status . Both valid and invalid SLP transactions are included. Whenever new SLP transactions are added to the Bitcoin Cash network they are immediately added to one of these collections.

  • Schema:

  {
      "tx": {
          h: string; 
      };
      "in": Xput[];
      "out": Xput[];
      "blk": { 
          h: string; 
          i: number; 
          t: number; 
      };
      "slp": {
          valid: boolean|null;
          detail: {
              transactionType: SlpTransactionType;
              tokenIdHex: string;
              versionType: number;
              symbol: string;
              name: string;
              documentUri: string; 
              documentSha256Hex: string|null;
              decimals: number;
              txnContainsBaton: boolean;
              txnBatonVout: number|null;
          } | null;
          invalidReason: string|null;
          schema_version: number;
      };
  }

• tokens = t

  • Purpose: This collection includes metadata and statistics about each token. Each time SLPDB has finished updating a token graph the associated items in this collection are updated.

  • Schema:

  {
      "tokenDetails": {
          transactionType: SlpTransactionType;
          tokenIdHex: string;
          versionType: number;
          timestamp: string|null;
          timestamp_unix: number|null;
          symbol: string;
          name: string;
          documentUri: string; 
          documentSha256Hex: string|null;
          decimals: number;
          containsBaton: boolean;
          batonVout: number|null;
          genesisOrMintQuantity: Decimal128|null;
          sendOutputs: Decimal128[]|null;
      };
      "tokenStats": {
          block_created: number|null;
          approx_txns_since_genesis: number;
      }
      "pruningState": TokenPruneStateDbo;
      "mintBatonUtxo": string;
      "mintBatonStatus": TokenBatonStatus;
      "lastUpdatedBlock": number;
      "schema_version": number;
      "nftParentId?": string;
  }

• graphs = g

  • Purpose: This collection contains an item for each valid SLP transaction (can be GENESIS, MINT, or SEND)

  • Schema:

  {
      "tokenDetails": { 
          tokenIdHex: string 
      };
      "graphTxn": {
          txid: string;
          details: SlpTransactionDetailsDbo;
          outputs: GraphTxnOutputDbo[];
          inputs: GraphTxnInputDbo[];
          _blockHash: Buffer | null;
          _pruneHeight: number | null;
      };
  }

7. Test Harnesses

SLPDB is backed by three distinct test harnesses, they include (1) OP_RETURN message parsing unit tests and differential fuzzing, (2) graph input unit tests, and (3) end-to-end regression testing.

7.1. Parser Tests

SLPDB leverages the SLPJS npm library has been tested using differential fuzzing and passes all SLP message parser unit tests for Token Type 1 and NFT1. You can learn more about this testing at the following locations:

• SLP Unit Tests - Parsing of OP_RETURN scripts
• JS Fuzzer
• c++ fuzzers

7.2. Input Tests

Graph validation typically requires checking that a transactions's valid inputs the outputs specified in the SLP OP_RETURN message. The SLPJS npm library also passes all unit tests which test for the specified input requirements for Token Type 1 and NFT1, and you can learn more about these types of tests at the following location:

• SLP Unit Tests - Transaction input tests

7.3. End-to-End Tests

A set of end-to-end tests have been created in order to ensure the expected behavior of SLPDB utilizing the bitcoin regtest network. These tests simulate actual transaction activity using the bitcoin regtest test network and check for proper state in mongoDB and also check that zmq notifications are emitted. The tests directory contains the end-to-end tests which can be run by following the instructions provided in the regtest directory.

8. Change Log

• 1.0.0

  • Removed utxos and addresses collections, as this information can be queried from the graphs collection. Updated README examples for queries which relied on now defunct utxos and addresses collections
  • Added Topological sorting in block crawl to allow for token validation during block crawl
  • Fixed issue where unconfirmed/confirmed transactions where initially writen to db without SLP property and then updated later after a subsequent validation step.
  • Fixed issue where MINT baton address is wrong if not the same as token receiver address.
  • Added graph pruning to actively reduce memory footprint
  • Move mint baton status (mintBatonStatus) and txo out of statistics (mintBatonUtxo), these are now main property of the token document
  • Update notification format for consistent value type, always returning string based numbers, no more Decimal128 in block notification
  • Removed token stats properties: block_last_active_send, block_last_active_mint, qty_valid_token_utxos, qty_valid_token_addresses
  • Removed token stats properties: qty_token_minted, qty_token_burned, qty_token_circulating_supply
  • Removed UTXO status enums: SPENT_INVALID_SLP, BATON_SPENT_INVALID_SLP
  • Renamed qty_valid_txns_since_genesis to approx_txns_since_genesis, since this can be corrupted if the block checkpoint is reset.
  • Removed network dependency to rest.bitcoin.com

• 0.15.6

  • Bug fixes and improvements in slpjs

• 0.15.5

  • Various bug fixes and improvements
  • NOTE: this version was not published

• 0.15.4

  • Added statuses collection
  • Added env variables for disabling graph search and zmq publishing
  • Caching improvements to speed up token processing
  • Various fixes and improvements

• 0.15.3

  • Additional db cleanup needed in graphs collection from the issue fixed in 0.15.2
  • Removed unneeded object initializers in FromDbObjects, moved to TokenGraph constructor

• 0.15.2

  • Fixed issue with address format occurring when restarting SLPDB
  • Cleaned up readme file formatting (Jt)

• 0.15.1

  • Fix issue with minting baton status update on initiating token from scratch

• 0.15.0

  • Add Graph Search metadata (see example queries above for search examples)
  • Start listening to blockchain updates before the startup process for improved data integrity during long startup periods
  • Fixed bug where not all inputs were showing up in graph transactions
  • Replaced getinfo RPC in favor of getBlockchainInfo
  • Fixed issue with tokens collection items missing "block_created" data

• 0.14.1

  • Improved token burn detection after a new blocks is broadcast
  • Updated to slpjs version 0.21.1 with caching bug fix.
  • Updated updateTxnCollections() so that any valid transactions erroneously marked as "invalid" get updated.
  • Refactored several methods to use destructured method parameters
  • Other minor refactors and improvements

• 0.14.0

  • Added NFT1 support
  • Improved token burn detection on new block event
  • Prevent duplicate zmq transaction publish notifications
  • Various bug fixes and improvements

• 0.13.0

  • Breaking Change: This change may impact any application using TokenUtxoStatus or the Graph collection's graphTxn.outputs.status property. A new enum type was added to TokenUtxoStatus called "EXCESS_INPUT_BURNED". This status is applied to any transaction that has an input SLP quantity that is greater than output SLP quantity. This enum label is used within the Graphs collection's graphTxn.outputs.status property.
  • A new startup script called "reprocess" was added for the purpose of debugging. Usage is node index.js reprocess <tokenId>.
  • Fixed issue with block and mempool item cache used to ignore duplicate zmq notifications
  • Fixed testnet config starting block (off by one)
  • P2MS and P2PK output addresses are stored as scriptPubKey:<hex>
  • Reduced number of RPC calls by subscribing to zmq 'rawtx' instead of 'hashtx'
  • Other minor improvements