Block API

get_blocks

Get signed blocks.

vector<optional<signed_block>> graphene::app::block_api::get_blocks(
    uint32_t block_num_from, 
    uint32_t block_num_to)const

subscribe_to_market

Subscribe a listener to a betting market.

unsubscribe_from_market

Unsubscribe a listener from a betting market.

PeerID Backend

PeerID GUI

The network broadcast API is available from the full node via web-sockets.

Transactions

broadcast_transaction

Broadcast a transaction to the network.

The transaction will be checked for validity in the local database prior to broadcasting. If it fails to apply locally, an error will be thrown and the transaction will not be broadcast

void graphene::app::network_broadcast_api::broadcast_transaction(
    const precomputable_transaction &trx)

broadcast_transaction_with_callback

This version of broadcast transaction registers a callback method that will be called when the transaction is included into a block. The callback method includes the transaction id, block number, and transaction number in the block.

void graphene::app::network_broadcast_api::broadcast_transaction_with_callback(
    confirmation_callback cb, 
    const precomputable_transaction &trx)

Block

broadcast_block

Broadcast a signed block to the network.

void graphene::app::network_broadcast_api::broadcast_block(
    const signed_block &block)

Orders API

get_grouped_limit_orders

Get grouped limit orders in given market.

vector<limit_order_group> graphene::app::orders_api::get_grouped_limit_orders(
    std::string base_asset, 
    std::string quote_asset, 
    uint16_t group, 
    optional<price> start, 
    uint32_t limit)const

Its the Python library for communicating with the Peerplays blockchain.

The code is maintained at https://gitlab.com/PBSA/PeerplaysIO/tools-libs/python-peerplays

Ids

1.2.x : accounts

1.3.x : assets

Notes

def transfer(self, to, amount, asset, memo="", account=None, **kwargs):

p.rpc.get_account_balances("jemshid", [])

p.rpc.get_global_properties

