LogoLogo
PAO DocsCommunity DocsInfrastructure DocsPeerplays.com
  • Developer Documentation
  • API Reference
    • Peerplays Core API
      • Popular API Calls
      • Account History
      • Asset API
      • Block API
      • Crypto API
      • Database API
      • Network Broadcast API
      • Network Nodes API
      • Orders API
    • Wallet API
      • Account Calls
      • Asset Calls
      • Blockchain Inspection
      • General Calls
      • Governance
      • Privacy Mode
      • Trading Calls
      • Transaction Builder
      • Wallet Calls
    • Bookie API
      • General Calls
      • Listeners
      • Tournaments
  • Peerplays API Libraries
    • Python Peerplays
      • Installation
      • Creating an Account
      • Creating a Peerplays Wallet
      • NFT API
      • Marketplace API
      • Role Based Permissions API
  • Development Guides
    • Creating User Issued Assets
    • Introduction to Permissions
    • NFT Minting
    • Calculating Costs
  • The Cookbook
    • NFTs for Staking Creator Tokens
  • Tools and Integrations
    • PeerID
      • 1.0.0
        • Infrastructure
          • Deployment on a Linux Serve
          • Deployment to AWS ECS
            • Building the Docker Images
            • Storing Secrets in Amazon Parameter Store to use in ECS
            • Creating the Task Definition
            • Creating the Cluster
            • Creating the Service
        • Development
          • How does PeerID work without storing the keys ?
          • Authentication with PeerID
          • Brain Storming
          • Software Requirements
      • Authentication with PeerID
      • Requirements Specification
    • Random Number Generator
      • RNG Technical Summary
      • RNG API
  • Supporting & Reference Docs
    • Peerplays Development FAQs
    • Sidechain Operator Node (SON) Development
      • Generic Sidechain Docs
        • Quick joining GLADIATOR
        • Changes to Peerplaysjs-lib
        • Requirements Specification
        • Low Level Designs
          • bitcoin-deposit-handling-lld
          • bitcoin-operations-draft
          • bitcoin-sidechain-handler-lld
          • bitcoin-sidechain-multisig-bitcoin-wallet-and-bitcoin-addresses-pw
          • bitcoin-withdrawal-handling-lld
          • btc-address-scripting-mechanism
          • comparison-between-scenarios-for-handling-deposits-and-withdrawals
          • exchange-rate-list
          • generic-sidechain-deposit-hld
          • generic-sidechain-high-level-design
          • generic-sidechain-listener-hld
          • generic-sidechain-withdrawal-hld
          • refund-btc-mechanism
          • son-configuration
          • son-consensus-communication-and-transaction-signing-on-chain-lld
          • son-de-register-proposals-lld
          • son-objects-and-operators
          • son-rewards-lld
          • son-voting-lld
          • son-wallet-list_sons-lld
          • creation of a multi-sig bitcoin address lld
          • claiming initial son vesting lld
          • changeover and SON maintenance scenarios lld
          • user-sidechain-addresses-mapping
          • wallet-commands-for-son
        • Functional Specs
          • SON Configuration
          • SON rewards
          • SON Voting and Consensus
          • SONs switchover scenarios
          • SON Status Operations & Monitoring
          • Proposals
          • SON Smart Contracts
      • Bitcoin Sidechain Docs
        • Functional Specs
          • btc-refunds
          • voting-and-consensus
          • son-switchover
          • son-rewards
          • son-proposals
          • son-configuration
          • heartbeat-monitoring
          • BTC Transaction Processing & Signing
          • Bitcoin Withdrawal Handling
          • Bitcoin Deposit Handling
          • SON Multisig Bitcoin Wallet
      • Hive Sidechain Docs
        • Functional Specs
          • HIVE Deposit Handling
          • HIVE Withdrawal Handling
    • Peerplays DEX Development
      • Peerplays NEX
        • Functional Specifications
          • NEX-FS01 Dashboard Page
            • NEX-FS12 ETH-SONs Deposit/Withdraw Functionality
          • NEX-FS02 Login and Account Creation
          • NEX-FS03 Menus and Nav
          • NEX-FS04 Notifications
          • NEX-FS05a Market Page (alpha)
          • NEX-FS05 Market Page
          • NEX-FS06 Profile Page
          • NEX-FS07 Wallet Functions
          • NEX-FS08 App Settings
          • NEX-FS09 Blockchain Page
          • NEX-FS10 GPOS Page
          • NEX-FS11 WhaleVault Integration
      • Requirements Specification
      • Functional Specs
        • Asset Info Page and Asset Lists
        • Dashboard
        • Exchange Page
        • Login and Account Creation
        • User Account Page
        • Voting Page
    • SPK Network
      • Functional Specs
        • Claimdrop Snapshot Functional Specification
        • Initial Claimdrop Functional Specification
    • NFT Development
      • NFT Store
        • NFT Store User Stories
        • NFT Store UI HLD
        • NFT Store Requirements Specification
        • Functional Specifications
          • APP-FS01 App Header
          • APP-FS02 App Body
          • APP-FS03 App Footer
          • APP-FS04 App Navigation
          • APP-FS05 Wallet Functions
          • APP-FS06 App Home Page
          • APP-FS07 Account Page
          • APP-FS08 Browse View
        • App Page List
        • Requirement Traceability Matrix
    • Operation IDs List
    • Sidechain Flow Diagram (HIVE coin)
    • Sidechain Flow Diagram (Bitcoin)
    • Sidechain Flow Diagram (Ethereum coin)
    • TradeHands Explorer
      • User Personas
      • User stories
      • APP-FS01 Detailed View
      • Draft: APP-FS02 Front Page
      • APP-FS03 Collection Details Page
    • Grafana
      • Grafana Installation
      • Install Grafana Behind reverse proxy
      • Loki Installation
      • Promtail agent Installation
      • Grafana Explorer
    • NEX Deployment & Configuration
      • NEX Deployment
      • NEX - Blockchain API configuration
      • Deploying NEX in a HA scenario
    • API Node
      • MarketCap API
    • TOTO Application
      • FS-Subscription Plan
      • FS-Achievements
  • Development Workflow Docs
    • Development Workflow
  • Other Documentation
    • Peerplays Home
    • Community Docs
    • Infrastructure Docs
    • Site Reliability Engineering
