Peerplays Development FAQs
Bitcoin-SON
Command:
References:
From developer.bitcoin.org...
For situations where interaction with random peers and blocks is unnecessary or unwanted, Bitcoin Core’s regression test mode (regtest mode) lets you instantly create a brand-new private block chain with the same basic rules as testnet—but one major difference: you choose when to create new blocks, so you have complete control over the environment.
Many developers consider regtest mode the preferred way to develop new applications. The following example will let you create a regtest environment after you first configure bitcoind.
Start
bitcoind
in regtest mode to create a private block chain.
Generate 101 blocks using a special RPC which is only available in regtest mode. This takes less than a second on a generic PC. Because this is a new block chain using Bitcoin’s default rules, the first blocks pay a block reward of 50 bitcoins. Unlike mainnet, in regtest mode only the first 150 blocks pay a reward of 50 bitcoins. However, a block must have 100 confirmations before that reward can be spent, so we generate 101 blocks to get access to the coinbase transaction from block #1.
Verify that we now have 50 bitcoins available to spend.
You can now use Bitcoin Core RPCs prefixed with
bitcoin-cli -regtest
.Regtest wallets and block chain state (chainstate) are saved in the
regtest
subdirectory of the Bitcoin Core configuration directory. You can safely delete theregtest
subdirectory and restart Bitcoin Core to start a new regtest. (See the Developer Examples Introduction for default configuration directory locations on various operating systems. Always back up mainnet wallets before performing dangerous operations such as deleting.)
Reference:
Command:
References:
Command Definition:
Command Structure:
Command Example:
Reference:
Gamified Proof of Stake (GPOS)
Faucet
One can use Curl command or POSTMAN in order to create a new account in the Faucet. With Curl you can do the following:
IP_ADDRESS should be 127.0.0.1 or localhost when running it directly in a VM or on your local machine.
owner_key
, active_key
, memo_key
should start with TEST on testnet, and it should be PPY on mainnet.
If the result of the above is successful, there should be output like this:
And in case of any error, it will be following (i.e. duplicate account):
You can also track the logs in Faucet container, with the following command:
And look for logs when receiving Create Account requests, with 200 status code as a result.
Peerplays DEX
This works with a Faucet and a local QA environment (create account & login).
First, pull the DEX repository from here.
After setting up the project, update the following variables in .env file:
IP_ADDRESS should be 127.0.0.1 or localhost when running it directly on your local machine.
Peerplays QA Environment
In the QA environment setup by instructions in here, execute commands in Peerplays01 container with the following:
Then running into account’s wallet:
Unlock the wallet with the default password (which is "password"):
Get the private key for active key (public key):
ACCOUNT_PASSWORD is the password defined when creating account in DEX UI.
Import the private key returned from previous step:
Finally transfer with the following:
memo key should be empty string for it to work. With list_core_accounts command you can check all account’s balances.
❓How to ensure QA environment is healthy ?
If you are getting "Generated block..." and "Scheduled SON..." messages, and SON last active timestamps are updated regularly, SON network is working as expected. To get last active timestamp, first use get_object 1.33.X (ids are 1.33.0, 1.33.1, ... 1.33.6), statistic object id will be there, and then use get_object statistic_object_id (I believe ids are 2.25.0, 2.25.1, ... 2.25.6). All timestamps should be in a last few minutes.
Last updated