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:
the DAG needs new transactions added constantly to run well.
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.
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.
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.
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.
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.
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.
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.
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.
millix is an open source cryptocurrency project. millix is fully decentralized, designed for simplicity, transacts at very high speed and very large scale.
work began on the project in spring of 2018 by a diverse group of developers and business professionals. their motivation to create a cryptocurrency protocol with the use case potential of millix came from their backgrounds building:
social network platforms
content management systems
data distribution systems
online financial services
manufacturing and logistics operations
accounting and legal practices
fundamentally, there was a recognition that
which influenced the following set of first principles:
currencies should not be created with debt
currencies should operate at infinite scale
the cost of securing value can't exceed the value it secures
a currency's market value should be proportionate to its fundamental value
participants that increase fundamental value should be compensated
currencies should function without carrying the weight of previous transactions
currencies should work the same throughout the spectrum of transaction values
modern currencies should be at least as simple to use as primitive currencies
simplicity at the edge is only possible with equal simplicity in the foundation
to the extent there is an inverted correlation between utility and a store of value, millix is not intended to compete with the use case or feature set of blockchain projects. the utility that comes from scale and speed has been prioritized, leading to the principles and methodologies described above.
learn more: meet the millix team
case study: the speed and scale of millix
Developers: millix certification for technical and non-technical careers
the total allocation of 9,000,000,000,000,000 mlx (nine quadrillion millix) were created in a genesis event on January 20th , 2020. millix is not being offered directly for sale. instead it will be distributed to participants who support and improve the millix ecosystem.
participants running millix software constantly receive millix for performing protocol related tasks that improve the millix ecosystem, such as storing transaction data and verifying transactions.
the economy is envisioned to allow any participant to incentivize any computing activity by any other participant via fees.
learn more: how can I earn, buy or sell millix?
unlike blockchain cryptocurrencies, millix is built on the logic of Directed Acyclic Graph (DAG) for transaction speed and capacity that increases as more transactions and users are added.
millix is original work and was not built on a copied code base of existing work. millix has no points of centralization. millix has no designed bottlenecks. millix has no hierarchy of participants of capabilities. millix data is natively sharded.
learn more: how does millix data sharding work
learn more: the millix toolbox of trust
learn more: how do transactions work
learn more: how do transactions get verified
learn more: how does the millix network work
the initial millix road map consisted of the following themes:
base organization and functionality
connecting millix protocol to machines for large scale transactions
large scale transaction speed and storage
a community of earning
store and own your personal data
developers: contribute to the millix project
millix is available to download for windows, mac, and linux at millix.org/client.