Transactions

Bitcoin keeps track of address balances simply by reading through the blockchain to see what has happened, it's a continual ledger instead of a self contained balance sheet. Bitcoin transactions use a system which include “inputs” and “outputs” and the inputs of most new transactions usually reference the outputs of previous transactions. The mini-blockchain scheme uses the basic input and output concept but the inputs point to accounts in the account tree and the outputs also refer to accounts in the account tree.

The input accounts will fund the coins which are sent to the output accounts. This operation will cause the balance of the input accounts to decrease and the balance of the output accounts to increase. Fees are still used as normal to give priority to transactions and provide incentive to miners. Obviously a transaction should not be accepted as valid if it reduces the balance of any account below 0, or if it requests anything which conflicts with the value of any balance, or it tries anything it doesn't have permission to do.

Technical details

A transaction represents one atomic modification on the account tree. For example: "Move X coins from account A to account B" or "Update withdrawal limit of Account C", etc. Modifications made by single transactions are virtually limitless, but they must have a few important properties. Transaction types used by this scheme can be found on the transaction types page.

• Transactions need to be easily reverted, because we need an efficient way of handling blockchain reorganizations.

When blockchain reorganization occurs, nodes must rollback all transactions which were included in the orphaned branch. This is achieved with an inversion database which holds instructions for undoing changes made to the account tree.

• There must be a mechanism for authorization of modification which can be checked by anyone. For this we use a ECDSA signature scheme similarly to bitcoin.
• The mini-blockchain is designed in such a way, that old transactions can be forgotten, so transaction signing must be done in a way that prevents rebroadcasting of old forgotten transactions while not affecting the ability of the system to handle multiple concurrent transactions.

An example of a bad way to do it is to include previous transaction hashes as a means of making transactions globally unique. Doing it that way would disallow concurrent transaction signing.

Does this scheme use script?

Script is not used within the mini-blockchain scheme. Since the account tree holds the final balance of all non-empty addresses and is not a continuous ledger of transactions like Bitcoin it's not possible to use scripts which must be solved at a later time because transactions in the mini-blockchain may be discarded after a relatively small period of time (the length of the mini-blockchain cycle time).

However, it is still possible to allow more complex types of transactions such as a multi-signature transactions. By not utilizing script we get the advantage of making many aspects of the system exceptionally simpler and at the same we get an increased level of security because every type of possible transaction will be very well defined, eliminating the risk of an unforeseen script causing havoc on the network.

At present the Bitcoin network only accepts a couple of standard scripts for basic types of transactions and every other type of script is considered non-standard. On top of that new script formats are very hard to get standardized. In reality it's best to include the types of transactions that you want to allow before you ever release the client, instead of trying to gradually phase in new types of transactions.