overview

millix operates on a directed acyclic graph, known as a DAG, instead of a blockchain. prior to millix, cryptocurrencies using DAGs had a speed and scale advantage over blockchains that came with two weaknesses:

1. the DAG needs new transactions added constantly to run well.

2. the state of the data in the DAG could never be known without centralized elements coordinating the network and reducing the speed potential of the network. millix is completely decentralized.

millix solves those two weaknesses while also increasing the security of transactions and stimulating the economy for node operators to earn fees.

terms

transaction : contains transaction inputs (funding sources) and transaction outputs (destination of funds).

transaction output : defines where the money from a transaction is sent, making it available for the recipient to use to fund their own transaction.

transaction input : funds new transactions with transaction outputs from previous transactions.

unspent : a transaction output that has not been used as a transaction input to fund a new transaction.

double spend : a transaction output that has already been used to fund a new transaction and is then attempted to be used to fund another transaction.

0b0 transactions : the type of transactions that are automatically generated to consume unspents approaching their expiration date. 0b0 indicates the transaction type and version as stored in table transaction.version. sequential versions of these automatic transactions would be indicated as 0bb0, 0bc0, 0bd0 etc.

key identifier : identifies the wallet related to an address. the same wallet can be running on multiple nodes.

problem: DAG malleability

blockchains only permit a small number of transactions into blocks of transactions that are created in consistent time intervals. this limits their ability to handle large scale transaction volumes, but does make it easy to trust that after a predictable amount of time, it is virtually impossible for the transaction data to change.

transactions on a DAG aren't grouped into sequential blocks and then frozen, transaction attributes such as is_parent, is_stable, is_spent and is_double_spent are recorded within the transaction records, not inferred by inclusion in a block.

a transaction output could be unused and dormant for years, during which time it's data doesn't change. as soon as it is used to fund a new transaction, the transaction output record would be updated to indicate that it is spent. without constantly and repeatedly querying the network about the current state of every transaction record eligible to be updated, which becomes an ever more burdensome computational problem, it is impossible to ever know the state of the network.

solution: hibernate unspents

if the protocol enforces a maximum period of time in which a transaction is allowed to change, the state of the network as it existed just prior to that period of time is known. in the same way that the state of bitcoin is known and agreed upon as of six blocks ago (~60 minutes), the state of millix can be known and agreed upon as of 10 minutes ago. this doesn't mean that millix transactions require 10 minutes to settle, it means that previously the only known state of the millix DAG was the genesis transaction, now the known state is recent and rolling.

on a regular basis each node updates the status of all transaction output records older than 10 minutes from active to hibernating (from status = 1 to status = 2). those transaction outputs are no longer considered valid to be spent, the transaction must be refreshed before they can be used.

unspent auto-consumption transactions

nodes that are online will automatically generate new transactions funded by their unspents that are approaching their expiration date. these automatic transactions can be identified in the database where table transaction.version equals 0b0. as subsequent versions of automatic transactions are released the version will increment to 0bb0, 0bc0, 0bd0 etc.

these transactions are sent to an address belonging to the same private key (key identifier) that the unspent is associated with*. In other words, the node sends a transaction to itself. this causes the node balance to temporarily alternate from available to pending while the automatic transactions are verified by the network. the node can only perform these auto-consumption transactions on unspents related to the active wallet being used by the node.

* as a note, the decision to send auto-consumption transactions to either the same address that the hibernating unspent is associated with or to a newly generated address with the same key identifier is determined by a config setting. setting the config to send auto-consumption transactions to the same address that the unspent is associated results in fewer addresses in the wallet and preserves the balance of an address. while this can be preferable from an address organization standpoint, it would cause an address associated with a customer account or invoice to be inappropriately credited over and over, in which case opting to generate a new address each time is preferable.

verifying unspent auto-consumption transactions

by forcing the creation of new transactions from aging unspents, all unspents are continuously re-verified by the network.

unspent auto-consumption transactions are verified by the network in the same way standard transactions are, they are normal transactions in that sense. there is no special verification logic based on the transaction version.

the protocol enforces that transaction inputs using hibernating outputs or with transaction date greater than 10 minutes old are only valid if they are used to send funds to the same key identifier. the unspent transaction_outputs can't be used to fund any transaction other than to the same key identifier.

benefits

this feature bridges previously unavailable features of a blockchain with the advantages of a DAG, offering a known state of the network while remaining decentralized.

the most trusted millix transactions are those whose entire lineage is verified all the way to the genesis transaction. this genesis level depth of verification requires an amount of computational power that could exceed the value being verified, making it burdensome. by having recent points where the state of the network is more easily known, a less powerful device is capable of achieving a higher level of trust when verifying transactions lineage. as a side effect, transactions can be verified faster by cheaper devices with no loss in transaction security.

another benefit is that legacy transactions created with previous millix versions are constantly being converted to current version transactions. the DAG data is constantly and automatically upgraded to the newest version technology.

in addition to the technical breakthrough to the DAG operation and lowered cost of security for the transactions, systematically generating new transactions also benefits the network economically. more transactions requiring verification means more verification fees paid to node operators and less wealth sitting idle, increasing money velocity.

it is assumed that the feature will cause average nodes to earn as much in fees verifying unspent auto-consumption transactions as they spend in fees to generate their own unspent auto-consumption transactions, making the feature cost neutral for average nodes.

nodes with large inventories of unspents will pay more fees to the network to keep the unspents from expiring. in general terms, it is an economic stimulus where node operators with less wealth stand to disproportionately benefit from the feature at the expense of the node operators with more wealth. funds held in cold storage are not significantly affected as each unspent only needs to be auto-consumed in one transaction before becoming eligible again after coming back online.

to summarize the economic implication: worker nodes are rewarded, cold storage savers are not significantly affected and nodes with large amounts of idle wealth contribute back to the network.

offline nodes

unspent auto-consumption transactions that prevent unspents from expiring can only be done when the node with the private key needed to sign the unspents is online. when a node has been offline long enough for unspents to hibernating they will be processed into new unspent auto-consumption transactions when the node comes back online and re-syncs with the network. during this time the pending and available balance will fluctuate normally until the node coming online is synched.