Transaction Processing

Every Burstcoin wallet acts as a node supporting transaction processing when connected to the network.

Transaction Types

Ordinary fund transfers and messaging are just two of the many types of transactions that can be made using Burstcoin.

Transaction Fees

Burstcoin uses a slot-based transaction fee structure.  The lowest fee is just .00735.

Offline Signing

Individual transaction can be signed on an offline device, transferred to a connected device and broadcast to the network using offline transaction signing.  This allows passphrases to be held offline and never exposed to the internet.

Documentation

To improve submit improve this document, provide updates, or recommend improvements, use the submission form at the bottom of this page or visit the documentation project.

How Burstcoin transaction processing works 

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)NameData DefinitionCumulative Total (bytes)
      8TypeTransaction type (payment, asset exchange, marketplace, etc.)1
      4TX Version0 on genesis, 1 currently, added attachments and appendages1.5
      4SubtypeTransaction subtype (example: create bid order with asset type)2
      32TimestampCurrent timestamp where the epoch is the genesis block6
      16DeadlineDeadline in minutes for the transaction to be processed8
      256Sender Public Key256-bit public key for account sending a transaction40
      64Recipient/GenesisRecipient of the transaction, genesis for transactions without a recipient, example: assets48
      64Amount NQTAmount to be sent to recipient, in Planck (1 Burstcoin = 100,000,000 Planck)56
      64Fee NQTFee amount, in Planck64
      256Referenced Transaction Full HashFull hash for transaction to reference, usually left blank96
      512SignatureSignature of this transaction where this field is zero, the signature must be generated by the private key of the earlier stated public key160
      32Flagsposition 1: arbitrary message   2: encrypted message   3: public key announcement  4: encrypted message to self164
      32EC Block HeightBlock height of referenced block for economic clustering168
      64EC Block IDID of the block referenced above76

       

      8 + 13 =