API Reference
Peerplays API Libraries
Development Guides
The Cookbook
Tools and Integrations
Supporting & Reference Docs
Development Workflow Docs
Other Documentation
Bitcoin Withdrawal Handling
1. Purpose
The purpose of this document is to outline functional specifications for monitoring bitcoin network and handling withdrawals. Result of a withdrawal is conversion of peerplay assets (pBTC) to Bitcoin (BTC) using 1:1 ratio.
2. Scope
Sidechain operating node will monitor Bitcoin network 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 withdrawals 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.
Specific functions covered include:
- monitor transactions to a designated sidechain user address
- handle withdrawal via creation of sidechain event data
- create & confirm object proposals
- conversion of pBTC to BTC using 1:1 ratio
- sign transactions
- withdraw bitcoin for conversion into peerplay tokens
3. Background
Withdrawal handling will consist of listener and handler functionality. Listener can identify and report new block, a transaction, or filtered single event (like specific operation involving specific address). Handlers will process the event identified by listener.
We have identified three (3) distinct scenarios describing how deposits and withdrawals may be implemented. Scenarios are outlined in this article:
Requirements below are describing functional specifications based on Scenario 1 - Multisignature primary wallet controlled by SON network, holding all the funds. All transfers are made to and from this multisignature wallet.
4. Process Overview
Described here is the process of monitoring withdrawal address and processing transactions that occur in relation to target address.
pBTC token issue is initiated by Sidechain Listener identifying a Bitcoin withdrawal, passing information to Sidechain Handler .
Steps involved:
- 1.User initiates withdrawal to convert pBTC to BTC
- 2.Listener identifies withdrawal type change in the block chain
- 3.Listener passes event data to handler
- 4.Handler receives event data and creates an object (normally SON Wallet Object, SON Wallet Deposit Object or SON Wallet Withdraw Object)
- 5.Object is checked by by all active SONs to compare object data from the chain against data generated by each SON.
- 1.If data does not match, transaction is terminated
- 2.If data matches, object is deemed ‘Confirmed'. Proceed to next step
- 6.Handler checks the number of active SONs
- 1.If active SONs are > 5, proceed to next step
- 2.If active SONs are < 5, store transaction for processing until required number of active SONs is available (this step will be repeated until SON availability requirement is met)
- 7.Issue proposal for for sidechain transaction create operation
- 8.Active SONs create local copies of transaction data to be verified against proposal
- 9.Proposal is verified by active sons by comparing local copies of transaction data to proposal
- 1.If data does not match, proposal is not approved and will eventually expire thus terminating the transaction
- 2.If data matches, proposal is approved. Proceed to next step
- 10.Transaction object containing a list of SONs expected to sign is created and published to the sidechain. List of SONs will be created based on list of active SONs
- 11.Expected SON signers initiate parallel processing of transaction. Offline SONs will not participate in signing and only the online SONs (regardless of status) will sign the transaction
- 12.Sign transaction
- 1.Each signing SON adds its signature
- 2.Each signing SON is added to list or received signatures
- 3.Operation evaluator checks signatures to determine if latest signature is the last signature required to complete transaction signing
- 1.If no, repeat this step after each SON’s signature
- 2.If yes, mark transaction object as ‘Completed’ (helper field complete = true)
- 13.Scheduled SON detects completed transaction object
- 14.Transaction is converted to a readable format and sent to Bitcoin network
- 15.User receives BTC amount
- 16.Withdrawal is marked as processed
5. Context
To facilitate conversion of peerplays tokens into bitcoin, SON must include an event listener and an event handler mechanisms to identify specific types of transactions and handle them accordingly. Proposed approach uses multisignature Primary Wallet controlled by SON network, holding all the funds. All transfers are made to and from this multisignature wallet.
6. Flow Diagram
7. Requirements
Current deposit address implementation is Timelocked-one-or-weighted-multisig
7.1 Listener
SON must include a Bitcoin event listener which monitors a designated Bitcoin address registered as a sidechain user address for withdrawals Specifically, listener uses Bitcoin node interface for monitoring changes in the block changes.
Listener must be able to recognize a change that signifies a withdrawal event and capture the following data associated with each transaction of this type:
- Transaction unique identifier
- Transfer operation’s source address
- Transfer operation’s target address
- Transfer amount
Following identifying a withdrawal transaction, Listener must check the number of active SONs to verify that a minimum of 5 SONs are active. If minimum is not met, withdrawal transaction must be stored for processing until minimum number of active SONs becomes available.
7.3 Handler
SON must include a Bitcoin event handler which uses information supplied by the Listener to perform a specific operation that’s based on transaction type submitted by listener. When handler receives notification of Withdrawal transaction from the Listener, sidechain_event_data must be received and passed to sidechain_event_data_received. Received sidechain event data must then be used to create proposal for a withdrawal descriptor object son_wallet_withdrawal_object.
System must then create a SON Wallet Withdrawal Object, which upon creation will be processed by all available SONs to verify its data. To verify object, system must check local data of each SON against object data on the side chain. Object must be deemed valid when its data is confirmed, and rejected when its data cannot be confirmed. Transaction terminates if object data is not confirmed during this check.
Successful object verification results in issuance of transaction create proposal that is based on confirmed object and includes some of its data (specifically, a reference to the object). Created sidechain transaction object must contain reference to the sidechain where it should be processed, reference to the object it is created for, sidechain transaction body, list of expected signers, list of received signatures, and the helper fields for calculating signature weights.
This proposal must be verified by SONs, which is performed by verifying referred object against locally re-created transaction data. If data does not match, proposal will be deleted from proposal list and transaction won’t be completed. If data matches, system must approve the proposal. Approved proposals must result in object being published on the chain.
When the object is published on the chain, SONs specified on the list of expected signers must begin processing it in parallel. Note that SONs specified as signers must sign the transaction as long as they are online, disregarding their status (thus SON in any status must sign the transaction). Once enough signatures hve been collected, transaction is marked as ‘Completed’.
When scheduled SON detects that a sidechain transaction object has been completed, it must collect all data from the sidechain transaction object, compile it, convert to a format that is ready for transmission to Bitcoin network, and send this transaction to the Bitcoin network.
SON must start conversion of withdrawal amount from peerplay tokens into Bitcoin following withdrawal confirmation. Conversion operation must calculate pBTC to BTC conversion using 1:1 rate. Conversion is completed by sending funds from bitcoin address (sidechain user address for withdrawals) to primary wallet (bitcoin multisig address).
User will receive bitcoin corresponding to amount of converted pBTC. Lastly, scheduled SON must mark son_wallet_withdrawal_object as processed
7.4 Refund Scenario
In some cases a transaction will not be processed by SONs (such as when active SONs threshold is not met), which will cause funds to wait until required number of active SONs become available. System must allow users to initiate refunds of their transactions.
Refund scenario must adhere to same rules as regular bitcoin transaction:
- 1.User needs transaction id for the transaction they wish to refund
- 2.User creates another transaction using transaction id of transaction they want to refund to move funds to their own address
- 3.User signs the transaction using a private key that matches the public key he provided in sidechain address mapping
- 4.Transaction is pushed to bitcoin network and user is refunded once transaction is processed
Current Deposit Address Implementation - One-or-weighted-multisig
This deposit address implementation type allows to send funds from this address with 2/3 weights of SON votes (like in Primary Wallet) or with single user signature. To create such address we need:
- 1.user public key
- 2.all SONs public keys
- 3.every SON weight
Note: This is the current implementation of the Deposit address.
This address type is implemented by btc_one_or_weighted_multisig_address class.
8. Glossary
pBTC​ is a peerplay Blockchain Asset, which represents users’ balances in Bitcoin on PeerPlays blockchain. Having a balance of 1 pBTC would mean having it backed by the same amount of Bitcoin on a Witness-controlled Multisig Wallet. New pBTC are NOT ISSUED by OWNER with ​issue ​operation. New pBTC are issued strictly in relation with ​Deposit​ operations.
PW (Primary Wallet) ​is the main Multisig Bitcoin Wallet.
Multisignature (multisig) refers to requiring more than one key to authorize a Bitcoin transaction. It is generally used to divide up responsibility for possession of bitcoins.
Related Documentation
Last modified 10mo ago