Transaction Fees

Burstcoin supports sending BURST from one account to another account, one to many accounts, and several advanced transaction types for a single minimum transaction fee.

Minimum transaction fee (sometimes referred to as “fee quant”)

• .00735 BURST (735.000 Plancks).

All transaction types use the following slot-based transaction fee schedule.

1: 0.00735 - 0.01469
2: 0.01470 - 0.02204
3: 0.02205 - 0.02939
4: 0.02940 - 0.03674
5: 0.03675 - 0.04409
6: 0.04410 - 0.05144
7: 0.05145 - 0.05879
8: 0.05880 - 0.06614
9: 0.06615 - 0.07349
10: 0.07350 - 0.08084

This schedule continues linearly up to 1020 for which the highest fee of 7.49700 BURST is charged, each slot holding one transaction.  The minimum fee for each slot is the minimum transaction fee (fee quant) multiplied by the slot number.  The total fees collected for a block where all slots are filled with the minimum required fee is 3827.2185 BURST.

Transactions are assigned to the slot for which their specified transaction fee falls within the fee range for that slot.  For example, a transaction with a specified fee of .03 would be assigned to slot #4 because it falls within the range of 0.02940 - 0.03674.  The amount by which a transaction’s specified fee exceeds the minimum fee for the slot to which it is assigned is not refunded.  It is up to the user to choose a reasonable fee that does not waste funds.

If no slot is available, a transaction remains unconfirmed in the memory pool until a slot becomes available in a future block or until its deadline for inclusion has expired. 

The slot-based transaction fee system serves as a disincentive for creating spam transactions that would otherwise require little or no investment.  This conserves blockchain space and keeps the cost of operating a public node at a minimum.

Examples:

Assuming a block capacity of 10 transactions, transactions with specified fees of .07350, .07000, .05900, and .00800 would be assigned slots as follows:

.07350 to slot 10

.07000 to slot 9

.05900 to slot 8

.00800 to slot 1

The Burstcoin wallet is equipped with a tool that suggests a transaction fee based on the transaction load over the last 10 blocks.  The suggested fees are as follows:

• Budget: 50% probability the transaction will be included in the next 10 blocks
• Standard: 50% probability the transaction will be included in the next block
• Priority: 90% probability the transaction will be included in the next block, 99% probability the transaction will be included in the next two blocks.

The fee suggestion tool is made available through the Burstcoin API.

Transaction Types

Ordinary transactions are those transactions that are subject to the minimum transaction fee:

• send money
• create alias
• transmit message
• issue asset
• order asset

One-to-One Transaction

• Specify a Burstcoin account as the recipient, the amount of the transaction, and the transaction fee.
• Add a message (optional).  The message can be encrypted (visible only to the receiver), or plain text (visible to everyone).  The default is encrypted.
• Click “Send BURST”.

Multi-out Transactions

• Send BURST to up to 128 unique recipients if the amount sent to each is the same.
• Send BURST to up to 64 unique recipients if the amount sent to each is different.
• If the amount to be sent to each recipient is the same, the “Same amount” option should be checked.

Add Note to Self

• This option allows entry of an encrypted note to one’s self.

Custom Deadline:

• Deadlines set the duration of a transaction’s pre-confirmation validity.
• The default, and maximum allowed, is 24 hours.
• If not confirmed by the deadline, transactions are deleted from the pool of unconfirmed transactions and must be be re-issued.

Conditional Execution

Allows for one transaction to be conditioned upon the confirmation of another.  The mechanism works as follows:

• A transaction with hash txhash₁ has been issued.
• Transaction tx₂ is created.
• If the txhash₁ is provided as the “References Transaction Hash” in tx₂,
• tx₂ will only be executed after tx₁ has been confirmed.

Do Not Broadcast Option

The “Do Not Broadcast” option prevents a signed transaction from being broadcast.  When the “Do Not Broadcast” option is checked, the raw transaction details are displayed and must be saved in a separate file.  To broadcast the transaction later, the raw transaction details must be retrieved and entered.  This option is generally used in combination with Offline Transaction Signing.

 

Offline Transaction Signing

The term “offline transaction signing” refers to the practice of keeping private keys on an offline device (never exposing them to the internet).  Individual transactions are signed on an offline device and then copied to an online device to be broadcast.  The transaction that is broadcast contains only a single use signature, so this practice is virtually risk-free.

To broadcast a transaction that has been signed offline:

• Access “Transaction Operations”
• Enter the signed transaction bytes
• Click “Broadcast”

 

Note:  In addition to signing transactions from an offline device, signing can also be done on an online device but still performed locally.  Assuming the computer is malware-free, this is the most convenient option while still keeping private keys safe.  BRS uses this form of signing for its wallet interface through locally run JavaScript.

Technical Information for developers:

Server-Side Online transaction signing

Although it is possible, it would only be considered “safe” to do this using localhost. If you are developing/distributing software, do not present online signing as an option to your clients. You will make them a potential target for malicious actions.

Implementing transaction signing

Transactions must be signed before they can be broadcast.  Use one of the API functions to request transactionBytes from a node. The returned JSON object contains the transactionBytes that represent the transaction to be made.

It is important to use the publicKey argument rather than  secretPhrase for the transactionBytes request.  Also, to set the broadcast argument to false to prevent broadcast.

To sign the transactionBytes locally, refer to these sources below to include the signing functions in your code.

Code sources

• Javascript / Java / Burst Reference Software
• Swift/Obj-C / BurstKit
• C++ / CloudBurst

Pseudocode:

function signTX(unsignedTransactionBytes) { myBytes = unsignedTransactionBytes // keep a copy signature = crypto.sign(unsignedTransactionBytes, passPhrase) // make the signature myBytes.copy(96, signature); // copy the signature over the unsignedTransactionBytes with a offset of 96 bytes return myBytes}

Note: Add signature and TransactionBytes length

Compare and verify your implementation with the requestType: Sign Transaction.

The transaction is now signed and can be broadcast (through POST only):  Refer to BRS API Transactions.