private-key = ["TEST6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]

The python-peerplays library has following dependencies. Make sure that the above dependencies are installed, if not install with:

sudo apt-get install python3-dev build-essential libssl-dev\
 libffi-dev libxml2-dev libxslt1-dev zlib1g-dev

Now install python-peerplays as follows:

 pip install peerplays

Ipython is a rich interactive python command shell. It's recommended for trying out python-peerplays library. It can be installed with

pip install ipython

In case Python 2.7 is the default Python for your machine, repalce

pip with pip3

python with python3

ipython with ipython3

Ipython shell can be started with the command

ipython

All these experiments and examples are expected to be tried out in ipython command shell. Start the command shell with ipython

Node is the chain with which you wish to interact.

node = "wss://elizabeth.peerplays.download/api"

password = "password"

from peerplays import PeerPlays

p = PeerPlays(node)

To create a new wallet

p.newWallet(password)

Unlock the wallet

p.unlock(password)

Add private key / keys

p.wallet.addPrivateKey("5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3")

Additional Methods

p.wallet.unlocked() #returns True if wallet is unlocked. Wallet needs to be unlocked to perform operations on the blockchain.

p.wallet.getAccounts() #Lists all the accounts associated with the private key.

1. Purpose

The purpose of this document is to provide a low-level design for implementing list_sons wallet functionality.

2. Scope

The design requirement listed in this document will be limited to the SON Wallet functionality.

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. Sidechain Operator Node ( SONs )

More on SON Objects can be found at SON Objects and Operators

5. Proposed Design Change

Users should be able to list all the SON nodes on the blockchain.

They should be able to check the status of the SON which is provided by the son_status variable in the son_object.

They should be able to check the number of votes polled during the last cycle, which is provided by total_votes in son_object. This is changes in every maintenance interval.

For better UI, we can list the SONs based on their status i.e. Active SONs first, Inactive next, In_Maintenance next in that order.

We can even further extend the types of data with the information stored in son_statistics_object as well.

This can be done by introducing a new structure (son_info in the UML below) that can collate the information in database_api and send it to the wallet.

After creating the Task Definition, we can now create a Cluster.

Creating a Fargate Cluster

Select the Networking only cluster template.

Configure cluster

Enter the cluster name.

Networking

If you don't already have a VPC setup, it's good practice to create one.

An example VPC would have 4 subnets, 2 meant to be private, and 2 meant to be public.

Example:

CIDR block 10.0.0.0/16 Subnet 1: 10.0.0.0/24 Subnet 2: 10.0.1.0/24 Subnet 3: 10.0.2.0/24 Subnet 4: 10.0.3.0/24

You would then navigate to the VPC service and:

1. Create route table for each of the two subnets chosen to be public facing and route 0.0.0.0/0 to the VPC's internet gateway.

2. Create NAT gateways for the public facing subnets.

3. Create route tables for the private subnets and add a 0.0.0.0/0 routes to the NAT gateways.

{ "result": { "expires": "<expiry date of the token>", "app_id": <your client ID>, "scope": <permissions granted by the user>, "token": "<access token for the user>", "refresh_token": "<refresh token for the user>" }, "status": 200 }

Note: Store the access token and refresh token like passwords.

OAuth Resource Owner Password Credentials flow Follow the below steps to get the access token using the OAuth Resource Owner Password Credentials flow:

1. In your app, request for user's login credentials i.e. username or email ID and mobile or password and on your server, get an access token by making this request:

   POST https://peerid.peerplays.download/api/v1/auth/token ?login=<user's username or email ID> &password=<user's password> &mobile=<user's mobile number> &client_id=<your client ID>

   Either password or mobile parameters has to be passed in this request. If both are passed, the PeerID server validates both of them along with the login.

2. We respond with a json-encoded access token. The response looks like this:

   { "result": { "expires": "<expiry date of the token>", "app_id": <your client ID>, "scope": <permissions granted by the user>, "token": "<access token for the user>", "refresh_token": "<refresh token for the user>" }, "status": 200 }

Sending access tokens

Once you have the user’s access token, your app can perform the permitted operations on behalf of the user on the Peerplays blockchain using the /api/v1/app/operations API. You have to pass the access token for the user in the Authorization header for this API like:

curl -H "Authorization: Bearer <access token>" https://peerid.peerplays.download/api/v1/app/operations

Note: The access token for one app cannot be used for another app.

Refreshing access token

New OAuth2 access tokens have expirations. Token-expiration periods vary in length, based on how and when the token was acquired. Tokens return an expires field indicating how long the token should last. However, you should build your applications in such a way that they are resilient to token authentication failures. In other words, an application capable of refreshing tokens should not need to know how long a token will live. Rather, it should be prepared to deal with the token becoming invalid at any time.

On seeing a 401 - Unauthorized error, an application should try to refresh the session if a refresh token is present. If the refresh fails, the application should re-prompt the end user with another authentication dialog via the standard OAuth 2 flow.

Generally, refresh tokens are used to extend the lifetime of a given authorization.

How to refresh:

To refresh a token, you need the refresh_token that you get in the response when you exchange your code for the token and the client ID and client secret. The following API returns the new access token:

POST https://peerid.peerplays.download/api/v1/auth/refreshtoken ?refresh_token=<refresh token for the user> &client_id=<your client ID> &client_secret=<your client secret>

The response will look like this:

{ "result": { "expires": "<expiry date of the token>", "app_id": <your client ID>, "scope": <permissions granted by the user>, "token": "<access token for the user>", "refresh_token": "<refresh token for the user>" }, "status": 200 }

The two ways of deployment are explained in the documents below:

The following documents help to understand the requirements and authentication process of PeerID:

Introduction

With the implementation of Hierarchical Role based Permissions (HRP) in the Peerplays blockchain and the introduction of Custom Authorities, it is now possible to allow a proxy account to perform any operation on the Peerplays blockchain on your behalf. PeerID uses this feature to act as a proxy for any account that has provided the permission to perform a particular operations.

Custom Permissions

Every account that’s created on Peerplays has two default permissions by default.

1. Owner

2. Active

They have a parent-child relationship by default (owner being the parent). The implicit default permission linked to all operations is active, which sits one level below the owner permission within the hierarchy structure.

As a result, the active permission can do anything the owner permission can, except changing the keys associated with the owner.

With custom permissions, the permissions can be created separately and can be assigned the valid required authorities which satisfies the maximum recursion depth of the blockchain and the permissions can be linked to the operations through custom authorities which specifies the time validity of the permission over the operation. Any given permission of an account can be linked to multiple types of operations.

This gives applications flexibility to use the custom permission of an account and at the same time specify the validity.

Custom Authorities

In Peerplays (graphene-based chains), an authority consists of one or many entities that authorize an operation, such as transfers or bet placement, etc. Authority consists of one or several pairs of an account name with a weight. In order to obtain a valid transaction, the sum of the weights from signing the parties has to exceed the threshold as defined in the permissions.

Custom Authorities takes this concept to the next level with the help of Custom Permissions by storing the mapping between custom permissions and operations. The custom authorities specify the actual operation on the Peerplays blockchain that a proxy account can perform on behalf of another account and the validity of this arrangement.

Working of PeerID

As soon as an account is created or an existing Peerplays account logs in using PeerID, we create a custom permission for PeerID on the Peerplays blockchain to perform the custom_authority_create, custom_authority_update, custom_authority_delete operations on behalf of the account.

PeerID further allows developers to create an app which can request for additional permissions from the user. When the user joins the app by allowing the app to perform some operation on his behalf, PeerID creates a custom authority for the requested operation by using its own custom permission. This way, we don't have to store the user's keys anywhere.

API Reference

This section explains about the different types of API calls involved in exchanges and gateways. The sample output for several API calls are also listed. The following APIs are explained in this section:

1. Peerplays Core API

2. Wallet API

3. Bookie API

API Libraries

API Libraries plays an important role in communicating with Peerplays blockchain. This section explains about:

1. Steps to install

2. How to create an account?

3. How to create a Peerplays wallet?

4. NFT, Marketplace, and Role based Permission API

Click the below link to learn about the API Libraries in detail.

Development Guides

The guides in this section will describe about the User Issued Assets, types of permissions, a detailed explanation about NFTs, and finally about cost calculation. Click the link below to learn in detail.

The Cookbook

Peerplays community need some specialized work to accomplish the vision of the community. The work includes file encoding, file storage, content verifiers, and Content Delivery Network (CDN) gateways which are not covered directly by Peerplays but a system is created to complete these works in a decentralized way. Click the below link to learn in detail about the plan and process.

Tools & Integration

This section explains about important Authentication techniques and random numbers:

1. Peer ID - Explain about Authentication and Requirement to create a Peer ID

2. Random Number Generator (RNG) - Explain about RNG Generation process and API involved in getting a random number.

Reference Docs

This section contains needful documents which helps to provide details about any questions that arise during learning and experimenting with Peerplays applications.

The topics under Supporting & Reference Documents are listed below:

1. Peerplays Development FAQs

2. Sidechain Operator Node (SON) Development

3. Peerplays DEX Development

4. SPK Network

5. NFT Development

6. Operation IDs List

7. Sidechain Flow Diagram (HIVE coin)

8. Sidechain Flow Diagram (Bitcoin)

Workflow

The workflow section provides a step by step approach followed in the Peerplays development process. Click below to learn in details about the nature of workflow involved in developing any application.

Other Documentation

There are different types of documents available to reduce the cost around time and helps in landing to specific topics. Use the below links to navigate to your desired page.

1. Peerplays Public Docs Portal - Click to land in Public documentation portal.

2. - Click to gather extensive knowledge about Peerplays.

3. - Click to understand the operation of Peerplays node.

Asset API

get_asset_holders

Get asset holders for a specific asset.

get_all_asset_holders

Get all asset holders.

The network node API is available from the full node via web-sockets.

Obtain Network Information

get_info

Return general network information, such as p2p port.

get_connected_peers

Get status of all current connections to peers.

get_potential_peers

Return list of potential peers.

get_advanced_node_parameters

Get advanced node parameters, such as desired and max number of connections.

Change Network Settings

add_node

Connect to a new peer

set_advanced_node_parameters

Set advanced node parameters, such as desired and max number of connections.

Blockchain Inspection

get_block

Returns info about a specified block.

get_account_count

Returns the number of accounts registered on the blockchain.

get_global_properties

Returns the block chain’s slowly-changing settings.

This object contains all of the properties of the blockchain that are fixed or that change only once per maintenance interval (daily) such as the current list of witnesses, committee_members, block interval, etc.

See for frequently changing properties.

get_dynamic_global_properties

Returns the block chain’s rapidly-changing properties. The returned object contains information that changes every block interval such as the head block number, the next witness, etc. See for less-frequently changing properties.

get_object

Returns the blockchain object corresponding to the given id.

This generic function can be used to retrieve any object from the blockchain that is assigned an ID. Certain types of objects have specialized convenience functions to return their objects e.g., assets have , accounts have , but this function will work for any object.

General Calls

help

Returns a list of all commands supported by the wallet API.

This lists each command, along with its arguments and return types. For more detailed help on a single command, use .

gethelp

Returns detailed help on a single API command.

info

Returns info about head block, chain_id, maintenance, participation, current active witnesses and committee members.

about

Returns info such as client version, git version of graphene/fc, version of boost, openssl etc.

network_add_nodes

network_get_connected_peers

Operations

Create Offer

For example

Bid

For example

Cancel Offer

For example

Calls for info

Additional Info

For examples, refer to tests/test_market_place.py

One way to pass secrets and variables securely to containers in AWS is to use Parameter Store. Navigate to the AWS Systems Manager service to get started.

Parameter Store

Create Parameter

1. Enter a name or path for the parameter.

2. Optionally add a description.

3. Select the tier to use.

4. Select the type. (we will choose SecureString.)

5. Select the KMS key source which is what will encrypt the SecureString.

6. Enter the value for the parameter.

Creating a Role and policy for ECS in IAM

In order for the containers in our Task Definition to get parameters, we need to enable KMS decrypt and SSM get parameter permissions. Navigate to IAM to get started.

Create Policy

Create a policy with permissions for KMS and SSM:

Create Role

1. Choose the service Elastic Container Service

2. Select the use case as Elastic Container Service Task

3. Attach the policy created to read secrets from Parameter Store.

4. Enter a role name.

5. Enter a role description.

Purpose

This doc describes the required changes to Bitcoin multisignature wallet scripting mechanism (previously described in Multisignature wallet LLD).

Scope

TODO

Process Overview

SONs are expected to be co-signatories for the funds stored on PW. Each SON has a public key on Bitcoin (secp256k1) and the weight of its signature.

This is executed on Bitcoin blockchain with the following script:

<pubkey1> OP_CHECKSIG

OP_IF

<voting_weight1>

OP_ELSE

0

OP_ENDIF

OP_SWAP

<pubkey2> OP_CHECKSIG

OP_IF

<voting_weight2>

OP_ADD

OP_ENDIF

...

OP_SWAP

<pubkeyN-1> OP_CHECKSIG

OP_IF

<voting_weightN-1>

OP_ADD

OP_ENDIF

OP_SWAP

<pubkeyN> OP_CHECKSIG

OP_IF

<voting_weightN>

OP_ADD

OP_ENDIF

<two_thirds_of_total_voting_weight>

OP_GREATERTHAN

The point of the script is that each SON has a weight (sum of votes for SON that is set at maintenance). Depending on the cumulative weight of votes a decision is made on whether the transfer is to be executed. For the transfer to happen the sum of weights in the script must be >= 2/3 + 1 from the number of current active SON weights.

Since the addresses depend on weights, and weights in turn depend on balances, on most occasions the deposit addresses will be re-generated after maintenance. There are two ways to handle this situation:

1. All pre-maintenance are to be considered invalid after maintenance.

2. Consider the pre-maintenance composition of SONs and their weights trusted post-maintenance. If the composition of SONs doesn't change, but their weights do, SON members are to be allowed to process the transaction in accordance with their pre-maintenance weights.

We can change the ranking upon the first transaction related to PW/SONs takes place. This is further discussed here :

Objective

This document is intended to outline generic design of withdrawal handling by Peerplays sidechain operating node. This interface will be extended to meet various other integrations.

Sidechain operating node will monitor Peerplays network for events of interest, namely transfer of Peerplays tokens to a shared SON account. When transfer happens, sidechain will process it, in order to pick up information needed to handle it. Handling withdrawals will create sidechain transaction, transferring certain amount of sidechain currency to the user who made the payment to the hared SON account. This amount will match the amount of Peerplays tokens by predefined exchange rate.

Assumptions

• Peerplays SON network is able to transfer assets on sidechain networks, in order to send assets to a user account. E.g. Peerplays SONs network has control over an multi-signature account on Bitcoin, Ethereum, EOS network which holds ballance of sidechain currency and is able to transfer them to the sidechain user accounts.

• Peerplays SON network have dedicated account on every supported sidechain. This address/account is a multi-signature account or script or smart contract, or any other entity supported by a target sidechain, which is able to send assets to users. This is the address where SON network will keep its sidechain asset ballance.

• Sidechain operating node has access to assets exchange rate list, containing exchange rates for every asset on every supported sidechain network. This list should be updateable by Peerplays network administrators.

• Sidechain operating node has access to user accounts mapping list, containing user addresses on supported sidechains. Key value in this mapping is user’s Peerplays account. E.g. [PeerplaysAccount, BitcoinAccount, EthereumAccount, …]. All sidechain accounts should be created by user (e.g. user can enter them during registration as a Peerplays user). Account creation on target sidechain should not be handled by Peerplays, because of increased risk of handling their private keys. This list should be updateable by user.

Block diagram

Link to file

Description

• The withdrawal is initiated by user, by transfering Peerplays core asset to SON shared account.

• As described in , when event of interest, transfer to a certain address on a target sidechain occurs, a sidechain handler will process it, and save the event data into Peerplays network for further processing.

• Sidechain handler will identify user depositing funds, by searching transaction’s source address in user accounts mapping list, in order to find which Peerplays network address matches sidechain transaction source address. Peerplays network will transfer assets to this address (target address).

• Sidechain handler will get the exchange rate from Exchange rate list, in order to calculate exact amount that needs to be transfered to the target address.

• SONs will synchronize between them selves, by exchanging information about new transaction on Peerplays network and information about transfer that needs to be executed on sidechain network. Once all active SONs have same information about transaction, randomly selected SON will create transaction and start singing process. Source address of this transfer will be SONs controlled account for transferring sidechain assets to users.

• When first signature is added to transaction, signed transaction will be sent through SONs network, so that other SONs can sign it. Depending on a sidechain features, at least 8 SONs needs to sign this transaction. We can also go with SONs with at least 2/3 of total weight signature, if that's supported by the sidechain. Last SON signing transaction will broadcast it to the network. Tutorial on how to use multisig in Bitshares is here:

• All sidechain specific functionalities will be implemented in sidechain handler.

• All general functionalities will be implemented in sidechain handler base class.

Sequence diagram

Link to file

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

The wallet (cli_wallet) requires a running full node to connect to because it does not offer P2P or blockchain capabilities directly.

If you have not set up your wallet yet, you can find more information here: .

Objective

This document is intended to outline generic design of a Bitcoin deposit handler, a component used for monitoring and processing deposits from a Bitcoin network.

For general information on deposit handlers, read: Generic Sidechain Deposit HLD

Asumptions

• Peerplays SON network is able to control (transfer or create) assets on Peerplays network - FULFILLED

• Peerplays SON network have full control over address/account on Bitcoin sidechain - FULFILLED (multisig addresses)

• Sidechain operating node has access to assets exchange rate list, containing exchange rates for every asset on every supported sidechain network - FULFILLED For Bitcoin, exchange rate is fixed 1 BTC = 1 PPY

• Sidechain operating node has access to user accounts mapping list, containing user addresses on supported sidechains - FULLFILLED

Block diagram

Link to draw.io file

https://drive.google.com/file/d/14HFGLqD8IV3ics1ojFcZ2xC6hRtFXLck/view?usp=sharing

Description

• Deposit process is initiated by sending BTC to a Bitcoin address which is registered as a sidechain user address for deposits

• Bitcoin listener will pick up this transaction

• Bitcoin sidechain handler will create sidechain_event_data data structure, with the information about transaction, and pass it to the sidechain_event_data_received

• sidechain_event_data_received will create a proposal for creating deposit descriptor object son_wallet_deposit_object

• When proposal is approved, object will be created, or if it is already created by another SON, it will be confirmed

• Scheduled SON will start processing withdrawals by creating Bitcoin transaction for sending funds from Bitcoin address which is registered as a sidechain user address for deposits to primary wallet (Bitcoin multisig address controlled by active SONs)

• Bitcoin transaction will be signed and sent to Bitcoin node

• User will receive Peerplays core asset matching the amount of deposited BTC

• Scheduled SON will mark son_wallet_deposit_object as processed

1. Purpose

The purpose of this document is to provide low-level design for SON Deregister proposals by a witness and how we can extend these in the future.

2. Scope

The design requirement listed in this document will be limited to the node management of SONs.

The document will also outline the way we can use the proposals related to SON management in the future.

The document will also outline the new data structures required to validate, raise and approve proposals efficiently.

The document will only outline the design from the point where a SON is down for more than N Hours ( N = 12 Currently ).

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. Graphene Proposals

All the info related to proposals can be found at https://github.com/peerplays-network/peerplays/wiki/Proposal-Mechanism

5. Deregistering SON

According to the functional requirements of SON, if a SON is down for more than 12 hours, it should be deregistered from the network.

And for this to happen a witness has to raise a proposal that removes the SON from the network.

This has to happen if and only if there is no dependency on the SON for Bitcoin side operations. But this is out of the scope of this document.

All the statistics including the timestamp for when a SON is down is stored in son_statistics_object.

So when a witness detects that for any in_maintenance SON the current_time is greater by 12 hours than its last down timestamp, a witness proposal is raised.

The proposal will have a lifetime of 3 complete witness cycles so as to allow sufficient time for approval.

A new proposal object son_proposal_object(And its indexes) is introduced to fetch the proposals that are only related to SONs faster.

These proposals can even be used by other SONs in the future for raising proposals on the network.

i.e. The proposals can be used for Bitcoin-related proposals, to notify various events on the network, etc

  A new type of operation can be created to suit the scenarios we want to handle and the operations can be put into the proposals for approval.

All the new data structures and helper functions can be found in the UML diagram below.

1. Purpose

The purpose of this document is to outline the steps required by a witness to create a proposal to refund the BTC deposited when more than 1/3rd SONs were down/inactive.

2. Scope

The design requirement listed in this document will be limited to the refund deposited BTC functionality of the SON – other coins should be handled differently if needed. This will outline the required steps that will be performed by the witness nodes to create a proposal to refund the BTC in the Peerplays blockchain. 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.

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 multisig 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 multisig 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 multisig 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. Process Overview

Described here is the design for refunding the BTC that was deposited on the Bitcoin Blockchain when more than 1/3rd SONs were inactive in the Peerplays blockchain.

5. Context

There can be a situation where more than 1/3rd of the SONs are down and a user deposits BTC to his account but it's not credited to his account. The ideal way to deal with such a situation is to create smart contracts (HTLC) to refund the BTC back to the user. In the absence of smart contracts, the below mentioned implementations have been suggested.

6. Implementations Suggested

1. This can be handled by the witness nodes. Witnesses can't sign any transaction related to BTC sidechain since that is the responsibility of the SONs but they should be able to create a proposal to refund the BTC when the SONs were down and the SONs should be able to ratify this proposal once they are online. This way, the BTC of the users who deposited it when the SONs were down won't be lost and instead refunded. This proposal can be created on-chain or manually by the witnesses. a. We just need to The implementation for a manual proposal by witnesses will be much lower than any other implementation suggested above. b. In an on-chain implementation, the witnesses will have to run a bitcoin instance on their node and the peerplays code will include a bitcoin listener (already implemented in sidechain) which will listen to the changes on the bitcoin blockchain and will keep track of SONs' inactivity. As soon as more than 1/3rd of the SONs become inactive, it will check for any deposits made to the Bitcoin wallet and create a proposal to refund it. This proposal can be signed by the SONs and the amount can be refunded.

2. During the period when more than 1/3rd of the SONs are down, the active SONs should either create the proposal for depositing pBTC to the users or to simply refund the BTC deposited by the user and when the rest of the SONs become active again, they should be able to verify it and sign the proposal. In this case, the time taken for the depositing the pBTC to the user's account may be more than 3 hours.

3. When the SONs become active after a period of inactivity, they should first check for any missed transactions on the Bitcoin blockchain and refund the BTC to the user that was deposited during the inactivity.

7. Flow Diagram

To be done on the basis of the implementation chosen.

1. Purpose

The purpose of this document is to provide the design for the commands to be added to the CLI Wallet for SONs.

2. Scope

The design requirement listed in this document will be limited to the commands to be added to the CLI Wallet. This will outline the commands required to be added and their implementation. 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.

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 multisig 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 multisig 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 multisig 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. Process Overview

Described here is the design for commands to be added to the CLI Wallet for adding/removing SON, voting for SON, etc.

5. Context

The following commands will have to be added in the CLI wallet and new APIs created for the same to allow the users to use the SON functionality:

a. create_son(string owner_account, string url, bool broadcast) This command creates a transaction to create a new SON. The parameters required are: owner_account: account name which has to be registered as an SON, url: published url where the SON has published his details and his marketing pitch and broadcast: whether to broadcast this transaction or not (default: false).

b. vote_for_son(string voting_account, string son_account, bool approve, bool broadcast) This command creates a transaction to vote for an SON. The parameters required are: voting_account: account name which is voting son_account: account name of the SON to whom the votes are being cast approve: whether the votes are being cast or withdrawn (default: false) broadcast: whether to broadcast this transaction or not (default: false)

c. get_son(string owner_account) Command to get the details of an SON. The parameters required are: owner_account: account name of the SON

d. update_son(string son_name, string url, string bitcoin_signing_key, bool broadcast) This command creates a transaction to update the SON. The parameters required are: son_name: The name of the SON to be updated url: published url where the SON has published his details and his marketing pitch to be updated bitcoin_signing_key: bitcoin transaction signing key of the SON to be updated broadcast: whether to broadcast this transaction or not (default: false)

e. update_son_votes(string voting_account, std::vector<std::string> sons_to_approve, std::vector<std::string> sons_to_reject, uint16_t desired_number_of_sons, bool broadcast) This command creates a transaction to update the votes for SONs. The parameters required are: voting_account: The account name which is voting sons_to_approve: The SONs to which the votes have to be casted sons_to_reject: The SONs from which the votes have to be removed desired_number_of_sons: The total number of SONs that the user wants to vote for broadcast: whether to broadcast this transaction or not (default: false)

f. list_sons(string& lowerbound, uint32 limit) Command to list the SONs starting from a lowerbound account id. lowerbound: The account id to start searching SONs from limit: The max number of SONs to be returned

g. claim_registered_son(const std::string& son_name) Command to save the private keys of the registered SON in the wallet permanently after the registration of SON is successful. The SON should have been created from the same CLI wallet. son_name: The name of the SON whose private keys are being saved in the wallet.

h. remove_son(string owner_account, bool broadcast) This command creates the transaction for remove_son_operation. The parameters required are: owner_account: The account name of the witness to be removed. broadcast: whether to broadcast this transaction or not (default: false)

i. list_active_sons(string& lowerbound, uint32 limit)

Command to list the SONs that are active currently.

We can use global_property_object::active_sons to retrieve the currently active SONs list.

lowerbound: The account id to start searching SONs from limit: The max number of SONs to be returned

The following commands will have to be updated in the CLI wallet and in the existing APIs to add the functionality related to SONs:

a. get_global_properties() This command returns the global properties of the blockchain such as head_block_num, head_block_id, next_maintenance_time, active_witnesses, active_committee_members, etc. This should be modified to provide the active_sons as well.

b. resync() method The resync method in the wallet.cpp file updates the wallet_data annotations e.g. wallet has been restarted and was not notified of the events while it was down.

There are two ways to create an account.

1. With Python-Peerplays: If you already have an account, it can be used to create another account.

2. With the Faucet: To create an account without an existing account.

The Python-Peerplays Method

You need a funded account to create additional accounts. The funded account should be upgraded to create new accounts. To upgrade an account

p.upgrade_account(account="account_name")

Once the account is upgraded

p.create_account(account_name="new_account_name", registrar="the_upgraded_account", owner_key='TEST6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV', active_key='TEST6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV', memo_key='TEST6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV')

The Faucet Method

url = https://mint-faucet.peerplays.download/

params = {'account': {
    'name': 'new_account_name',
    'owner_key': 'TEST6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV',
    'active_key': 'TEST6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV',
    'memo_key': 'TEST6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV',
    'refcode': '',
    'referrer': ''}}

requests.post(url, json=params)

Additional Methods

p.transfer(to, amount, asset, memo="", account=None)

Once we have created a Cluster, we can create a service inside it.

Configure Service

1. Choose a Launch Type. (In this case we will be using FARGATE).

2. Select a Task Definition and revision.

3. Select the platform version.

4. Select a cluster.

5. Create a name for the service.

6. Select the service type (in this case we will be using REPLICA).

7. Enter the number of tasks that the service should try to keep running.

8. Enter the desired value for the minimum and maximum healthy percent.

Deployments

Select either the Rolling update or Blue/green deployment.

Task Placement

Select a placement strategy from the placement templates.

Configure network

VPC and security groups

1. Select your Cluster VPC.

2. Select your desired subnets.

3. Attach security groups.

4. Attach a Load Balancer

Set Auto Scaling (optional)

Select Service Auto Scaling to set the cardinality of tasks and automatic task scaling policies.

Bitcoin Withdrawal Handling LLD

This document assumes that the multi-signature wallet is existing

Objective

This document is intended to outline generic design of a Bitcoin withdrawal handler, a component used for processing withdrawals to Bitcoin network.

For general information on deposit handlers, read: Generic Sidechain Withdrawal HLD

Asumptions

• Peerplays SON network is able to transfer assets on Bitcoin network - FULFILLED

• Peerplays SON network have dedicated account on Bitcoin sidechain - FULFILLED (multisig addresses)

• Sidechain operating node has access to assets exchange rate list, containing exchange rates for every asset on every supported sidechain network - FULFILLED For Bitcoin, exchange rate is fixed 1 BTC = 1 PPY

• Sidechain operating node has access to user accounts mapping list, containing user addresses on supported sidechains - FULLFILLED

Block diagram

Link to draw.io file

https://drive.google.com/file/d/1qSWvcxfWVEwJV2nZA-xTApTSi5rH_1uv/view?usp=sharing

Description

• Withdrawal process is initiated by sending Peerplays core asser to a SON shared account

• Peerplays listener will pick up this transaction

• Peerplays sidechain handler will create sidechain_event_data data structure, with the information about transaction, and pass it to the sidechain_event_data_received

• sidechain_event_data_received will create a proposal for creating withdrawal descriptor object - son_wallet_withdrawal_object

• When proposal is approved, object will be created, or if it is already created by another SON, it will be confirmed

• Scheduled SON will start processing withdrawals by creating Bitcoin transaction for sending funds from primary wallet (Bitcoin multisig address controlled by active SONs) to the a Bitcoin address which is registered as a sidechain user address for withdrawals

• Bitcoin transaction will be signed and sent to Bitcoin node

• Scheduled SON will mark son_wallet_withdrawal_object as processed

1. Purpose

The purpose of this document is to provide low-level design for SON Voting mechanism.

2. Scope

The design requirement listed in this document will be limited to the voting mechanism of the SON Objects.

The document will also outline the way a SON object can be voted.

The document will also outline how the votes are tallied at the maintenance interval.

The document will also outline how the top N SONs are updated during the maintenance interval.

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. Sidechain Operator Node ( SONs )

More on SON Objects can be found at SON Objects and Operators

5. How can SON be voted on

Users can vote for SONs in a similar way they vote for a witness.

A PeerPlays account updates his votes in 'account_object' via standard Graphene operation 'account_update_operation' (covered by 'account_object::account_options::num_witness' and 'account_object::account_options::votes' fields). wallet API has methods introduced for it: 'set_desired_witness_committee_son_member_count' (standard method, updated) and 'vote_for_son'.

Below is the sequence of how to vote for an SON.

6. Tallying Votes for SONs

At maintenance interval a 'vote_tally_helper::operator()' is called for each committee account on PeerPlays.

Votes for SON are added to 'database::_vote_tally_buffer', using 'vote_id' as an index from 'account_object::account_options::votes', and 'voting_stake' of the account as value.

In 'database::_son_count_histogram_buffer', using 'amount_son_members / 2' as an index, and 'voting_stake' of the account as value, the votes for a new number of top SONs are added.

Based on the above, the number of top SONs can only be odd, as during the calculation it is divided by 2, then multiplied by 2 and added + 1.

A method 'database::update_active_sons' is called to determine the actual number of top SONs (the order in which they are placed).

First, a calculation of votes for the number of top SONs is performed (step 2). 'stake_target' needs to be reached, which equals 1/2 of the 'voting_stake' (without considering the stakes of the votes for 0 SONs).

The data from 'database::_son_count_histogram_buffer' are orderly summed into a variable until it reaches 'stake_target'.

The index, at which the counting stops, will be multiplied by 2 and added + 1. The result of these operations will be the new number of top SONs.

New SONs are elected via 'database::sort_votable_objects` - a method to sort the witnesses and now SONs by the votes given to them by users.

A similar approach can be found in the witness voting tally code in perform_chain_maintenance.

Following changes have been made to the peerplaysjs-lib:

1. ChainTypes.js

   1. Add the following missing object types to the object_type constant: son: 27, son_proposal: 28, son_wallet: 29, son_wallet_deposit: 30, son_wallet_withdraw: 31, sidechain_address: 32, sidechain_transaction: 33

   2. Add the following missing implementation object types to the impl_object_type constant: son_statistics: 24, son_schedule: 25

   3. Add the following missing operations in operations constant: son_create: 82, son_update: 83, son_delete: 84, son_heartbeat: 85, son_report_down: 86, son_maintenance: 87, son_wallet_recreate: 88, son_wallet_update: 89, son_wallet_deposit_create: 90, son_wallet_deposit_process: 91, son_wallet_withdraw_create: 92, son_wallet_withdraw_process: 93, sidechain_address_add: 94, sidechain_address_update: 95, sidechain_address_delete: 96, sidechain_transaction_create: 97, sidechain_transaction_sign: 98, sidechain_transaction_send: 99, sidechain_transaction_settle: 100

2. operations.js 1. Add the following missing fee parameters:

   const son_create_operation_fee_parameters = new Serializer( 'son_create_operation_fee_parameters', { fee: uint64 } ); const son_update_operation_fee_parameters = new Serializer( 'son_update_operation_fee_parameters', { fee: uint64 } ); const son_delete_operation_fee_parameters = new Serializer( 'son_delete_operation_fee_parameters', { fee: uint64 } ); const son_heartbeat_operation_fee_parameters = new Serializer( 'son_heartbeat_operation_fee_parameters', { fee: uint64 } ); const son_report_down_operation_fee_parameters = new Serializer( 'son_report_down_operation_fee_parameters', { fee: uint64 } ); const son_maintenance_operation_fee_parameters = new Serializer( 'son_maintenance_operation_fee_parameters', { fee: uint64 } ); const son_wallet_recreate_operation_fee_parameters = new Serializer( 'son_wallet_recreate_operation_fee_parameters', { fee: uint64 } ); const son_wallet_update_operation_fee_parameters = new Serializer( 'son_wallet_update_operation_fee_parameters', { fee: uint64 } ); const son_wallet_deposit_create_operation_fee_parameters = new Serializer( 'son_wallet_deposit_create_operation_fee_parameters', { fee: uint64 } );

   const son_wallet_deposit_process_operation_fee_parameters = new Serializer( 'son_wallet_deposit_process_operation_fee_parameters', { fee: uint64 } );

   const son_wallet_withdraw_create_operation_fee_parameters = new Serializer( 'son_wallet_withdraw_create_operation_fee_parameters', { fee: uint64 } );

   const son_wallet_withdraw_process_operation_fee_parameters = new Serializer( 'son_wallet_withdraw_process_operation_fee_parameters', { fee: uint64 } ); const sidechain_address_add_operation_fee_parameters = new Serializer( 'sidechain_address_add_operation_fee_parameters', { fee: uint64 } );

   const sidechain_address_update_operation_fee_parameters = new Serializer( 'sidechain_address_update_operation_fee_parameters', { fee: uint64 } );

   const sidechain_address_delete_operation_fee_parameters = new Serializer( 'sidechain_address_delete_operation_fee_parameters', { fee: uint64 } );

   const sidechain_transaction_create_operation_fee_parameters = new Serializer( 'sidechain_transaction_create_operation_fee_parameters', { fee: uint64 } );

   const sidechain_transaction_sign_operation_fee_parameters = new Serializer( 'sidechain_transaction_sign_operation_fee_parameters', { fee: uint64 } );

   const sidechain_transaction_send_operation_fee_parameters = new Serializer( 'sidechain_transaction_send_operation_fee_parameters', { fee: uint64 } );

   const sidechain_transaction_settle_operation_fee_parameters = new Serializer( 'sidechain_transaction_settle_operation_fee_parameters', { fee: uint64 } );

   1. Add these fee parameters to the fee_parameters constant: son_create_operation_fee_parameters, son_update_operation_fee_parameters, son_delete_operation_fee_parameters, son_heartbeat_operation_fee_parameters, son_report_down_operation_fee_parameters, son_maintenance_operation_fee_parameters, son_wallet_recreate_operation_fee_parameters, son_wallet_update_operation_fee_parameters, son_wallet_deposit_create_operation_fee_parameters, son_wallet_deposit_process_operation_fee_parameters, son_wallet_withdraw_create_operation_fee_parameters, son_wallet_withdraw_process_operation_fee_parameters, sidechain_address_add_operation_fee_parameters, sidechain_address_update_operation_fee_parameters, sidechain_address_delete_operation_fee_parameters, sidechain_transaction_create_operation_fee_parameters, sidechain_transaction_sign_operation_fee_parameters, sidechain_transaction_send_operation_fee_parameters, sidechain_transaction_settle_operation_fee_parameters

   2. Add missing fields to parameter_extensions constant: gpos_period: optional(uint32), gpos_subperiod: optional(uint32), gpos_period_start: optional(uint32), gpos_vesting_lockin_period: optional(uint32), son_vesting_amount: optional(uint32), son_vesting_period: optional(uint32), son_pay_max: optional(uint32), son_pay_time: optional(uint32), son_deregister_time: optional(uint32), son_heartbeat_frequency: optional(uint32), son_down_time: optional(uint32), son_bitcoin_min_tx_confirmations: optional(uint16), son_account: optional(protocol_id_type('account')), btc_asset: optional(protocol_id_type('asset'))

   3. Add a new serializer for dormant_vesting_balance_initializer and add it to the constant vesting_policy_initializer: const dormant_vesting_policy_initializer = new Serializer('dormant_vesting_policy_initializer', {});

   4. Add 'son' to vesting_balance_type enum serializer: const vesting_balance_type = enumeration([ 'normal', 'gpos', 'son' ]);

   5. Add the following missing operation serializers: const sidechain_type = enumeration([ 'unknown', 'bitcoin', 'ethereum', 'eos', 'peerplays' ]);

      const son_create = new Serializer('son_create', { fee: asset, owner_account: protocol_id_type('account'), url: string, deposit: protocol_id_type('vesting_balance'), signing_key: public_key, sidechain_public_keys: map(sidechain_type, string), pay_vb: protocol_id_type('vesting_balance') });

      const son_update = new Serializer('son_update', { fee: asset, son_id: protocol_id_type('son'), owner_account: protocol_id_type('account'), new_url: optional(string), new_deposit: optional(protocol_id_type('vesting_balance')), new_signing_key: optional(public_key), new_sidechain_public_keys: optional(map(sidechain_type, string)), new_pay_vb: optional(protocol_id_type('vesting_balance')) });

      const son_delete = new Serializer('son_delete', { fee: asset, son_id: protocol_id_type('son'), payer: protocol_id_type('account'), owner_account: protocol_id_type('account') });

      const son_heartbeat = new Serializer('son_heartbeat', { fee: asset, son_id: protocol_id_type('son'), owner_account: protocol_id_type('account'), ts: time_point_sec });

      const son_report_down = new Serializer('son_report_down', { fee: asset, son_id: protocol_id_type('son'), payer: protocol_id_type('account'), down_ts: time_point_sec });

      const son_maintenance_request_type = enumeration([ 'request_maintenance', 'cancel_request_maintenance' ]);

      const son_maintenance = new Serializer('son_maintenance', { fee: asset, son_id: protocol_id_type('son'), owner_account: protocol_id_type('account'), request_type: son_maintenance_request_type });

      const son_info = new Serializer('son_info', { son_id: protocol_id_type('son'), weight: uint16, signing_key: public_key, sidechain_public_keys: map(sidechain_type, string) });

      const son_wallet_recreate = new Serializer('son_wallet_recreate', { fee: asset, payer: protocol_id_type('account'), sons: set(son_info) });

      const son_wallet_update = new Serializer('son_wallet_update', { fee: asset, payer: protocol_id_type('account'), son_wallet_id: protocol_id_type('son_wallet'), sidechain: sidechain_type, address: string });

      const son_wallet_deposit_create = new Serializer('son_wallet_deposit_create', { fee: asset, payer: protocol_id_type('account'), son_id: protocol_id_type('son'), timestamp: time_point_sec, block_num: uint32, sidechain: sidechain_type, sidechain_uid: string, sidechain_transaction_id: string, sidechain_from: string, sidechain_to: string, sidechain_currency: string, sidechain_amount: int64, peerplays_from: protocol_id_type('account'), peerplays_to: protocol_id_type('account'), peerplays_asset: asset });

      const son_wallet_deposit_process = new Serializer('son_wallet_deposit_process', { fee: asset, payer: protocol_id_type('account'), son_wallet_deposit_id: protocol_id_type('son_wallet_deposit') });

      const son_wallet_withdraw_create = new Serializer('son_wallet_withdraw_create', { fee: asset, payer: protocol_id_type('account'), son_id: protocol_id_type('son'), timestamp: time_point_sec, block_num: uint32, sidechain: sidechain_type, peerplays_uid: string, peerplays_transaction_id: string, peerplays_from: protocol_id_type('account'), peerplays_asset: asset, withdraw_sidechain: sidechain_type, withdraw_address: string, withdraw_currency: string, withdraw_amount: int64 });

      const son_wallet_withdraw_process = new Serializer('son_wallet_withdraw_process', { fee: asset, payer: protocol_id_type('account'), son_wallet_withdraw_id: protocol_id_type('son_wallet_withdraw') });

      const sidechain_address_add = new Serializer('sidechain_address_add', { fee: asset, payer: protocol_id_type('account'), sidechain_address_account: protocol_id_type('account'), sidechain: sidechain_type, deposit_public_key: string, deposit_address: string, deposit_address_data: string, withdraw_public_key: string, withdraw_address: string });

      const sidechain_address_update = new Serializer('sidechain_address_update', { fee: asset, payer: protocol_id_type('account'), sidechain_address_id: protocol_id_type('sidechain_address'), sidechain_address_account: protocol_id_type('account'), sidechain: sidechain_type, deposit_public_key: optional(string), deposit_address: optional(string), deposit_address_data: optional(string), withdraw_public_key: optional(string), withdraw_address: optional(string) });

      const sidechain_address_delete = new Serializer('sidechain_address_delete', { fee: asset, payer: protocol_id_type('account'), sidechain_address_id: protocol_id_type('sidechain_address'), sidechain_address_account: protocol_id_type('account'), sidechain: sidechain_type });

      const sidechain_transaction_create = new Serializer('sidechain_transaction_create', { fee: asset, payer: protocol_id_type('account'), sidechain: sidechain_type, object_id: protocol_id_type('object'), transaction: string, signers: set(son_info) });

      const sidechain_transaction_sign = new Serializer('sidechain_transaction_sign', { fee: asset, signer: protocol_id_type('son'), payer: protocol_id_type('account'), sidechain_transaction_id: protocol_id_type('sidechain_transaction'), signature: string });

      const sidechain_transaction_send = new Serializer('sidechain_transaction_send', { fee: asset, payer: protocol_id_type('account'), sidechain_transaction_id: protocol_id_type('sidechain_transaction'), signature: string });

      const sidechain_transaction_settle = new Serializer('sidechain_transaction_settle', { fee: asset, payer: protocol_id_type('account'), sidechain_transaction_id: protocol_id_type('sidechain_transaction') });

   6. Add the missing operations in st_operations: son_create, son_update, son_delete, son_heartbeat, son_report_down, son_maintenance, son_wallet_recreate, son_wallet_update, son_wallet_deposit_create, son_wallet_deposit_process, son_wallet_withdraw_create, son_wallet_withdraw_process, sidechain_address_add, sidechain_address_update, sidechain_address_delete, sidechain_transaction_create, sidechain_transaction_sign, sidechain_transaction_send, sidechain_transaction_settle

Operations

Create NFT Meta

For example

Update NFT Meta

For example

Mint NFT

For example

Transfer NFT

For example

Approve Control over NFT

For example

Approve for all the tokens owned

For example

Info calls

p.rpc.nft_get_balance(owner)

p.rpc.nft_owner_of(token_id)

p.rpc.nft_get_approved(token_id)

p.rpc.nft_is_approved_for_all(owner, operator)

p.rpc.nft_get_name(nft_metadata_id)

p.rpc.nft_get_symbol(nft_metadata_id)

p.rpc.nft_get_token_uri(token_id)

p.rpc.nft_get_total_supply(nft_metadata_id)

p.rpc.nft_token_by_index(nft_metadata_id, token_idx)

p.rpc.nft_token_of_owner_by_index(nft_metadata_id, owner, token_idx)

p.rpc.nft_get_all_tokens()

p.rpc.nft_get_tokens_by_owner(owner)

Additional Info

For examples, refer to tests/test_nft.py

This article will be referencing the following repositories as the Docker image codebase:

In ECS, create a new Task Definition and choose the desired launch type compatibility (Fargate or EC2)

Attach the Task Role

Attach the task role created from .

Attach the Task Execution Role

This role is required by tasks to pull container images and publish container logs to Amazon CloudWatch on your behalf. You can use the default one created by Amazon.

Adjust the Task Size

We can assign total memory and CPU to the task. For PeerID, choose:

• 2GB Task Memory (GB)

• 1 vCPU Task CPU (vCPU)

Adding the Containers

Create two containers:

• PeerID Backend

• PeerID Frontend + Webserver (we will be using NGINX)

PeerID Backend

1. Enter the container name.

2. Enter the path to the Docker registry with the container Image.

3. Enter 1024 for a soft limit for the memory.

4. Enter 3000 tcp for the port mappings.

5. Enter 756 CPU units.

6. Tick the essential box.

7. Enter /peerid-backend/docker-entrypoint.sh for the entry point.

8. Enter npm,run,start for the command.

9. Enter peerid-backend for the working directory.

10. Enter the environment variables for PeerID Backend using ValueFrom and referencing the parameters from Systems Manager Parameter Store.

PeerID Frontend

1. Enter the container name.

2. Enter the path to the Docker registry with the container Image.

3. Enter 256 for a soft limit for the memory.

4. Enter 80 and 443 tcp for the port mappings.

5. Enter 256 CPU units.

6. Tick the essential box.

7. Enter /docker-entrypoint.sh for the entry point.

8. Enter nginx,-g,daemon off; for the command.

9. Enter the environment variables for PeerID GUI using ValueFrom and referencing the values created from Systems Manager Parameter Store.

Get a random number

TypeDefs

Declaration

Examples

Initialization in constructor

Updating seed on a new block

Getting a new random number

The history API is available from the full node via websockets.

Account History

get_account_history

Get operations relevant to the specified account.

vector<operation_history_object> graphene::app::history_api::get_account_history(
    const std::string account_id_or_name, 
    operation_history_id_type stop = operation_history_id_type(), 
    unsigned limit = 100, 
    operation_history_id_type start = operation_history_id_type())const

get_account_history_operations

Get only asked operations relevant to the specified account.

vector<operation_history_object> graphene::app::history_api::get_account_history_operations(
    const std::string account_id_or_name, 
    int operation_type, 
    operation_history_id_type start = operation_history_id_type(), 
    operation_history_id_type stop = operation_history_id_type(), 
    unsigned limit = 100)const

get_relative_account_history

Get operations relevant to the specified account referenced by an event numbering specific to the account. The current number of operations for the account can be found in the account statistics (or use 0 for start).

vector<operation_history_object> graphene::app::history_api::get_relative_account_history(
    const std::string account_id_or_name, 
    uint64_t stop = 0, 
    unsigned limit = 100, 
    uint64_t start = 0)const

Market History

get_fill_order_history

Get details of order executions occurred most recently in a trading pair.

vector<order_history_object> graphene::app::history_api::get_fill_order_history(
    std::string a, 
    std::string b, 
    uint32_t limit)const

get_market_history

Get OHLCV data of a trading pair in a time range.

vector<bucket_object> graphene::app::history_api::get_market_history(
    std::string a, 
    std::string b, 
    uint32_t bucket_seconds, 
    fc::time_point_sec start, 
    fc::time_point_sec end)const

get_market_history_buckets

Get OHLCV time bucket lengths supported (configured) by this API server.

flat_set<uint32_t> graphene::app::history_api::get_market_history_buckets()const

Operations

Create Custom Permission

p.custom_permission_create(
    permission_name,
    owner_account=None,
    weight_threshold=[],
    account_auths=[],
    key_auths=[],
    address_auths=[],
    )

For example

    p.custom_permission_create(
        testperm1,
        owner_account="1.2.7",
        weight_threshold=1,
        account_auths=[["1.2.8", 1]])

Custom Permission Update

p.custom_permission_update(
    permission_id,
    owner_account=None,
    weight_threshold=[],
    account_auths=[],
    key_auths=[],
    address_auths=[],
    )

For example

            p.custom_permission_update(
                    permission_id,
                    weight_threshold=1,
                    account_auths=[["1.2.9", 2]],
                    owner_account="1.2.7"
            )

Custom Permission Delete

p.custom_permission_delete(
    permission_id,
    owner_account=None,
    )

For example

            p.custom_permission_delete(
                    permission_id,
                    owner_account="1.2.7"
            )

Custom Account Authority Create

p.custom_account_authority_create(
    permission_id,
    operation_type,
    valid_from,
    valid_to,
    owner_account=None,
    )

For example

p.custom_account_authority_create(
                    permission_id,
                    0,
                    "2020-07-27T00:00:00",
                    "2030-07-27T00:00:00",
                    owner_account="1.2.7")

Custom Account Authority Update

p.custom_account_authority_update(
    auth_id,
    new_valid_from,
    new_valid_to,
    owner_account=None,
    )

For example

p.custom_account_authority_update(
            authority_id,
            "2020-07-27T00:00:00",
            "2040-07-27T00:00:00",
            owner_account="1.2.7")

Custom Account Authority Delete

p.custom_account_authority_delete(
    auth_id,
    owner_account=None,
    )

For example

    p.custom_account_authority_delete(
            authority_id,
            owner_account="1.2.7")

RPC Info calls

get_custom_permissions(account)
get_custom_permission_by_name(account, permission_name)
get_custom_account_authorities(account)
get_custom_account_authorities_by_permission_id(permission_id)
get_custom_account_authorities_by_permission_name(account, permission_name)
get_active_custom_account_authorities_by_operation(account, int operation_type)

Introduction

The Peerplays blockchain RNG was initially added to the blockchain to provide draw features for the Easy5050 decentralized application (DApp).

The first release of the RNG was localized to the Easy5050 DApp and wasn't exposing the number generated via an API, or a similar mechanism, such that other DApps or users could consume them.

For the second release of the RNG the functionality was extended to become a general RNG, with a public API, for supporting games such as Slots, Poker, Roulette, Raffle, Bingo, Keno, etc.

How the Random Numbers are Generated

Random numbers are generated from secret hashes taken from the previous and current block, which are then combined into a single data stream and encoded using the ripemd160 algorithm, and finally fed into a random number generator as a seed.

Block-Hash Randomness

In this approach, the hash of blocks or transactions is used as the source of randomness. As the hash is deterministic, everyone will get the same result. A block, once added to the blockchain, is likely to stay there forever, therefore everyone can verify the correctness of the generated numbers.

Consider an example of a lottery service that adopts this method. The players first buy a ticket by placing their number before a specific time, say 7PM everyday. After 8PM, the buying ticket phase is closed, the protocol proceeds to the next phase which is to determine the winning numbers for a ticket. This ticket is calculated based on the hash of the first block accessible for everyone on the blockchain after 8PM.

As we can see, at 7PM, no one can predict the hash of block at 8PM which makes the service seemingly a sound one. However, this hash is subject to manipulation by the block-signers of the blockchain. When the reward of the lottery is small, the block-signers have little motivation to tamper with the block, but as soon as this amount is larger than the block reward plus the transaction fees, there is a chance that witnesses will start influencing the block-hash to generate their desired numbers.

So on it's own a block-hash level of randomness is not enough. This is why the Peerplays RNG extends the block-hash mechanism by using the hash as a seed for randomization along with the repemd160 algorithm and Secure Hash Algorithm (SHA).

Distributed Ledger Technology (DLT)

Peerplays, and other blockchains, are one type of a distributed ledger. Distributed ledgers use independent computers (referred to as nodes) to record, share and synchronize transactions in their respective electronic ledgers (instead of keeping data centralized as in a traditional ledger).

The immutability of DLT is critical for the RNG because it ensures that once a random number is generated it is authentic and can't be changed.

Witness Randomness

Peerplays is based on the Delegated Proof of Stake (DPOS) consensus mechanism, which means that the block signers (Witnesses) are all elected by the token holders. This is important from an RNG perspective because it requires loyalty, commitment and honesty to get voted in as a Witness. Since a component of the randomness is based on the block hash, knowing that the block signers are a trusted, elected, group greatly mitigates the risk of block tampering.

Peerplays further extends the block-signing robustness and randomness because:

1. Not all Witnesses are block-signing (active) Witnesses. There is a second level of consensus that has to happen before a Witness is promoted to an active Witness.

2. Not all active Witnesses are signing blocks at any given time. The blockchain randomly selects which Witnesses are signing at ten minute intervals.

Because of the role of the Witnesses, Peerplays has two levels of randomness. First the Witnesses themselves are randomly selected, and secondly the randomness of the number generation itself.

Testing

For testing the RNG, the “Dieharder” random number generator testing suite was used.

Dieharder is intended to test generators, not files of possibly random numbers as the latter is based on the mistaken view of what it means to be random. Perfect random number generators produce "unlikely" sequences of random numbers -- at exactly the right average rate. Testing an RNG is therefore quite subtle.

Dieharder is a tool designed to push a weak generator to unambiguous failure.

Install prerequisites for running RNG tests

sudo apt install dieharder

To run RNG test suite, use the following command:

$ ./tests/random_test

Gaming Laboratories International (GLI)

GLI are an internationally recognized institute offering the the most experienced and robust RNG testing methodologies in the world. This includes software-based (pseudo-algorithmic) RNG’s, hardware RNG’s, and hybrid combinations of both.

The Peerplays RNG has been submitted to GLI for approval [TBD: or has 'been approved']

GLI generally performs the testing of applications and games, such as Keno, as opposed to an API. The game testing will automatically include the backend API as well. On successful completion of all tests each application will be certified by GLI.

For each new game, different testing will be required. An example would be the Easy5050 DApp that can be tested and with all subsequent releases, tested again.

However, as the core Peerplays RNG is a blockchain (back-end) implementation and not an application it can only be approved by GLI rather than certified.

API

The RNG has a very simple API for generating random numbers, requiring just a single API call to get_random_bits(bound) ; supplying an upper bound.

get_random_bits(uint64_t bound)

For more information on the API see the RNG API.

1. The Concept

Peerplays communities come in all shapes and sizes. Sometimes a community will need some specialized work to be done to accomplish the vision of the community. The Peerplays network covers some basic functions for everyone like, sidechain transfers, random number generation, asset exchanges, etc. But what if a community needs something else?

One example would be a community for book publishing. This community needs several specialized workers: file encoding, file storage, content verifiers, and Content Delivery Network (CDN) gateways to name a few. None of these are covered by Peerplays directly. But we can create a system which will incentivize community members to complete this work in a decentralized way.

2. The Plan

2.1. Components

This concept will make use of some Peerplays components:

• Service Infrastructure Pools

• NFTs

• Custom Permissions

• User Issued Assets

This concept will also need some development for its custom components. These would be created by you, the dapp developer:

• Worker Node Software

• Decentralized User Interface

2.2. Putting it together

As the creator of the Peerplays community, you can use the components available to you to build a new system. The system can be simple or complex to best fit the needs of the community.

In this example system:

1. Community members enjoy the books available within and written by the community. The members purchase a specific community token (LIBRARY, for example) directly from the community. The profit from these sales is fed to the Service Infrastructure Pool.

2. The members then stake the LIBRARY tokens to receive community NFTs. The NFTs allow community governance voting and generate another community token (BOOK, for example) as rewards to the members over time.

3. Now a content creator (an author) needs the services of a community worker node. The author needs to pay the worker with BOOK token. So the author buys BOOK from the exchange and uses it to publish a book via the worker nodes.

4. BOOK is in high demand because it's also used by the members to check-out books for a limited time. So the workers can sell the BOOK in the exchange for profit.

The system so far is of a medium complexity and could satisfy the needs of the community. It's possible to add a little more to introduce some competition and buy-in among the worker nodes while also making the BOOK token deflationary.

• The workers can stake the BOOK token to receive a special worker NFT. This NFT provides the worker with "work power" which diminishes over time. The work power determines the amount of BOOK a worker is paid for performing a job as well as their priority for receiving jobs.

The Peerplays network makes many things possible. With imagination and will-power, you can create systems like this to realize your vision.

3. Related Documents

The components listed in this guide will cost transaction fees. To calculate how much PPY you'll need to make these transactions and meet your development goals, please see the Calculating Costs guide.

Comparison between scenarios for handling deposits and withdrawals

Intro

The purpose of deposit handling is to detect cryptocurrency payment from Peerplays user (currently only Bitcoin), and issue matching amount of Peerplays assets (pBTC) on Peerplays network, which user can use in games.

The purpose of withdrawal handling is to do the same thing in reverse - user will initiate withdrawal process, system will exchange his Perplays assets (pBTC) for the matching amount of cryptocurrency, and send this amount to user’s account.

In this document, I will describe scenarios we are considering, and present the main differences between them. There are features common to all scenarios (like user address mappings and sidechain manager features, verifying transaction validity reported by different SONs...), and I will consider them to be out of the scope of this document.

Scenarios

At this moment we are considering three possible approaches:

• S1: Multisignature primary wallet controlled by SON network, holding all the funds. All transfers are made to and from this multisignature wallet.

• S2: Proxy account, created by Peerplays network, paired with multisignature primary wallet controlled by SON network. On deposit, user sends funds to proxy account and funds are moved from proxy account to a primary wallet. On withdrawal, user initiates withdrawal process and funds are moved from primary wallet to proxy account or to another account belonging to the user. There is no clear suggestion on the approach. This is existing sidechain design, implemented in feature_sidechain branch.

• S3: 3 of 3 multisig wallet, controlled by blockchain network, SON network and user, paired with temporary primary wallet controlled by SON network. On deposit, user sends funds to 3 of 3 wallet, funds are staying in 3 of 3 wallet, wallets are periodically rebalanced to match the balance between 3 of 3 wallet and Peerplays pBTC, and funds are moving between 3 of 3 accounts and temporary primary wallet. On withdrawal, user initiates withdrawal process, selects one of three withdrawal scenarios, and once the withdrawal is executed, funds will be moved from temporary primary wallet to 3 of 3 wallet or to another account belonging to the user. There is no clear suggestion on the approach. This is Jonathans proposal.

General description of deposit process

• User send’s cryptocurrency to some address controlled by Peerplays. Depending on what's behind this address, we will need more or less work for implementation and maintaining it during system usage. Current suggestions are:

  • S1: User sends funds to a primary wallet, holding all the funds, and controlled by SON network.

  • S2: User sends funds to a user’s single signature proxy account, created by Peerplays network. Network will pull the funds from proxy account to primary wallet controlled by SON network, when applicable.

  • S3: User sends funds to a 3 of 3 wallet, where signers are Blockchain network, SON network and user.

• SON network monitors this address for transfers, and when transfer is detected, it will initiate a process of issuing pBTC.

  • S1: SON network monitors address of primary wallet. When transfer is detected, the system will identify user who made the payment and issue pBTC to user’s Peerplays address.

  • S2: SON network monitors address of users’s single signature proxy account. When transfer is detected, funds will be moved from proxy account to primary wallet, system will identify user who made the payment, and issue pBTC to user’s Peerplays address.

  • S3: SON network monitors address of 3 of 3 wallet. When transfer is detected, funds will stay locked in 3 of 3 wallet, system will identify user who made the payment, and issue pBTC to user’s Peerplays address.

• Once the pBTC is issued, user will not be able to freely handle the crypto-currency he initially paid. Current suggestions are:

  • S1: Funds are moved to Primary wallet controlled by network.

  • S2: Funds are moved from proxy account to Primary wallet account

  • S3: Funds stay in a 3 of 3 wallet, and in order to move them, three signatures are required

General description of withdrawal process

• User initiate withdrawal process. Depending on how the user will initiate withdrawal process we we will need more or less work for implementation and maintaining it during system usage. Current suggestions are:

  • S1: No clear suggestion on this. However, it can be started by initiating transfer from user’s peerplays account to a primary wallet controlled by SON network in Peerplays network.

  • S2: No clear suggestion on this. However, it can be started by initiating transfer from user’s peerplays account to a primary wallet controlled by SON network in Peerplays network.

  • S3: User can select one of three withdrawal methods, instant, standard and econo. The difference between these three is the price the user will pay for withdrawal, and the amount of time needed for withdrawal to be processed. If user pays higher price, withdrawal will be processed faster.

• When SON network receive withdrawal process request, it needs to identify user who initiated a request, and send funds to his account. In current scenario, we only handle BTC. In the future, when we support more blockchain networks, we also need to identify the network where we will send crypto-currency (e.g. if user made his paymetn from BTC and ETH network, we can allow him to choose whether he will be paid in BTC or ETH). However, we will also need a way to prevent user to use Peerplays network as an exchange office, in order to speculate with exchange rates, and pull more funds from the system, without actually using the Peerplays network for gaming.

  • S1: No clear suggestion on this, but we can send funds to a user account on target sidechain registered in the system.

  • S2: No clear suggestion on this, but we can send funds to a user account on target sidechain registered in the system, or to a user’s proxy account used for initial payment.

  • S3: Funds will be sent to 3 of 3 wallet during rebalance. However, user still needs 3 signatures to withdraw his funds from 3 of 3 to his personal account. There is no clear suggestion on how this will be done.

Problems on active SONs set change

Various problems may occur when we are using multi signature wallets controlled by SONs network, and active SONs set changes. Multisignature wallet is not updateable - we can’t update the list of signatures required for using funds from multisignature wallet. When active SONs set changes, multisignature wallets created by previous active SONs set may become unusable (because previous SONs holding ⅔ weight are not available anymore), rendering funds unavailable. To prevent this, the general approach is to recreate the multi signature wallets, and move all the funds from the old one to the new one. For some blockchain, like Ethereum, this problem may be easily solved by using smart contracts, and no recreation will be needed. However, since our current target is Bitcoin, the app

• S1: Primary wallet needs to be recreated and funds moved from old wallet to the new one.

• S2: Primary wallet needs to be recreated and funds moved from old wallet to the new one.

• S3: All 3 of 3 wallets, and temporary primary wallet needs to be recreated and funds moved from old wallets to the new ones. User interaction with the system might be needed for some of these actions.

Rebalancing

• S1: Rebalancing is not needed.

• S2: Rebalancing is not needed.

• S3: All 3 of 3 are periodically rebalanced to match the balance of pBTC in Peerplays network. Rebalance can be optimized by addressing only accounts that actually needs rebalancing, and transferring only differences that are needed to match the BTC and pBTC balances.

Comparison

• S1: This design is a kind of “lowest common denominator” approach, that will offer functional system, with lowest costs (single transaction for deposit, and single transaction for withdrawal), it is easiest to implement and most flexible to add changes later. It is easier to convert S1 into S2 or S3 than S2 into S3 or S3 into S2, or any other way around. The main problem with this design is PW recreation and moving funds from old to the new one, and the fact that PW will hold all Bitcoins in the network, which can make him target for hackers in the future, when it may hold enough value for somebody to go for it.

• S2 is very similar to S1 in all terms, but it is not clear why do we need the proxy account. It increases cost (one transaction for user account to proxy and one transaction for proxy to PW for deposit, and one transaction for PW to proxy and one transaction for proxy to user account for withdrawal). The main problem with this design is PW recreation and moving funds from old to the new one, and the fact that PW will hold all Bitcoins in the network, which can make him target for hackers in the future, when it may hold enough value for somebody to go for it. Another problem is increased costs of system usage, because of using proxy accounts.

• S3: By far the most complex design, advertised as “no primary wallet needed”, but from the discussion we had, we actually do need it for rebalancing and for holding the surplus of assets that are not distributed to 3 of 3 wallets during rebalancing. Temporary or not, multisig wallet controlled by SON network is there, and it needs handling. User interactions with the system in order to allow pulling funds from 3 of 3 wallet to temporary primary wallet (for handling "half signed" PUAT and PUST transactions) is problematic from the point of getting funds earned by Peerplays network, as user does not have clear motivation to sign any of these (e.g. user’s pBTCs are all spent, so why would user care did Peerplays pulled the BTC from his account or not). The good side of this design is that PW will not hold all assets, only part of them, while the other part will be distributed in user’s 3 of 3 wallets.

Recommendation

In order to unblock development, I recommend that we go with S1, since it will enable us to get the functionality we need with the least effort and shortest time. With S1 as a starting point, we will implement all common features for all three designs (son communication, multisig wallet recreation, moving funds, signing transactions, user address mappings, sidechain manager functionalities, etc…) and once we have S1 done, we can tweak it to any other scenario.

1. Purpose

The purpose of this document is to provide low-level design for making payments to SONs for their contribution to the Peerplays network.

2. Scope

The design requirement listed in this document will be limited to the payments to SON Nodes.

The document will also outline the way we pay witnesses currently in our network.

The document will also outline the new chain parameters required to configure the payments to SONs dynamically.

The document will also outline the new data structures required to identify the transactions that a SON participated in.

All the terminology used in the document is generic and will not be specific to any particular cryptocurrency like BTC or ETH.

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. Types of transactions

4.1 Transfer cryptocurrency(i.e. like BTC, ETH) from Deposit Address to PW Address

In this case, SONs have to sign the transaction to be successful.

So a reward should be made to SONs in this case.

Miner fee for the external chain is also required but it is out of the scope of this document.

4.2 Transfer cryptocurrency from Old PW Address to New PW Address

In this case, SONs have to sign the transaction to be successful.

So a reward should be made to SONs in this case.

Miner fee for the external chain is also required but it is out of the scope of this document.

4.3 Transfer UIA (User Issued Asset Eg. pBTC) from one account to another

In this case, there is no need for a SON to sign for the transaction to be successful.

This is a normal on-chain transaction. This has been supported in all the graphene-based chains for long.

So no reward is required in this case. But a witness fee is applicable as in the case of core asset transfer.

5. How it all works currently

5.1 How are witnesses paid

Currently whenever a new block is generated by a particular witness, we immediately deposit the amount into the vesting balance of the witness account.

The amount comes from the witness_budget allocated globally during the previous maintenance interval.

This is stored in dynamic_global_property_object of the blockchain for faster access.

5.2 How fee is collected

For every operation, there is a rate specified that goes as the fee to the network.

For core asset transaction, the fee is directly deducted from payer's account.

For the UIA asset transaction, the fee is converted to the core using the base exchange rate of the UIA.

Between two maintenance intervals, the core fee is accumulated in the core asset's asset_dynamic_data_object.

5.3 How is budget calculated currently

At the end of each maintenance, we calculate the budget for the coming cycle.

Some of the parameters we take into consideration are witness_budget, worker_budget, core_accumulated_fee, leftover_witness_budget etc.

A simple equation to arrive at the final budget (current_supply) is,

current_supply = current_supply + (required_witness_budget + required_worker_budget - leftover_worker_funds - core_accumulated_fee - leftover_witness_budget)

reserve_supply = max_supply - current_supply

At the end of every maintenance, the above parameters are updated in the databases.

6. Proposed Design Change for SONs

One of the requirements for the SONs is to pay the SON accounts proportional to the number of transactions they participate in.

So there is a need to know the number of transactions a particular SON object has participated in from the last payout period till now.

There is also a requirement to pay SONS_DAILY_MAX_REWARD to set of SONs operating in the network.

And this should be configurable so that in future if we have to add more SONs to handle transactions from other cryptocurrencies, we need more daily rewards or vice-versa.

As can be seen in the previous section as to how the budget is calculated, how the core amount is pooled in from the reserve, we can follow a similar approach for SONs as well.

With SONs budget factored into the budget calculations, our new equation would be,

current_supply = current_supply + (required_witness_budget + required_worker_budget + required_son_budget - leftover_worker_funds - core_accumulated_fee - leftover_witness_budget - leftover_son_budget)

reserve_supply = max_supply - current_supply

required_witness_budget ==> required witness budget till next maintenance interval

required_worker_budget ==> required worker budget till next maintenance interval

required_son_budget ==> reserved SON budget to be paid out in the next maintenance interval = (chain_parameters.son_pay_max)

leftover_worker_funds ==> Remaining funds from previous worker payout

core_accumulated_fee ==> Accumulated fee (after all the cuts removed from it), since the last maintenance interval.

leftover_witness_budget ==> Leftover funds from previous witness budget ( happens if any block is missed in between )

leftover_son_budget ==> Leftover funds from previous son budget ( happens if there are no SON transactions on the network )

For us to efficiently find the number of transactions a SON has signed, we need a new implementation_id object that complements our proposed son_object.

We store the transaction linked list that the SON has participated in and the number of transactions since the last payout.

This way during maintenance we can calculate payouts faster for each SON.

A new chain parameter to change the max daily rewards is also required.

6.1 parameter_extension.son_pay_daily_max

This parameter is used to specify the current son max payout.

It can be re-configured by committee_member_update_global_parameters_operation.

6.2 dynamic_global_property_object.son_budget

This parameter is used to denote the son_budget till next payout interval.

This is set every payout interval.

6.3 son_statistics_object

This new class is an implementation type object.

It stores the data which is changed frequently and better to separate it from the SON object.

It has data about the transactions and number of pending since last payout.

6.4 pay_sons

This function should be introduced and called from perform_chain_maintenance.

After this new budget should be recorded and saved.

1. Purpose

The purpose of this document is to provide low-level design for the process of claiming the initial vesting amount to become SON on PPY Blockchain.

2. Scope

The design requirement listed in this document will be limited to the de-registration of SON Node from active SONs and claiming the initial vesting amount by a user.

The document will also outline the function flow for how de-registration of SON node happens.

The document will also outline the new chain parameters required to configure the initial vesting amount and vesting period duration after de-registration happens.

The document will also outline the new data structures required to control the user from claiming the initial vesting amount before the vesting period duration expires.

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. Current Vesting scenario for GPOS

As proposed and implemented in GPOS, user can vest a certain amount to,

1. Participate in voting for proposals.

2. To earn a part of commissions for transactions.

The vesting period is currently 6 months and it is divided into sub-periods of 1 month.

At the end of every sub-period, a parameter called Vesting Factor (typically between 0 to 1) is calculated based on user participation.

The Vesting Factor decreases if a user doesn't participate in any voting activity for the preceding sub-period.

Users can retain their starting Vesting Factor of 1 if they continue to participate in voting in every sub-period.

And commissions are paid out proportional to the Vesting factor.

Any commission which is not paid to users because of their inactivity is transferred into a separate account which can be used further.

5. Vesting Requirement for SON

As proposed in the Functional specification of SON, a user who wants to become an SON should vest a certain amount (50 PPY) in a separate account.

The vested amount would be locked indefinitely until 2 days after the SON is deregistered on the network.

The vesting amount doesn't change and rewards are paid into liquid/normal account of the user.

6. Perceived Challenges for implementing Vesting for SON

As seen above for GPOS, at the time of the creation of Vesting Account a vesting period of at least one sub-period can be set to prevent users from withdrawing the vesting amount.

So when a user tries to withdraw his vesting amount, a vesting policy which was initialized during the creation of the vesting account can be used to decline the withdrawal.

However in SON Vesting at the time of creation, we can't initialize a policy with a particular duration that can decline user withdrawals.

A policy cannot be initialized at the time of Vesting account creation because the vesting period depends on the time of deregistration of SON.

7. Current list of Vesting policies

Currently, there are two types of vesting policies are in place,

7.1 linear_vesting_policy

This vesting policy is used to mimic traditional stock vesting contracts where each day a certain amount vests until it is fully matured.

No amount can be withdrawn before a certain number of cliff seconds have elapsed.

7.2 cdd_vesting_policy

This policy defines vesting in terms of coin-days accrued which allows for dynamic deposit/withdraw.

The economic effect of this vesting policy is to require a certain amount of interest to accrue before the full balance may be withdrawn.

Interest accrues as coin days = (balance * length_held). If some of the balance is withdrawn, the remaining balance must be held longer.

8. Proposed ways of de-registering SON

An SON can be deregistered in two ways according to the functional requirements,

1. remove_son called for SON in any state by the user from the wallet.

2. If an active SON is in maintenance for more than 12 hours.

9. Design changes suggested

9.1 son_vesting_amount

This is the minimum amount that should be vested in order to become an SON.

Currently, this is proposed to be 50 PPY.

This parameter can be changed through committee_member_update_global_parameters_operation.

9.2 son_vesting_period

This is the minimum vesting duration a user has to wait from the time an SON is considered to be deregistered.

Currently, this is proposed to be 2 days ( 2 * 86400 seconds).

This parameter can be changed through committee_member_update_global_parameters_operation.

9.3 vesting_balance_type

A new vesting_balance_type son is introduced like the one similar to gpos.

This helps in identifying the type of vesting amount.

9.4 dormant_vesting_policy<linear_vesting_policy>

This new policy just acts a wrapper around the existing policies.

As mentioned above the challenge in implementing the son vesting is that exact vesting duration is not known at the time of the creation of vesting_balance_object.

Till the point, an SON is considered as deregistered this policy would be in dormant mode and declines any vesting withdrawals initiated by the user.

Once an SON is marked as deregistered, the policy comes out of dormant mode and vesting duration is set to 2 days from deregistration.

From then on policy would just act as linear_vesting_policy.

9.5 update_active_sons

This function is introduced into the database class to handle the task of picking top N SONs at maintenance interval.

This also performs the task of deregistering the SON and activating the new dormant policy residing inside son_object.

9.6 son_status

This enum holds the state of an SON.

active - An SON user account selected among the top N SONs. ( N = 15 proposed currently ).

inactive - An SON who is idle and not actively performing the duties of maintaining the sidechain operations of another smart coin.

maintenance - An SON has gone down for maintenance but not deregistered yet.

9.7 create_vesting_balance

Argument is_gpos needs to be changed to either a string or an enum to cater to the new requirements of son vesting balance type.

10. UML and Sequence Diagrams

11. Scenarios to consider

11.1 SON gone down into maintenance mode and user issues remove_son

remove_son takes precedence and the node is deregistered at the next maintenance interval.

The new dormant vesting policy is activated.

11.2 remove_son followed by create_vesting_balance/create_son within the 2-day vesting period

TODO: This should be specified in the FR Document.

11.3 SON gone down into maintenance mode, then de-registered after 12 hours period and user issues remove_son

The first timestamp when the SON initially de-registered takes precedence.

Brain Stroming

Identity Provider - Brainstroming

Created by [Bobinson Bobby]

Brainstorm planning

Brainstorm pre-work & ideas

SSO document prepared by @Prabhjot Singh in 2019

HiveSigner

Scatter

Study Reference Architectures for dApps

Problem Statement

One of the challenges everyone in the blockchain is agreeing and facing is the lack of standards for signin, interaction with between wallets, an SSO mechanism similar to OpenID (Janrain version) which later got extended to Oauth. Needless to say, the blockchain space doesn't even have something similar to a simple gravtar system.

In the context of SSO few items we are trying to do is:

1. For a user with Twitch/Facebook account, it should be easy to sign up for a Peerplays account

2. Once a user owns say, EOS or Bitcoins, she should be able to easily signup or use Peerplays without going through the entire cycle of account creation etc.,

3. Our target market uses additional apps like STEAM, Discord & YouTube gaming (& there could be betting related apps).

The objective of the SSO is to provide a simpler mass onboarding mechanism for people with or without blockchain accounts to start participating in various public blockchains. Such an SSO service like Bitpass can have a massive impact on the blockchains. Graphene-based chains (Bitshares, SCORUM, STEEM & EOS), Bitcoin & Ethereum should be considered as our target blockchains. While storing private keys and "Brain Keys" should not be allowed, we can store Tokens like JWT with an expiry against private keys and store them in a secure database. The database will be encrypted at the store and in transit using TLS to ensure safety. In a nutshell, we can store a mapping between a private key-derived Time & URL-bound unique tokens & various services.

Further use cases: KYC similar to Passport from Telegram, create discord bots, Telegram bots, Access Twitch widgets

The wallet

Similar to the chains and services there is also a challenge with numerous wallet implementations and no clear, unified mechanism for the dApps to interact with wallets. In the case of lesser known blockchain projects its important to get noticed by Software Wallets like Exodus and hardware wallets like Ledger. We would essentially expose a mechanism for the wallets and dApps to integrate with us and also act as signature providers.

The transit API is such an example.

https://medium.com/eos-new-york/the-transit-api-connecting-dapps-signature-providers-5d816c056f7f

Along with the wallet, if we can also consider an extension of Transit API for Peerplays, that will be a great achievement.

The combination of SSO and wallet implementation with a Transit API-like interface will help us to onboard "masses" & safely interact with Peerplays via various dApps.

Thoughts and ideas are welcome!

Brainstorm outcomes

1. In a large dApp like peaked.com or StreamersEdge.com an identity provider that can help end users sign transactions is helpful to isolate the authentication and authorization functionalities from the application business logic

2. We will have to provide easy account creation using existing social accounts like Facebook, Twitter, etc., as opposed to be expecting users to be blockchain savvy. This would mean that the identity provider component should store the MASTER_PASSWORD or the generated keys and lease them to the dApps as when needed.

1. Introduction

The rationale behind the dApps is to develop applications using rock-solid transaction capabilities, tamper-proof immutability, and the impenetrable security offered by the Peerplays blockchain platform.

While these are compelling reasons for developers to use blockchain technology, the need for end-to-end application development knowledge, traditional enterprise-backed software development methods, etc creates entry barriers for developers.

A Blockchain Middleware System (BMS) platform with various components will be built by PBSA to address these unique challenges. Our goal is to expose general-purpose APIs which can be accessed in a language and platform-agnostic way thus making it possible for developers of varying skill sets to create applications on the blockchain.

2. Identity management

User management and identity management are a major part of any application development and the blockchain with unique security constraints brings challenges to the same. While the public key cryptography-based account access provided by the Peerplays blockchain is secure compared to a username password based authentication, the same makes it challenging and next to impossible for laymen to create and use dApps. A common alternative proposed is using cryptocurrency wallets. This doesn't solve the onboarding challenge as a tiny set of internet browsing population and cryptocurrency wallets.

To ensure faster and smoother onboarding of users, Peerplays is thus creating an identity management and SSO platform that helps anyone with an email address, Facebook, or Google account to easily create an account on the Peerplays blockchain. For tech-savvy users, the traditional blockchain mechanism will be used to create the accounts.

In addition to the account creation, Peerplays will also provide simpler mechanisms for dApp developers to create and provision dApps and configure various dApp-level permissions.

3. Requirements

3.1 High-level Requirements

This section will define each of the high-level components of the the identify manager product - PeerID.

The components:

• account creation

• retrieving Peerplays keys

• dApp provisioning

• dApp Permissions

• unlinking third-party services

• Multi-Factor Authentication

• Anti Phishing features

3.1.1 Account creation

A dApp user account creation will always involve creation of an account on the Peerplays blockchain. PeerID will provide 2 modes of account creation. The first mode will be for advanced users which will use the core Peerplays Faucet to generate a blockchain account and keys. A simpler mechanism wherein the account can be created by signing up with Facebook, and Google accounts. The list of third-party services will be increased in the future and they might include Twitter, Discord, Steam, Snapchat, etc.,

3.1.2 Retrieving Peerplays keys

Scenarios might arise that may lead a user to request the Peerplays private keys or master password. In such a scenario, requested keys or a MASTER Password will be sent to the user via an email and shown on the screen/UI. This will be an irreversible action and all the third-party links established during this process will get securely deleted from the PeerID databases.

3.1.3 dApp Provisioning

Developers must be given a simpler interface wherein they can create the dApp, assign permissions, and configure any third-party call-back URLs. Ideally, provisioning of the dApp related permissions, minting the tokens, etc., should be done using the cli_wallet. The provisioning should be used primarily for the staging and development process and the related cli commands can be used to mint tokens, assign permissions, etc., Additionally, multiple accounts can be used to create each type of provisioning. For minting any related token a high-security account can be used, permissions can be created with another user, etc., This must be detailed in the functional specifications.

3.1.4 dApp Permissions

The blockchain-level permissions capabilities should be used to create permissions.

The permissions must map users to dApps, assets, and operations based on various conditions. The conditions themself can be generic and configurable via the PeerID U

3.1.4.1 External conditions

The blockchain will expose a generic interface to validate / verify with any external validator. The dApp can perform the calls with external services like a KYC verification application to receive a callback and then set relevant attributes to a given user.

Limiting users based on conditions set in blockchain-based on external validators. (services like KYC, and geo-location). The external conditions can be is_member_of_facebook, is_MFA_enabled, etc.,

3.1.5 Miscellaneous Features

These features will be low-priority, phase II features that will ensure additional controls and enhanced security.

• unlinking third-party services

• Multi-Factor Authentication

• Anti Phishing features

3.2 Functional Requirements

Account creation

• A user should be able to create an account only by having an email, Facebook ID, or Google ID

• A user should be able to change the passwords

• A user should be able to import or export his Peerplays keys

• A forgot password option must be provided

1.5.dApp provisioning

1. The first step of the dApp creation is to create a corresponding blockchain account for the dapp. A simple UI will be provided for the same.

Aspects provisioned

• account name

• access credentials - usernames, passwords, permissions

• secure tokens

• federated logins with Google, Twitch, Youtube, Facebook, STEAM, EPIC games etc

• support for Multi-factor authentication

The crypto API is available from the full node via websockets.

Blinding and Un-Blinding

blind

Get signed blocks.

Generates a Pedersen Commitment: *commit = blind * G + value * G2. The commitment is 33 bytes, the blinding factor is 32 bytes.

blind_sum

Get SHA-256 blind factor type.

Range Proofs

range_get_info

Gets “range proof” information.

The cli_wallet includes functionality for sending blind transfers in which the values of the input and output amounts are “blinded.”

range_proof_sign

Proves with respect to min_value the range for Pedersen Commitment which has the provided blinding factor and value.

Verification

verify_sum

Verifies that commits + neg_commits + excess == 0.

verify_range

Verifies range proof for 33-byte Pedersen Commitment.

verify_range_proof_rewind

Verifies range proof rewind for 33-byte Pedersen Commitment.

1. Introduction

The goal of every Peerplays dApp developer is to develop applications using the rock solid transaction capabilities, tamper proof immutability, and impenetrable security offered by the Peerplays blockchain platform.

While these are compelling reasons for developers to use blockchain technology, the need for end-to-end application development knowledge along with traditional enterprise backed software development methods create entry barriers for developers.

A Blockchain Middleware System (BMS) platform with various components will be built by the PBSA to address these unique challenges. Our goal is to expose general purpose APIs which can be accessed in a language and platform agnostic way and thus make it possible for developers of varying skill sets to create applications on the blockchain.

2. Identity Management

User and identity management is a major part in any application development. Blockchains bring challenges with their unique security constraints. The public key cryptography based account access provided by the Peerplays blockchain is secure compared to a username and password based authentication. But this method makes it challenging or even next to impossible for laymen to create and use dApps. A common alternative proposed is using cryptocurrency wallets. This doesn't really solve the on-boarding challenge as a tiny set of the internet browsing population use cryptocurrency wallets.

To ensure faster and smoother on-boarding of users, Peerplays is thus creating an identity and access management (IdAM) and SSO platform which helps anyone with an email address, Facebook, or Google account to easily create an account on the Peerplays blockchain. For tech-savvy users the traditional blockchain mechanism will be used to create the accounts.

In addition to the account creation, Peerplays will also provide simpler mechanisms for dApp developers to create and provision dApps and configure various dApp level permissions.

3. Requirements

3.1. High level Requirements

This section will define each of the high level components of the identity management product - PeerID.

The components:

• account creation

• retrieving Peerplays keys

• dApp provisioning

• dApp Permissions

• unlinking third party services

• Multi-Factor Authentication (MFA)

• Anti-Phishing features

3.1.1. Account creation

User account creation within a dApp will always involve creation of an account on the Peerplays blockchain. PeerID will provide two modes of account creation. The first mode will be for advanced users which will use the core Peerplays Faucet to generate a blockchain account and keys. The second will be a simpler mechanism wherein the account can be created by signing up with an email, Facebook, or Google account. The list of third party services will be increased in the future which might include Twitter, Discord, Steam, Snapchat, etc.

3.1.2. Retrieving Peerplays keys

Scenarios might arise which may lead a user to request their Peerplays private keys or master password. In such a scenario, requested keys or a master password will be sent to the user via an email and shown on the screen/UI. This will be an irreversible action and all the third party links established during this process will be securely deleted from the PeerID databases.

3.1.3. dApp provisioning

Developers must be given a simple interface wherein they can create the dApp, assign permissions, and configure any third party call back URLs. Provisioning of the dApp related permissions, minting tokens, etc., should be done using the cli_wallet. The provisioning features within PeerID should be used primarily for the staging and development process. Additionally, multiple accounts can be used to create each type of provisioning. For minting tokens a high security account can be used. Then permissions can be created with another account, and so on. This must be detailed in the functional specifications.

3.1.4. dApp permissions

The blockchain level permissions capabilities should be used to create permissions. The permissions must map users to dApps, assets, and operations based on various conditions. The conditions can be generic and configurable via the PeerID user interface.

The blockchain will expose a generic interface to validate / verify with any external validator. The dApp can perform the calls with external services like a KYC verification application to receive a call back and then set relevant attributes to a given user.

PeerID should allow limiting users based on conditions set in the blockchain which are based on external validators (services like KYC, geo-location, etc.) The external conditions can be properties like is_member_of_facebook, is_MFA_enabled, etc.

3.1.5. Miscellaneous features

These features will be low priority, phase II features that will ensure additional controls and enhanced security.

• unlinking third party services

• Multi-Factor Authentication

• Anti-Phishing features

3.2. Functional Requirements

3.2.1. Account creation

• A user shall be able to create an account with any one of the following:

  • email address

  • Facebook id

  • Google id

• A user shall be able to change their password

• A user shall be able to import or export their Peerplays keys

• A password recovery (forgot password) option shall be provided

3.2.2. dApp provisioning

1. The first step of dApp creation is to create a corresponding blockchain account for the dApp. A simple UI shall be provided for creating the dApp account.

Aspects provisioned for the dApp account:

• account name

• access credentials - usernames, passwords, permissions

• security tokens

• federated logins with Google, Twitch, Youtube, Facebook, Steam, EPIC games, etc.

• support for multi-factor authentication

4. Glossary

dApp - Decentralized Application. Just like a typical computer application, but with no centralized database, host, or distribution.

PBSA - Peerplays Blockchain Standards Association - For more information, see .

IdAM - Identity and Access Management - A framework of policies and technologies for ensuring that the right users have the appropriate access to technology resources.

SSO - Single Sign-On - An authentication scheme that allows a user to log in with a single set of credentials to any of several related, yet independent, applications. True single sign-on allows the user to log in once and access services without re-entering authentication factors.

PeerID - The IdAM and SSO blockchain middleware for the Peerplays blockchain.

MFA - Multi-Factor Authentication (encompassing two-factor authentication, or 2FA, along with similar terms) - An authentication method in which a user is granted access to an application only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism.

KYC - Know Your Customer (or Client) - Guidelines in financial services that require organizations to make an effort to verify the identity, suitability, and risks involved with maintaining a business relationship.

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:

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:

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:

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).

