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
  • Purpose
  • Scope
  • Background
  • Process Overview
  • Context

Was this helpful?

Export as PDF
  1. Supporting & Reference Docs
  2. Sidechain Operator Node (SON) Development
  3. Bitcoin Sidechain Docs
  4. Functional Specs

SON Multisig Bitcoin Wallet

Purpose

The purpose of this document is to outline the steps required to create and change the multisig bitcoin wallet for Peerplays bitcoin sidechain.

Scope

The functional requirement listed in this document will be limited to the Multisig Bitcoin Wallet (Primary Wallet) portion of the SON. This will outline the required steps that will be performed by the Peerplays blockchain to create a multisig bitcoin wallet using the bitcoin signatures of the SONs and changing the signatures in the multisig wallet when required. Also outlined here will be the sequence in which the required steps will be performed including:

  • any interactions with the user.

  • validations to ensure complete and accurate information gathering.

Background

The Bitcoin Sidechain functionality has been implemented in the Peerplays blockchain but it doesn't take into account, the change of SONs. As per the current implementation of Sidechain, a multisig bitcoin wallet will be created on the bitcoin blockchain to hold the bitcoins that have been deposited into the pBTC accounts of the Peerplays users. Every Peerplays witnesses will have a bitcoin transaction signing key for this multisig bitcoin wallet and will be required to sign any withdrawal transaction. When a SONs changes, the transaction signing key of the outgoing witness needs to be removed from the multisig bitcoin wallet and the key of the incoming witness needs to be added. The suggested proposal is to make the Sidechain code available as a plugin and assign the responsibility for running the sidechain code to separate nodes called the Sidechain Operating Nodes (SONs). The SONs will be independent of the witnesses and don't need to be changed much often.

Process Overview

Described here is the process to create the mutlisig bitcoin wallet with the SONs signatures and changing the signatures when required.

Context

In the sidechain implementation, at the beginning of the sidechain fork, a multisig bitcoin wallet called the Primary Wallet is created on the bitcoin blockchain to store the funds transferred by the users to their pBTC accounts. This multisig bitcoin wallet should be created by using the bitcoin public keys of the SONs in the active SONs list We will also have to use the Hash Time Locked Contracts (HTLC) for this address so that if a user transfers the funds to their pBTC accounts and due to some error/downtime, the funds will enter a pending status and wait until more active SONs are available to process and sign the transaction

  1. SON Change: The SONs may change at any maintenance interval when the votes are tallied and the existing SONs are voted out. Since, the bitcoin public keys of the SONs will be used to create the multisig bitcoin wallet, whenever SONs in the active lists change, this changes the set of keys associated with multisig bitcoin wallet. This when active SON's change a new multisig bitcoin wallet must be created because the multisig bitcoin wallet address is dependent on the public keys. Once a new wallet has been created, system must transfer the funds from the old wallet to the new wallet every time an SON changes which will incur bitcoin transaction fees.

    Once, 1/3rd of the initial SONs change, we will create a new multisig bitcoin wallet with the public keys of the current SONs and transfer the funds from the previous wallet to the newly created multisig bitcoin wallet.

  2. SON Downtime: The SONs might stop functioning or go into maintenance. We should provide a mechanism to the SONs to announce any planned maintenance so that the community knows about it. In any case, the maximum continuous downtime allowed for an SON will be 12 hours (This should be a chain parameter). If the downtime exceed 12 hours, the SON will be deregistered. During the downtime, the SON will not be able to sign any transactions. If more than 1/3rd SONs are not able to sign the bitcoin transactions, the pending transaction go into wait mode as described in BTC Transaction Processing & Signing. Once the required number of active SONs reaches required threshold, queued transactions will be signed and processed.

    Similarly, if 2/3rdsmore SONs are down, the incoming bitcoin transactions can't be published on the Peerplays blockchain and the funds cannot be accepted. In this scenario, transactions will also enter a pending state in which they will await the required number of active SONs.

  3. SON Communication Problem: In case of a communication problem between the all SONs and the witnesses which might be caused due to a DOS attack or for any other reason, the sidechain functionality might come to a standstill for a period of time. In this scenario, any incoming funds into the multisig bitcoin wallet will enter a queued pending state until the minimum number of active SONs is available. Transactions will be signed and processed once required number of active SONs is available.

PreviousBitcoin Deposit HandlingNextHive Sidechain Docs

Was this helpful?