Powered by GitBook
On this page
  • Objective
  • Block Diagram
  • Sequence diagram
  • Components
  • Listener
  • Communication interface
  • Event Handler
  • Suggested implementation

Was this helpful?

Export as PDF
  1. Supporting & Reference Docs
  2. Sidechain Operator Node (SON) Development
  3. Generic Sidechain Docs
  4. Low Level Designs

bitcoin-sidechain-handler-lld

Previousbitcoin-operations-draftNextbitcoin-sidechain-multisig-bitcoin-wallet-and-bitcoin-addresses-pw

Last updated 2 years ago

Was this helpful?

Objective

This document is intended to outline generic design of a blockchain handler, a component used for monitoring and processing changes on a Bitcoin network.

For general information on sidechain handlers, read:

Block Diagram

Link to file:

Sequence diagram

Link to file

Same sequence diagram applies for all sidechain handlers. It shows interactions between components in a single sidechain handler.

Components

The purpose of Bitcoin sidechain handler is to notify sidechain manager that a transaction of interest has happened, and forward the data about that transaction to it, for further processing. As stated in general design, standard components of the sidechain handler are listener, communication interface and event handler.

Listener

Assumptions

Blockchain node provides interface for monitoring changes in a blockchain.

Bitcoin node provides ZeroMQ messaging interface. The ZeroMQ facility implements a notification interface through a set of specific notifiers. Currently there are notifiers that publish blocks and transactions. This read-only facility requires only the connection of a corresponding ZeroMQ subscriber port in receiving software; it is not authenticated nor is there any two-way protocol involvement. Therefore, subscribers should validate the received data since it may be out of date, incomplete or even invalid.

Monitoring is based on new block, new transaction or filtered single event (like transfer operation to specific address)

Bitcoin's ZMQ uses a publish/subscribe (pubsub) design pattern, where the publisher in our case is our bitcoin node which published messages based on events. The subscriber on the other hand, includes any application looking to utilise it by subscribing to these events. There are currently 4 different publish (PUB) notification topics we can expose via bitcoind which notify us when ever a new block or transaction is validated by the node.

  • zmqpubhashtx : Publishes transaction hashes

  • zmqpubhashblock : Publishes block hashes

  • zmqpubrawblock : Publishes raw block information

  • zmqpubrawtx : Publishes raw transaction information

We can use any of these, but some are more practical than others. E.g. we can subscribe to receive hash values of newly created blocks:

socket.setsockopt( ZMQ_SUBSCRIBE, "hashblock", 0 );

socket.connect( "tcp://" + ip + ":" + std::to_string( zmq_port ) );

zmqpubrawtx looks like best candidate we can use, since we can get raw transaction info, decode it, and we will have all required info in a single call. However, depending on number of transaction, we can expect more traffic between bitcoin node and listener.

zmqpubhashblock is also a good candidate, we will receive the hash of newly created block, then we can read the whole block by communication interface, parse it and get the info we need.

There is a sufficient C/C++ library for connecting to monitoring interface

ZeroMQ project provides a client library which we can use to connect to a Bitcoin node ZeroMQ interface. The project is alive and well maintained. At the time of writing this document, we are not aware of any problem which would require us to use specific library version, or link it statically into our software.