1. Purpose

The purpose of this document is to outline the steps required by a Peerplays node operator to enable/disable Sidechain plugin in the Peerplays blockchain.

2. Scope

The functional requirement listed in this document will be limited to the configuration portion of the SON. This will outline the required steps that will be performed by the Peerplays node operator to enable/disable Sidechain plugin in the Peerplays blockchain from the command line. 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.

3. 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.

4. Process Overview

Described here is the process to configure the SON plugin in the Peerplays blockchain.

5. Context

The Peerplays blockchain will allow the node operators to enable/disable the Sidechain functionality on their node. They will have to stake PPY 50 to be able to register as an SON. As soon as the Sidechain functionality is enabled/disabled and the user vests 50 PPY, the Peerplays blockchain will add the node to its list of Sidechain enabled nodes and make the node operator available for SON voting. An SON enabled node will be able to operate as an SON only when it receives the votes required to become one of the top 15 SONs.

6. Flow Diagram

7. SON Commands

Any Peerplays node can become a SON irrespective of it is a witness or not. It can connect to a local or remote Bitcoin node and verify the transactions.

7.1 Enable SON

./programs/witness_node/witness_node --resync --replay --son-enable

This command will enable the SON functionality in the Peerplays node. The node will be registered in the peerplays blockchain as an SON enabled node. Peerplays users will be able to vote for this user to be an active SON. The node will be able to listen to the changes on the Bitcoin blockchain. An active SON can perform all the functionality of the sidechain once it has been voted into the top 15 SONs.

