How Burstcoin transaction processing works
Every Burstcoin wallet acts as a node supporting transaction processing when connected to the network.
A Burstcoin transaction, such as a payment from party A to party B, is initiated by entering transaction details in a Burstcoin wallet. The intended transaction is broadcast to the network as a transaction object with a transaction ID and transaction details included. Nodes (Burstcoin wallets that are online and fully synchronized) evaluate the transaction’s details to determine if it is valid.
All values for the transaction detail inputs are bounds checked.
- Are all mandatory details specified?
- Is the specified transaction fee greater than or equal to the minimum transaction fee?
- Is the transaction deadline at least one minute into the future?
If there are no exceptions, transaction processing continues as follows:
- The sending account’s public key is calculated using the supplied secret passphrase.
- The sending account’s balance is retrieved from a scan of the blockchain.
The following items are checks in relation to the sending account’s balance:
- Is the sending account’s balance greater than zero?
- Is the sending account’s confirmed balance greater than or equal to the transaction amount plus the transaction fee?
- Is the sending account’s confirmed balance sufficient to cover the transaction amount plus the transaction fee for the current transaction as well as any other transaction from the same account that has not yet been confirmed?
If the sending account has a sufficient balance, processing continues as follows:
- A transaction object is created which includes all of the transaction’s details. The transaction is assigned a transaction number.
- The transaction is signed using the sending account’s private key.
- The encrypted transaction data is placed within a message that instructs network peers to process the transaction.
- The transaction is broadcast to all network peers.
Note: If any of the detail checks fail, the network will respond with an error code and a message.
Valid transactions are added to the ‘unconfirmed transaction store’, a holding area within the ‘mempool’. When a new block is generated, these transactions are prioritized by the block generator and as many as possible are added, subject to a limit on the number of transactions per block (255) and the maximum number of bytes.
Phased transactions are included first, selected according to the block height at which they were accepted into the block chain. If two phased transactions were accepted at the same block height, the transaction with the lower index number is selected first. After all phased transactions are included, regular unconfirmed transactions are included, selected according to the specified fee, and then by timestamp if multiple transactions have the same specified fee. Note: The selection order in not retained when a block is finalized. Transactions will be order only by timestamp. The new block is added to the chain of blocks that make up Burstcoin’s immutable distributed shared ledger. Any transaction that was not included remains in the holding area pending inclusion in a future block.
Transactions are considered to have one confirmation when they are first included in a block. Each subsequent block adds another confirmation to the transaction. Burstcoin transactions are considered reliable after 10 confirmations. Up to 720 blocks can be “re-organized” by the network in case of problems, so a transaction with 721 confirmations is considered irreversible. Transactions with 1,440 confirmations are considered permanent.
The byte order of a send transaction is as follows:
|Length (bits)||Name||Data Definition||Cumulative Total (bytes)|
|8||Type||Transaction type (payment, asset exchange, marketplace, etc.)||1|
|4||TX Version||0 on genesis, 1 currently, added attachments and appendages||1.5|
|4||Subtype||Transaction subtype (example: create bid order with asset type)||2|
|32||Timestamp||Current timestamp where the epoch is the genesis block||6|
|16||Deadline||Deadline in minutes for the transaction to be processed||8|
|256||Sender Public Key||256-bit public key for account sending a transaction||40|
|64||Recipient/Genesis||Recipient of the transaction, genesis for transactions without a recipient, example: assets||48|
|64||Amount NQT||Amount to be sent to recipient, in Planck (1 Burstcoin = 100,000,000 Planck)||56|
|64||Fee NQT||Fee amount, in Planck||64|
|256||Referenced Transaction Full Hash||Full hash for transaction to reference, usually left blank||96|
|512||Signature||Signature of this transaction where this field is zero, the signature must be generated by the private key of the earlier stated public key||160|
|32||Flags||position 1: arbitrary message 2: encrypted message 3: public key announcement 4: encrypted message to self||164|
|32||EC Block Height||Block height of referenced block for economic clustering||168|
|64||EC Block ID||ID of the block referenced above||76|