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
  • 1. Purpose
  • 2. Scope
  • 3. Background
  • 4. How it all works
  • 5. Current Sidechain Implementation
  • 6. Challenges for the proposed SONs Implementation
  • 6.1 Disadvantages with current weighted model
  • 6.2 Advantages with equally weighted SONs model
  • 7. Scenarios Captured for PW address change
  • 7.1 De-Register issued by Active SON user
  • 7.1.1 SON weight < ( 1/3 or 33.33% ) – PW Address remains the same.
  • 7.1.2 SON weight > ( 1/3 or 33.33% ) – PW Address changes.
  • 7.2 De-Register issued by Inactive SON user – PW Address remains the same.
  • 7.3 Active SON Abruptly Down
  • 7.3.1 SON weight < ( 1/3 or 33.33% ) – PW Address remains the same.
  • 7.3.2 SON weight > ( 1/3 or 33.33% ) – PW Address changes.
  • 7.4 Inactive SON(s) Abruptly Down – PW Address remains the same.
  • 7.5 Multiple Active SONs Abruptly Down
  • 7.5.1 Sum of the downed SONs Weight < ( 1/3 or 33.33% ) – PW Address remains the same.
  • 7.5.2 Sum of the downed SONs weight > ( 1/3 or 33.33% ) – PW Address changes.
  • 7.6 Active SON ( weight > 1/3 or 33.33% ) goes down before Bitcoin transaction is confirmed – PW Address changes.

Was this helpful?

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

changeover and SON maintenance scenarios lld

1. Purpose

The purpose of this document is to outline the existing changeover process in Sidechain and list the SON maintenance scenarios (both user-triggered and abruptly downed servers).

2. Scope

The design listed in this document is limited to the listing of the scenarios that can arise due to maintenance and how to tackle the PW changes arising out of the change of SONs.

This document also outlines the current implementation of Sidechain and whats missing from that implementation and how it is different from the current SONs requirement.

3. Background

The Bitcoin Sidechain functionality has been implemented in the Peerplays blockchain but it doesn't take into account, the change of witnesses.

As per the current implementation of Sidechain, a multi-sig bitcoin address 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 multi-sig bitcoin address and will be required to sign any withdrawal transaction.

When a witness changes, the transaction signing key of the outgoing witness needs to be removed from the multi-sig bitcoin address 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 SON functionality will be independent of the witness functionality and SONs don't need to be changed much often.

4. How it all works

There are two types of bitcoin addresses,

  1. PW Address

  2. Deposit Address of a User.

Following are the list of steps needed for a user to transfer BTC,

  1. A PW Address is created which acts as a global address holding all the user funds.

  2. A user issues create_bitcoin_address and gets a bitcoin address multi-signed by SONs ( 10-of-15 multi-sig Proposed currently ). This is called Deposit Address.

  3. The user transfers BTC funds to the deposit address.

  4. Bitcoin block listener catches the transaction if any vout has any of the deposit addresses.

  5. A proposal to send the BTC from the user Deposit Address to PW address is initiated by SONs and if approved, a bitcoin transaction signed by the top 2/3 SONs is sent out.

  6. After receiving confirmation from Bitcoin ( 6 blocks confirmation ) a proposal to issue pBTC to the user's account is initiated by SONs.

  7. If the proposal is approved, pBTC is issued to the user's peerplays account.

  8. External miner fee is also taken into consideration for the bitcoin transaction initiated from deposit address to PW address apart from fees of proposals initiated.

5. Current Sidechain Implementation

In the current sidechain implementation, Witnesses act as signatories and follow 5-of-15 multi-sig model.

Each witness has the same weight associated with its signing key.

PW address is changed if more than 5 witnesses are voted out which is very unlikely.

All the user deposit addresses are also needed to be changed along with PW address.

More info can be found about sidechain implementation on this site.

6. Challenges for the proposed SONs Implementation

The current proposal of SONs takes DPOS mechanism into consideration for associating weights with signatures of each SON.

Based on the votes tallied each SON will have a different weight of the signature in each bitcoin multi-sig address (10-of-15 multi-sig) that's issued on Peerplays network.

6.1 Disadvantages with current weighted model

  1. With the weighted signing, if any of the SONs can accumulate enough weight which is more than 1/3 (34%), we will have a single point of failure model.

  2. If such a SON ( which has more than 1/3 or at least 34% weight) goes down abruptly, there is no other way but to change the PW address.

  3. PW multi-sig address might need to be changed multiple times in this model because of the weights.

  4. Loss of miners fee associated with the transfer of BTC from old PW address to new PW address.