7.1.1. Pre-Conditions & Errors

The error messages are to be displayed in GUI wallet or cli_wallet or other programmatic means.

1. The SON node should not be enabled and active for the same Peerplays account

2. Trying to enable an already in enabled SON node will give the error message "SON is already enabled for the account_name."

3. The account trying to enable SON should have a minimum balance of 50 PPY which has to be VESTED to become SON

4. If the account is not having the minimum required balance, an error message "Minimum VESTING Balance for SON node activation is not available. Make sure that the account is funded with MINIMUM_VESTING_BALANCE"

5. If a previous VESTED balance is available, it will not be considered to be the minimum VESTING BALANCE. This is to avoid accounts spamming the blockchain with SON-activate commands.

7.2. Disable SON

This section talks about permanently disabling SON.

./programs/witness_node/witness_node --resync --replay --son-disable

This command will disable the SON functionality in the Peerplays node and deregister the node in the peerplays blockchain as an SON enabled node. Any votes casted to the user to be an active SON will be reverted. The user will be able to claim their vested PPY after 2 days of deregistering their node.

7.1.2. Pre-Conditions & Errors

The error messages are to be displayed in GUI wallet or cli_wallet or other programmatic means.

1. Only a SON node which is in "enabled state" can be disabled

2. Trying to de-activate/disable a Peerplays node with SON not enabled will give the error message "SON is not enabled for account_name"