There is a libzmq3-dev package in Ubuntu 18.04 repository.

This will be obvious developers choice, for ease of installation and usage.

Communication interface

Bitcoin provides RPC interface we can use to read additional transaction info from a node.

Depending on how we configure the listener, we will need more or less functionalities in this component.

In general, we will need:

  • Method to retrieve the whole block by hash

  • Method to retrieve the transaction by hash

  • Method to retrieve block as json

    • HTTP request to "http://ip/:PORT/rest/block/BLOCK_HASH.json"

  • Method to decode transaction

  • Method to retrieve the transaction fee

  • Method to send signed transaction to the node (for deposit/withdrawal)

Communication interface can be implemented as a HTTP client, which will send requests to a bitcoin node.

Event Handler

Event handler is a working horse of sidechain handler. It will receive input from a listener, and process it any way needed, in order to get the minimum required information about event of interest, namely transactions to the addresses we are interested in.

In general, event handler needs:

  • Access to the list of addresses we are interested in

Suggested implementation

  • sidechain_manager is a class implementing Sidechain Manager

    • Introduce a new element of network enum, to indicate that we want to use bitcoin network

    • namespace graphene { namespace peerplays_sidechain {

    • enum networks {

    • bitcoin

    • ...

    • };

    • class sidechain_net_manager {

...

    • Extend factory method to create the instance of sidechain_handler_bitcoin

    • bool sidechain_net_manager::create_handler(peerplays_sidechain::networks network, const boost::program_options::variables_map& options) {

    • ...

    • switch (network) {

    • case networks::bitcoin: {

    • std::unique_ptr<sidechain_net_handler> h = std::unique_ptr<sidechain_net_handler>(new sidechain_net_handler_bitcoin(options));

    • net_handlers.push_back(std::move(h));

    • ret_val = true;

    • }

    ...

  • Implement sidechain_handler_bitcoin class, inheriting sidechain_handler, implementing sidechain handler for Bitcoin

  • Implement zmq_listener, using ZeroMQ library

    • subsribe to hashblock or raw transaction

    • socket.setsockopt( ZMQ_SUBSCRIBE, "hashblock", 0 );

    • socket.connect( "tcp://" + ip + ":" + std::to_string( zmq_port ) );

      • or

      • socket.setsockopt( ZMQ_SUBSCRIBE, "rawtx", 0 );

    socket.connect( "tcp://" + ip + ":" + std::to_string( zmq_port ) );

  • Implement bitcoin_rpc_client class, HTTP client used to communicate with Bitcoin node

    • Implement, at least, following methods:

      • receive_full_block - to retrieve full block by block hash

      • receive_transaction - to retrieve transaction info by transaction hash

      • receive_block_as_json - to retrieve full block as json by block hash

      • decode_transaction - to decode raw bitcoin trasnaction

      • receive_estimated_fee - to retrieve transaction cost (transaction fee)

      • send_btc_tx - to send signed transaction to the bitcon node

  • Implement any additional code needed, for receiving event data, collecting any additional information about event of interest, with the final result as a data structure containing the following info:

  • struct sidechain_transaction_info {

  • graphene::peerplays_sidechain::networks network; // set to network::bitcoin

  • std::string source;

  • std::string destination;

  • uint64_t amount;

  • uint64_t transaction_fee;

}

    • Identifier of a sidechain handler (network::bitcoin)

    • Transaction’s source address (as string, representing sidechain native address)

    • Transaction’s destination address (as string, representing sidechain native address)

    • Transaction’s amount (as unsigned integer, in sidechain native currency)

    • Estimated transaction fee (as unsigned integer, in sidechain native currency)

For general information on sidechain listeners, read:

Some of the info in this section are taken from useful article on ZMQ and Bitcoin

https://peerplays.atlassian.net/wiki/spaces/PIX/pages/352026689/Generic+Sidechain+Interface+High+Level+Design
draw.io
https://drive.google.com/file/d/1ErmQfeaWa9m67si4hb0RZs54WVYWR0pC/view?usp=sharing
draw.io
https://drive.google.com/file/d/17kbez7C1Djaj-2AgyEzQ1Z-5CrSZ5wZE/view?usp=sharing
https://peerplays.atlassian.net/wiki/spaces/PIX/pages/352092181/Generic+Sidechain+Listener+HLD
https://bitcoindev.network/accessing-bitcoins-zeromq-interface/
https://zeromq.org/
https://github.com/zeromq/libzmq
https://packages.ubuntu.com/bionic/libzmq3-dev
https://bitcoin.org/en/developer-reference#getblock
https://bitcoin.org/en/developer-reference#gettransaction
https://bitcoin.org/en/developer-reference#decoderawtransaction
https://bitcoin.org/en/developer-reference#estimatesmartfee
https://bitcoin.org/en/developer-reference#sendrawtransaction