Bitcoin and related currencies often use an encrypted file, under the name and wallet, to store generated addresses for receiving coins. The Next core used in the Prizm neither simulate this functionality, neither rule it out. Client developers can implement a system in which a private key group for Prizm accounts is stored in an encrypted stand-alone file.
All PZM transactions are considered unconfirmed until they are included in a valid network block. The newly created blocks are distributed to the network by the node (and the associated account) that creates them, and the transaction that is included in the block is considered to be received by one confirmation. As subsequent blocks are added to an existing blockchain, each additional block adds another confirmation to the number of transaction confirmations. If a transaction is not included in the block before it expires, it burns and is deleted from the transaction pool.
Each transaction contains a deadline parameter set to the number of minutes since the transaction was sent to the network. By default, the deadline is 1440 minutes (24 hours). A transaction that was sent to the network but was not included in the block is called an unconfirmed transaction.
If the transaction was not included in the block before the transaction deadline, the transaction is removed from the network. Transactions can be left unconfirmed because they are invalid or distorted, or because blocks are filled with transactions that offer to pay a higher Commission. In the future, features such as multi-signature transactions can use deadlines as a means of enforcing expiration.
Detailed information about creating and processing of a PZM transaction is as follows: - The sender specifies the transaction parameters.
Transaction types change, and you specify the desired type when you create the transaction, but for all transactions you should specify multiple parameters:
The private key for the sending account
The transaction deadline
Optional transaction reference