3. If a SON is disabled and trying to move the VESTED funds before 2 days duration via any means should be prevented

API Requirements

All the v1 Sidechain APIs should work as it is. Except for those, an API to provide the list of SON enabled users will be required. The API should return the list in the following format:

CLI Wallet Command Requirements

These are new options to be added.

1. list_sons: We need a command in the CLI Wallet similar to list_witnesses to get the list of SONs.

2. list_active_sons: This command should provide a list of active SONs on the Peerplays blockchain.

The below sections help in understanding the ways of deployment and development.

1. OBJECTIVE

Provide requirements for Sidechain Operating Nodes (SON). PIP (Peerplays Improvement Proposal) for the same is here : https://github.com/peerplays-network/pips/blob/master/pip-0005.md

• Provide bi-directional exchange of value (tokens/coins) between multiple chains and Peerplays

2. Assumptions

• Peerplays blockchain will be upgraded to support Ubuntu 18.04

• GPoS will be merged and available

• BOOST 1.67.0, Peerplays-FC with default versions of build tools like gcc, g++, cmake available on Ubuntu 18.04 will be used for the development.

• A specific version / branch of the Peerplays blockchain will be provided by PBSA where all the unit test cases are running successfully

• Voting UI will be made available

INTRODUCTION

In order to facilitate the transfer of token operations from the Peerplays blockchain to and from another blockchain Side Chain Operating nodes aka SONs is proposed. This mechanism will tie directly into GPOS in order to accomplish a full inter-blockchain communication mechanism. The scope of SONs is limited to transfer of value and not state across chains. The transfer of value will be bi-directional.

