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
  • btc_input_data_operation (Same as bitcoin_issue_operation in Sidechain)
  • btc_withrawal_operation (Same as withdraw_pBTC_operation in the existing Sidechain feature)
  • btc_transaction_sign_operation (Same as btc_transaction_sign_operation in the existing Sidechain feature)

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-operations-draft

btc_input_data_operation (Same as bitcoin_issue_operation in Sidechain)

This operation creates an object that stores the information about deposits for their further approval. Some minor changes will be required in its implementation i.e. the operation has to be signed by the active SONs holding more than 2/3rd of the votes.

This operation contains the following fields:

Type

Name

Description

asset

fee

transaction fee for the operation

account_id_type

payer

SON account

vector<info_for_vin>

info_for_vins

a vector of vins

string

btc_block_hash

hash of a block on the side of BTC

uint64_t

estimated_feerate

estimate fee for Bitcoin transaction

This operation is handled as follows:

1) Index is searched by id for vins same as the vin that is being added ( hash( string(hash_of_trx) + string(n_vout) ) ). 2) Id is calculated by the evaluator, since if it is passed in an operation, a potential attack vector opens: a valid ID for a different vin could be used to get approvals on another vin. 3) If nothing was found, a new btc_input_data_object object is created, storing the number of active SON members. son_id of the SON that sent the operation to set is also recorded in order to check confirmations by other SONs. 4) If set.size() > (2/3 + 1) * active_son_members_amount, btc_input_data_object object is considered confirmed (the consensus part). 5) Estimated fee index is searched for btc_fee_data_object by ID ( hash( string(btc_block_hash) ) ). 6) If no object was found, we create a btc_fee_data_object object, storing the number of active SON members. 7) Estimate fee map (key=son_id, value=fee) is checked for records about operation sender. If there is a record, handling stops. 8) If there are no records found in step 7, new information is recorded to the map. 9) If map.size() > (2/3 + 1) * active_son_members_amount, btc_fee_data_object is considered confirmed (the consensus part).

btc_withrawal_operation (Same as withdraw_pBTC_operation in the existing Sidechain feature)

This operation creates an object with information about a BTC withdrawal (btc_withdrawal_object). Some minor changes will be required in its implementation i.e. the operation has to be signed by the active SONs holding more than 2/3rd of the votes.

The fields are as follows:

Type

Name

Description

asset

fee

fee for the transaction on PeerPlays blockchain

account_id_type

payer

id of the PeerPlays account that initiates the withdrawal

string

data

bitcoin address, to which BTC is being withdrawn

uint64_t

amount

the amount of withdrawal in satoshis

This operation is handled as follows:

1) Validation is performed to make sure that the withdrawing PeerPlays account has enough pBTC for the withdrawal amount + fees (withdrawal amount + fee for son members + fee for Bitcoin transaction). 2) btc_withdrawal_object is created. It contains the following information: ID of the withdrawing account (account_id_type), Bitcoin address to withdraw to (string), amount of withdrawal in satoshis (uint64_t), used flag that indicates whether this object has been used (bool). 3) The amount from step 1 is burnt from the withdrawing user's balance 4) Confirmed objects are processed once every N block on PeerPlays (where N is a constant specified in the protocol. An example of N is 300 - since average blockTime on Bitcoin is ~10 minutes, and ~2 seconds on PeerPlays), which allows to minimize the tx fees by placing multiple withdrawals into one transaction. 5) On the node accepting a PeerPlays block a check is performed on its number (block_number % N == 0). If block_number = N, a btc_transaction_object, that contains a Bitcoin transaction. If inputs и withdrawals exceed the size of a Bitcoin transaction, another object is created containing a transaction that depends on the previous one. 6) On block acceptance an index storing the objects with btc_tx is checked. If it cointains an unsigned transaction, a signal for creating a son_member signature is emitted. 7) A Bitcoin transaction is emitted to Bitcoin blockchain once the object receives the required number of signatures.

btc_transaction_sign_operation (Same as btc_transaction_sign_operation in the existing Sidechain feature)

This operation serves to sign Bitcoin transactions by SONs. Some minor changes will be required in its implementation i.e. the operation has to be signed by the active SONs holding more than 2/3rd of the votes. It contains the following fields:

Type

Name

Description

asset

fee

fee for the transaction on PeerPlays blockchain

account_id_type

payer

SON account that pays the fee

vector<vector>

signatures

Signatures for vins

The process for signing a transaction is as follows: 1) When a signal from database::apply_block is called to create a signature for a Bitcoin transaction, a method from btc_sidechain_service is called. 2) btc_transaction_sign_operation is created storing the signature, and is broadcast on PeerPlays blockchain. evaluator class for this operation records btc_transaction_object of the signature, and, when the required number of signatures is collected ((2 / 3 + 1) * son_members_amount), sorts them in accordance with redeem script. The sorting is required since the keys in multisig script are handled in pre-defined order, and it is required that signatures are sorted in the same order (key - signature).

Previousbitcoin-deposit-handling-lldNextbitcoin-sidechain-handler-lld

Was this helpful?