6.2 Advantages with equally weighted SONs model

  1. With 10-of-15 multi-sig equally weighted model, it is almost impossible for more than 5 SONs to go down at a time. Thus very less chance of SON network stall.

  2. PW multi-sig address need not be changed multiple times which can save us the miner fee that's charged for sending BTC from old PW to latest PW.

7. Scenarios Captured for PW address change

The idea is that immediately after the initial hard fork with SON change, a new PW address is created and a buffer amount of bitcoins are sent to it.

This buffer is to offset the mining fee associated with the transfer of BTC from old PW address to the new PW address.

7.1 De-Register issued by Active SON user

7.1.1 SON weight < ( 1/3 or 33.33% ) – PW Address remains the same.

If the active SON weight is less than the 1/3 or 33.33% then there is no need to change the PW address.

After the maintenance interval, a new set of active SONs are active but the PW address remains the same.

==> Transfers from user deposit addresses to PW Address goes on as usual.

7.1.2 SON weight > ( 1/3 or 33.33% ) – PW Address changes.

We will wait until the maintenance interval, tally votes again during the maintenance interval.

If the active SON weight is greater than the 1/3 or 33.33% then a new PW address is assigned.

Funds from the old PW Address are transferred to the new PW Address.

The SON is removed from the active list.

==> All the transactions for transferring BTC from Deposit address to PW Address are stuck till the SON node comes back.

==> Deposit addresses have to be changed to be signed by the new set of SONs.

7.2 De-Register issued by Inactive SON user – PW Address remains the same.

If an inactive SON is de-registered, there is no need to change the PW Address.

After the maintenance interval, we can allow the user to claim his vesting balance after 2 days.

==> Transfers from user deposit addresses to PW Address goes on as usual.

7.3 Active SON Abruptly Down

7.3.1 SON weight < ( 1/3 or 33.33% ) – PW Address remains the same.

If the active SON weight is less than the 1/3 or 33.33% then there is no need to change the PW address.

After the maintenance interval, a new set of active SONs are active but the PW address remains the same.

==> Transfers from user deposit addresses to PW Address goes on as usual.

7.3.2 SON weight > ( 1/3 or 33.33% ) – PW Address changes.

We will wait until the maintenance interval, tally votes again during the maintenance interval.

If the active SON weight is greater than the 1/3 or 33.33% then a new PW address is assigned.

Funds from the old PW Address are transferred to the new PW Address.

The SON is removed from the active list.

All the transactions for transferring BTC from Deposit address to PW Address are stuck till the SON node comes back.

==> All the transactions for transferring BTC from Deposit address to PW Address are stuck till the SON node comes back.

==> Deposit addresses have to be changed to be signed by the new set of SONs.

7.4 Inactive SON(s) Abruptly Down – PW Address remains the same.

If an inactive SON is down, there is no need to change the PW Address.

After the maintenance interval, we can allow the user to claim his vesting balance after 2 days.

==> Transfers from user deposit addresses to PW Address goes on as usual.

7.5 Multiple Active SONs Abruptly Down

7.5.1 Sum of the downed SONs Weight < ( 1/3 or 33.33% ) – PW Address remains the same.

If the weight of SONs went down is less than the 1/3 or 33.33% then there is no need to change the PW address.

After the maintenance interval, a new set of active SONs are active but the PW address remains the same.

==> Transfers from user deposit addresses to PW Address goes on as usual.

7.5.2 Sum of the downed SONs weight > ( 1/3 or 33.33% ) – PW Address changes.

We will wait until the maintenance interval, tally votes again during the maintenance interval.

If the sum of the weight of the active SONs that are down is greater than the 1/3 or 33.33% then a new PW address is assigned.

Funds from the old PW Address are transferred to the new PW Address.

The SONs are removed from the active list.

All the transactions for transferring BTC from Deposit address to PW Address are stuck till one or more SON nodes comes back which allow us to hit the required threshold weight of 2/3 or 66.67%.

==> All the transactions for transferring BTC from Deposit address to PW Address are stuck till one or more SON nodes comes back which allow us to hit the required threshold weight of 2/3 or 66.67%.

==> Deposit addresses have to be changed to be signed by the new set of SONs.

7.6 Active SON ( weight > 1/3 or 33.33% ) goes down before Bitcoin transaction is confirmed – PW Address changes.

If an active SON with enough weight to stall the SON network goes down in the middle of transfer of BTC from user's deposit address to PW address and then the transaction is not confirmed on Bitcoin network, then the funds are stuck in the user deposit address till the SON comes back.

During maintenance, a new set of SONs are elected.

PW Address is changed with new signatories.

Previousclaiming initial son vesting lldNextuser-sidechain-addresses-mapping

Was this helpful?