The core Peerplays blockchain will support SONs by having the plugin running SON receiver logic. The core of Peerplays blockchain will undergo only necessary changes, but not related to support of various external chains like EOS, Bitcoin and Ethereum. ie interface changes for support of new chains will happen at the SONs plugin and not at the Peerplays witness.

SONs will be elected through a voting mechanism making use of GPoS. A user interface allowing users to vote for SONs has to be created. This can be also incorporated to the wallet.

SON AS A PLUGIN

A Peerplays node, can enable or disable SON via the configuration file and restarting the node. When a node which wants to be an SON, node operator will enable and configure SON plugin, and register SON account. Disabling or enabling the plugin should not impact replaying the node. A SON becomes active participant based on the votes it receives. That is to say if a node just activates the plugin and registers SON account, but not receiving any votes, it will not be able to operate as a SON.

The SON plugin must have a mechanism to submit transactions it receives from side chains.

The SON plugin should enable API and programmatic interface which will help dApps or scripts to send transaction details from other chains to SONs. We must expose a generic interface which can be further extended for various blockchains. SONs must publish an API so that RPC requests for EOS, bitcoin & other chain related transactions to them. (Refer BTC Relay & PeaceRelay)

Transactions from Sidechain > SON Transaction Receiver > Processing and Signing of the Transaction by 2/3rd of the SONs > SON Transaction Submitter > Peerplays

