Private Chains concept is based on structured Burst Messages. A private chain is created with 2 ordinary Burst transactions sent to 2 different Pchains Accounts. One account serves as a chain creation account and accepts creation fees (50 Burst) from chain creators. The chain creator sets ticker (name) of chain and maximum number (cap) of tokens in chain.
Upon creation, the creator is the owner of all tokens in that chain. The other account serves as transaction account which holds transactions for all chains, if not otherwise specified in chain creation for a particular chain.
Both creation-specification and chain-transactions in chain are sent the ordinary way as Burst messages to the 2 Pchains Accounts.
Newly created chains arrives in the 1st Pchains account as a Burst message. Participants confirms the creation string and verifies that creator also has sent creation fee from same sender account.
Then initially, creator is the holder of all tokens in that chain and can freely spend them as he/she wishes by sending a structured Burst message to the 2nd Pchains account. Miners confirms he/she is the owner of the tokens and confirms the new owner in that transaction.
Messages the ordinary Burst way is the only way to use Pchains. The Pchains framework watches non-encrypted messages only, sent to the 2 Pchains accounts. Chain creation messages, without creation fee are ignored, which prevents spammers to operate without a cost. Transaction messages from accounts not holding that particular token, are by miners verified invalid and ignored.
The network is nothing but activities on the 2 predefined Pchains accounts that participants watches through the framework.
Framework users can join the Network and operate as both a client and a server, thus also participate as a miner. Alternatively the user can choose to stay as client only, no request from other clients and no miner participation. The framework will include a client and a server and if set up as full node the framework needs to be installed on a server. A whitelist of servers participating in the network is distrubuted between participants. Post requests from not whitelisted referers on a specific server are ignored. A possible way the avoid spammers on servers is to ignore messages from users not holding that token. In order to participate on that chain the user needs to get hold of some of the tokens first. Another way to ignore users is to use the Burst messages once again, this time send the user in question a private encrypted message as a password. Everyone in the network can ping a server for response. If server is not responding, the client pinging the server can broadcast it as not responding and the server not responding may be delisted from the whitelist.
At this point (in version 1.0) there is only 1 tx pr block, which means a transaction is a block in itself. To simplify the process the transaction (block) consists of parts from the Sender and a parts from the miner. The miner confirms the sender parts add his own parts and complete the the whole transaction with a hash.
Transactions are structured Burst messages sent to Pchain Txs account. Miners confirms the message by its syntax, semntics and that the sender has the right balance. The whole sender balance is spent in the transaction and change is sent back to sender as new input. The creator’s balance is proved from block 0 (chain creation). Other’s balances are proved by reference to last unspent transactions. To simplify the several inputs and balances, every transaction can spin off a side transaction on receiver side. Spend the previous balance and the newly received amount, send all to itself, (merging 2 unspents into 1 unspent).
Unconfirmed transactions is a distributed FIFO list, where the Unix timestamp from the Burst message sent is what decides the order in the list of unconfirmed transactions. Miners pick transactions from the ordered list where the oldest Tx is the first out.
Transaction parts:Parts set by Sender:
Tx - Tx counter 0,1,2,.. 0 being creation balance
TxID - Tx ID in format AA-BBBB-CCCCCCCCCC (16hex in length), A = version no, B = chain ID, C = counter
Sender - Burst account of Sender
Receiver - Burst account of Receiver
Amount - Amount sent to Receiver
Burst TxID - TxID of the Burst Message holding the whole Pchain tx
Burst Msg - Burst Msg being the Pchain Tx
Timestamp - Timestamp, human readable
Unix Timestamp - Unix Timestamp, seconds since Burst blockchain was created (2014-08-11 04:00:00)
Sender prev - Pchain TxID, last output tx to Sender (Senders’ prev balance)
Sender Input - Amount, prev balance
Sender Output - Amount, to Receiver
Fee - Amount (Fee), for later use
Change (Sender balance) - Amount, new balance>
Receiver prev - Pchain TxID, last output to Receiver (Receivers’ prev balance)
Receiver prev balance - Amount, prev balance
Receiver merge - Amount, from Sender, added to Receivers’ new balance
Receiver balance - Amount, new balance
Prev Tx hash - Hash of prev tx, (SHA256)
Tx hash - Hash of tx, (SHA256)
With the framework users register a Burst account. The account is used in the framework to build a structured message. That message then has that Burst account as sender and needs to be sent the ordinary Burst way from that account to the Pchains Txs account.
The Pchains wallet can be switched to any of the private chains and build transactions, watch latest transactions and balance if present. Since the whole balance is spent on each transaction, the latest transaction with this account as input is the balance on that account. Next transaction marks the input spent and receives a new input (change) which then becomes the new balance.
Miner does his own syncing and investigation of chain blocks and transactions. Thus keeps his own mark of what is correct. When miner wants to start mining, he gets a number in the queue of other miners. That number is the number of a future transaction. When his tx number is next in queue (say block 15), he is sent the hash and block of miner on block 14. He must respond and accept mining block 15 immediately, otherwise next miner in queue will get that chance. When accepted, he gets 30 secs to mine, and investigate all is correct back to his own mark of trusted blocks and transactions. If nothing wrong is found with miner on block 14 and blocks back to trusted point, he publishes his own block and hash to the next miners in queue. If something was wrong at a point, he publishes claim of rollback (fork) back to where all was right. If all was right and he has published block and hash, miner on block 14 gets 1 confirmation and miner on block 15 can then reenter the queue of miners.
A field in transactions is dedicated to fee for possible future use as miner incentive. To prevent attempts on false mining there could be a risk on false mining in place. Say a miner needs to raise a certain amount, thus exposing the account to other miners. Another miner proving wrong that transaction and that block wins whatever first miner is exposed to. As an example, say the miner trying to include a block also is exposed with 100 or 1000 of that token, the first other miner proving him wrong will win that bet. This way, attempts to do something wrong will be of a cost and incentive for other miners to investigate. If nothing is wrong, the miner is refunded. This concept can be used as an alternative to fees. If fees are in place, the miner simply earns the fees.
Miner’s job may include:
All Pchains transactions are sent as ordinary Burst messages. Pchains transactions are therfore preserved in the Burst blockchain and DO NOT DISAPPEAR. Also, there is no way for a hacker to spend your tokens, without also hacking into your Burst wallet and send a Pchain transaction from there. A Pchain transaction contains both sender and receiver fields, and the sender field of course is the same Burst account you are sending the message from in order to be a valid transaction.