As described above the SON must expose a generic transaction receiver with support for EOS, Bitshares, Bitcoin and Ethereum. A generic definition of the interface should be provided as part of the High Level Design. The generic interface should be capable of extending to support more chains in the future.

Enabling the SON plugin will not have any impact on a Peerplays witness node unless the node is also elected as a SON. The primary difference between the earlier Bitcoin sidechain implementation and SON is that no additional components from other chains will have to be operated by the SON nodes. This will ensure a lean system as opposed to the Peerplays nodes running various blockchains like Bitcoin and Ethereum Virtual Machines. This means no smart contracts written for say EVM will be executed in any of the Peerplays nodes irrespective whether they are witnesses, seed nodes or SONs.

VOTING

SONs will be elected using GPOS voting. The SONs will change depending on criteria like the votes received, taken out of circulation due to down time, planned maintenance etc. A minimum of 5 SONs should be available at any point in time for the SONs to be operational. The requirement of minimum 15 is needed to provide resilience. Transaction approval will require a minimum of 2/3rd approvals in any case.

As an SON enabled node, if my downtime exceeds 12 continuous hours, I should be automatically deregistered in the Peerplays blockchain as an SON enabled node and all the votes cast for me should be reverted. (Applicable only for unplanned downtime)

FEES

A daily rewards pool will be established for SONs that will be paid out daily based on transactions signed and weight of voting. Both approved and rejected transactions shall be included as part of the total transaction count. Recommended starting balance should be 200 PPY daily.

A SON, will be paid for providing my services through the blockchain & in PPY. The payments will be dispersed after each Maintenance cycle. All the transaction fee deducted from the bitcoin transactions for SONs should be deposited in a separate account just like the dividend-distribution-account.

KEY MANAGEMENT

To create a multisig address on Bitcoin, the signatures of all the SONs are required. The signatures of the top 2/3rd SONs in-terms of votes would be used while creating the Multisig account on the bitcoin blockchain. The top 2/3rd selection is thus an important end user controlled activity in the chain.

When a SON needs to perform maintenance, it will disable the node which will first rotate the keys used for the multi-signature wallet. This operation has to be detailed in the system architecture and design documents.

In the event of a SON part of the key management goes down abruptly, the funds under maintenance will be stuck until the SON comes back.

All bitcoin transactions in Peerplays blockchain get validated to ensure they are originated form the SONs only. Add validations on the Peerplays blockchain to check that the bitcoin transactions originated from the SONs only.

As soon as there is a change in the SON, his private key on the bitcoin address should be replaced by the private key of a new incoming SON OR we can simply delete the private key from the outgoing SON's account and add it to the new SON's account.

TODO: explore HTLC

TRANSACTION SIGNING & CONSENSUS

As captured early, we would need 15 SONs for the normal operation of the SON network. If the number of nodes goes below this number SONs should stop accepting new transactions. However if there are already existing multi-signature wallets & pegged assets or tokens issues in the Peerplays network those operation should continue. Any Transaction submitted by the SONs on the Peerplays blockchain should be signed by at least half + 1 SONs. This would ensure that a single SON cannot submit a malicious transaction on the blockchain.

SONs should create a distributed event bus sort of mechanism which should receive transaction details. If a SON receives the request for a transaction via an API, it must publish it to the event bus which the other SONs can read and process. This should be using a publisher - subscriber mechanism. If at any point in time a SON finds that a particular transaction is signed by 2/3rd of the SONs, that SON will post the transaction to the Peerplays blockchain. This will ensure that the Peerplays blockchain receives only those transactions which are signed by 2/3rd of the SONs. Upon receiving the transaction from the event bus, the SON will verify the transaction details with the appropriate blockchain & if the data on the source blockchain (sidechain) seems to be intact, the SON will sign the transaction and publish it back to the event bus. Any transaction signed by 2/3rd of the SONs will be marked dirty and will be taken out of the event bus. For the event bus, a ring buffer design pattern can be implemented. (refer: LMAX disruptor)

This will prevent any SON from creating a malicious transaction by running a malicious bitcoin node.

VESTING REQUIREMENTS

Nodes interested in becoming SONs must vest 50 amount of PPY. The PPY vested by SONs can't be claimed till 2 days after they have deregistered their SON node.

PERFORMANCE REQUIREMENTS FOR SONS

The performance of the SONs should be determined by their uptime as well as the errors that they make. Uptime & missed blocks or similar errors should be tracked and presented to the voters providing historical performance data to the voters.

Witnesses should have the power to freeze SON's account or blacklist SON. If an error on the part of an SON is not verifiable with a fork of the bitcoin blockchain then the witnesses should have the power to freeze his account or blacklist him.

ACCEPTANCE CRITERIA

• performance: TPS, computational resource KPI must be defined

• security audits: The ring buffer can be bombarded with event submissions. This must be carefully evaluated.

• For each blockchain SONs are going to support, separate KPI (key performance indicators should be defined)

• code peer review

User interaction and design

The end users are the Peerplays holders. They will be able to vote and select SONs. We need to prove a UI for the end users to engage in voting.

Open Questions

Out of Scope

TBD

1. Purpose

The purpose of this document is to outline various scenarios in which SONs will be switched from the top 2/3rd and also among the top 15 minimum ACTIVE SONs.

2. Scope

The functional requirement listed in this document will be limited to the multi-sig key change scenarios only.

3. 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.

4. Process Overview

Various scenarios are outlined in the Scenarios section

5. Context

The SONs has a ranking & grouping. The ranking is depending on the total effective stake of the votes received. We can have infinitely many SONs and rankings. The top 15 nodes aka ACTIVE nodes are the ones which are mandated by the SON implementation. ie at any point of time, there has to be 15 nodes for the SON feature to be operational. Apart from the ACTIVE group of top 15, we also have a 2/3rd top ranked SONs in terms of votes which signs the transactions.

Any time there is a change to active SON list, a change to primary wallet scripts will be triggered. Therefore any change to active SONs list must result in creation of new primary wallet using public keys of SONs that remain active after the change. The reason for this is that primary wallet is created based on public keys of all active sons, when the composition of active SON list changes, it affects what keys are associated with the primary wallet.

At each maintenance intervals, list of candidates for active SONs is compared to list of current active SONs, if lists are different, list of current active SONs is understood to change and thus a new primary wallet must be generated.

6. Scenarios

Scenarios below are examples of changes that may impact active SONs list and thus trigger re-creation of primary wallet using public keys of SONs on active SONs list.

6.1 Ranking change within the top 2/3rd SONs

In this scenario the SONs will change their ranking and order but the top 2/3rd SONs will remain the same. This means, if there are 15 SONs and the 2/3rd is 10 SONs, the rank of the 10 SONs will be changed. But it will not have any impact on the multi-sig wallet. On using the list_sons will provide the new order.

During design, if possible its recommended to have invoke the immediate ranking change only in the case of a change involving the multi-signature key change. ie, this particular scenario can be ignored until the first deposit transaction happens. This will induce a slight delay in the display of ranking of the SONs for the reporting purposes.

6.2 Ranking Change due new votes resulting in the change of multi-wallet key

This scenario addresses the normal case where one or more of the top 2/3rd SONs loses votes and they moves out of the top 2/3rd.

An example scenario is with 15 ACTIVE SONs where the top 10 are forming the 2/3rd quorum. When one of them loses votes, an ACTIVE node or a node outside of TOP 15 ACTIVE nodes replaces its position.

This scenario would trigger:

• creation of a new Bitcoin address

• move the Bitcoin (BTC) balances to the new address which is controlled by the new set of top SONs

• The deposit and transfer APIs of the SON should return new multi-signature wallet address

6.3 Ranking change - ACTIVE SON change

If an ACTIVE SON receives or loses votes, its effective stake can change. This can trigger the ranking change. The change will be executed at the next son_maintenance_interval` , ie 24 hours or during the next deposit/withdraw operation whichever comes first.

Ranking changes in the list of SONs must result in creation of new multi-signature wallet using public keys of new SONs. Balances are then transferred to the new address.

Note that any changes to list of SONs must result in new wallet being generated and balances transferred to new wallet address.

6.4 Ranking Change - Disabling an ACTIVE SON

If an ACTIVE SON disables its node, another node has to replace it.

This can trigger the ranking change. The change will be executed at the next son_maintenance_interval` , ie 24 hours or during the next deposit/withdraw operation whichever comes first.

Ranking changes in the list of SONs must result in creation of new multi-signature wallet using public keys of new SONs. Balances are then transferred to the new address.

6.5 Ranking change - an ACTIVE SON goes offline

In this scenario, an ACTIVE SON but not in the top 2/3rd in terms of cumulative votes received goes down.

• SON goes down/offline

• The SON network records this

• Upon completion of 12 hours after the SON going down/offline event is recorded, the ranking change is triggered

• The Ranking change will be executed on the first deposit transaction or once in 24 hours whichever comes first.

• This approach is done at the cost of status change at the front-end, but to avoid unnecessary operations in the chain

Ranking changes in the list of SONs must result in creation of new multi-signature wallet using public keys of new SONs. Balances are then transferred to the new address.

6.6. A top 2/3rd SON goes offline

A high stake SON or a group of SONs goes offline without notice. This scenario or slowness is often observed during large scale internet routing attacks involving BGP poisoning or a data center maintenance where a group of servers becomes unreachable. (This often happens when certain German data center performs an upgrade or maintenance).

• If we have ACTIVE SONs, and if need to perform a key change before the on the maintenance interval or before the next deposit transaction is requested, we can proceed with the change of keys

• Upon such a change the funds has to be transferred to the new wallet created

• The fund transfer will be possible if the remaining SONs who originally signed the transaction has enough authority (weight) to perform the withdraw operation on the old wallet

• If the remaining SONs doesn't have enough control / weight to operate the multi-signature wallet, the funds will locked in the previous wallet until the necessary SONs becomes active. There seems to no way to address this. But, new deposits to the address will not be entrained as the deposit API will return new Bitcoin address.

If change of keys occurs for any SONs, this event must must result in creation of new multi-signature wallet using new SON keys. Balances are then transferred to the new address.

6.7 A top SON goes into maintenance - with key change

If a SON part of the multi-signature wallet creation with a large stake enough to trigger change in the keys, the maintenance mode should trigger a change in the ranking of the SONs & also a change in the keys.

To avoid frequent key changes, the key change can be handled upon the first deposit or withdrawal. The deposit and withdrawal operations to the SON should be made via calling respective APIs to make this possible.

IMPORTANT: The time taken for the wallet change operation should be captured and we need to take this account for fine tuning the strategy for key changes. This is something that we can't easily predict right now, but needs to test and verify.

This scenario must trigger creation of new wallet using SON public keys, and transfer of balance to new wallet address due to change in SON composition and public keys.

Purpose

The purpose of this document is to provide the design for the SON configuration.

Scope

This document describes the SON configuration based on the functional specifications Functional Specification - SON Configuration excluding the functionality that has been described in the Low Level Design document Wallet Commands for SON.

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 SON 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 SON needs to be removed from the multisig bitcoin wallet and the key of the incoming SON 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).

Process Overview

Described here is the design for configuring the SONs on a node

Context

SONs have to be implemented as a plugin i.e. it shouldn't be mandatory for a node operator to register as an SON. It should be an option that can be chosen at the time of starting/restarting a node. Moreover, there shouldn't be an issue when replaying the chain even if the plugin is disabled. Also, the number of active SONs should be a chain parameter and the witnesses should be able to vote and change it.

son_plugin

son_plugin class should inherit from the graphene::app::plugin class and the methods plugin_set_program_options(), plugin_initialize(), plugin_startup() and plugin_shutdown() can be overridden to initialize the rpc client and to start/stop the bitcoin zmq listener.

son_api

All the APIs related to sidechain should be moved to the son_api class in the graphene::son namespace together with the son_plugin so that it is easy to maintain the project.

Register son_plugin

The SON plugin has to be registered in programs>witness_node>main.cpp using the register_plugin() method of node object if the options contain the string "son-enable" like below:

if(options.count("son-enable"))

node->register_plugin<son::son_plugin>()

This has to be done before calling the initialize_plugins() method of the node object.

get_tournaments_in_state

Get a list of tournament ids for upcoming tournaments

get_registered_tournaments

Get a list of registered tournaments by account id.

get_tournaments

Get all tournaments between last_tournament_id and start_tournament_id.

Ubuntu

Configure the environment file

Configure the .env with the specified values:

Start the application (dev mode)

For a production environment build the static files:

After building the static files, you can host them using any web server.

PeerID-backend

configure the config/default.json and config/development.json files:

default.json

development.json

Start the application:

Objective

This document is intended to outline generic design of deposit handling by Peerplays sidechain operating node. This interface will be extended to meet various other integrations.

Sidechain operating node will monitor target sidechain for events of interest, namely transfer of assets to a Peerplays address. When transfer happens, sidechain will process it, in order to pick up information needed to handle it. Handling deposits will create certain amount of tokens on a Peerplays network. This amount will match the amount of assets on target sidechain by predefined exchange rate.

Assumptions

• Peerplays SON network is able to control (transfer or create) assets on Peerplays network, in order to send assets to a user account. E.g. Peerplays SONs network has control over an account on Peerplays network which holds initial ballance of Peerplays tokens, or is able to mine them to user account, or create them out of thin air and transfer them to user during deposit handling.

• Peerplays SON network have full control over address/account on every supported sidechain. This address/account may be single signature wallet, multi-signature wallet, script, smart contract, or any other entity supported by a target sidechain, which is able to receive assets from users. This is the address where user should send his assets to, in order to get Peerplays tokens on Peerplays network.

• Sidechain operating node has access to assets exchange rate list, containing exchange rates for every asset on every supported sidechain network. This list should be updateable by Peerplays network administrators.

• Sidechain operating node has access to user accounts mapping list, containing user addresses on supported sidechains. Key value in this mapping is user’s Peerplays account. E.g. [PeerplaysAccount, BitcoinAccount, EthereumAccount, …]. All sidechain accounts should be created by user (e.g. user can enter them during registration as a Peerplays user). Account creation on target sidechain should not be handled by Peerplays, because of increased risk of handling their private keys. This list should be updateable by user.

Block diagram

Link to file

Description

• As described in , when event of interest, transfer to a certain address on a target sidechain occurs, a sidechain handler will process it, and save the event data into Peerplays network for further processing.

• Sidechain handler will identify user depositing funds, by searching transaction’s source address in user accounts mapping list, in order to find which Peerplays network address matches sidechain transaction source address. Peerplays network will transfer assets to this address (target address).

• Sidechain handler will get the exchange rate from Exchange rate list, in order to calculate exact amount that needs to be transfered to the target address.

• SONs will synchronize between them selves, by exchanging information about new transaction on sidechain and information about transfer that needs to be executed on Peerplays network. Once all active SONs have same information about transaction, randomly selected SON will create transaction and start singing process. Source address of this transfer will be SONs controlled account for issuing assets to users.

• When first signature is added to transaction, signed transaction will be sent through SONs network, so that other SONs can sign it. At least 8 SONs needs to sign this transaction. We can also go with SONs with at least 2/3 of total weight signature, if that's supported by Bitshare. For now, it does not look like it is. Last SON signing transaction will broadcast it to the network. Tutorial on how to use multisig in Bitshares is here:

• All sidechain specific functionalities will be implemented in sidechain handler.

• All general functionalities will be implemented in sidechain handler base class.

Sequence diagram

Link to file

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

Purpose

The purpose of this document is to outline the steps required by a user to vote for an SON in the Peerplays blockchain and the consensus mechanism for SONs.

Scope

The functional requirement listed in this document will be limited to the voting and consensus portion of the SON. This will outline the required steps that will be performed by a user to vote for an SON in the Peerplays blockchain and their selection as active SONs. 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 vote for SONs in the Peerplays Blockchain.

Context

The Peerplays blockchain will allow the users to vote for the SON enabled node operators. The Peerplays blockchain should have a minimum of 15 active SON nodes. The user should be able to see a list of the SON enabled nodes and vote for up to 15 nodes. An SON enabled node will be able to operate as an active SON only when it receives the votes required to become one of the top 15 SONs. The number of active SON Nodes can be increased by the witnesses/advisor by making a change to the chain parameters. The active SONs will have corresponding bitcoin transaction signing keys in order to sign transactions for the Peerplays bitcoin multisig address on the bitcoin blockchain. When the active SONs change on the Peerplays blockchain, their corresponding bitcoin transaction signing keys are changed in the Peerplays bitcoin multisig address on the bitcoin blockchain.

Each SON when processing inter blockchain communications (IBC) will carry a percentage of weight in the signing based on the votes they have received. Every IBC request will require signed consensus by at least ⅔ of the Active Cast Weighted (ACW) Votes for the SONs. Active Cast Weighted votes means the votes casted to active SONs by users who have staked some PPY weighted by their staked PPY.

If an SON enabled node's downtime exceeds 12 continuous hours, it should be automatically deregistered in the Peerplays blockchain as an SON enabled node and all the votes cast for me should be reverted.

If an SON decides to stop operating the node by disabling the SON plugin, any votes cast to him will be removed and another SON will take his place.

Flow Diagram

SON Voting Command

The below command from the CLI wallet will be used to vote for SONs: vote_for_son <voting_account> <son> <approve> <broadcast>

• voting_account_id: the name or id of the account who is voting with their shares

• son: the name or id of the son's owner account

• approve: true if you wish to vote in favor of that son, false to remove your vote in favor of that son

• broadcast: true if you wish to broadcast the transaction