(c)2018 The MoX Developers <mox@mox.network>
Version 0.8.0 - July 26th 2018
Project Home: https://mox.network/
Document License: Creative Commons Attribution-ShareAlike 4.0
Medium of Exchange (MoX) is a block chain based digital currency and distributed application backplane that introduces significant improvements in energy efficiency, privacy, macroeconomic structure, and performance. A novel consensus mechanism called constrained proof of work (CPoW) is introduced to globally limit the total amount of work performed to secure the chain. This vastly reduces energy use by avoiding an unlimited proof of work arms race while preserving most of the benefits of a block chain including global state objectivity and true decentralization. Privacy is improved via the invisible hands protocol, a money transfer mechanism that fully removes sender and receiver addresses from the chain and renders all transactions anonymous. It's built on straightforward established cryptographic constructions and is always enabled requiring no additional steps from the user. Finally MoX introduces the concept of decentral banking, the implementation of intelligent monetary policies similar to those that could be employed by central banks instead as pure functions of global ledger state. The initial implementation specifies a policy of mild monetary base inflation distributed equitably as interest earned on deposits and in a way that implicitly delivers economic stimulus during times of low monetary velocity. Transaction throughput is improved over other block chain systems with a simpler overall design and a more efficient more richly connected lower latency network protocol. The MoX transaction design very naturally lends itself to off chain settlement, providing a clear path forward for settlement networks whose performance can be many orders of magnitude beyond what any globally synchronized ledger could achieve alone.
A.1. Recommended Further Reading
A.2. Credits
The most popular and successful (as of 2018) digital currencies all suffer from three generally acknowledged problems: weak privacy due to sender and receiver address transparency, low transaction throughput, and the high financial and environmental cost of proof of work. The latter is perhaps the most urgent but all are impediments to widespread adoption.
Privacy coins like Monero have addressed the privacy issue with some success but not the issues of efficiency or performance. Some alternatives to conventional proof of work block chains have attempted to solve cost and scalability problems with alternative data structures like randomized directed acyclic graphs (DAGs). These suffer from other problems like vulnerability to ledger spam denial of service attacks, insecure bootstrapping, greater network overhead, and uncertainty about the global ledger state. DAGs also generally have poor privacy. Still other alternatives to PoW block chains have abandoned decentralization, a choice that reduces a cryptocurrency to a distributed implementation of a proprietary bank database.
Beyond technical problems there exist more complex and controversial macroeconomic issues that no major present generation cryptocurrencies have attempted to address. Chief among these is the problem of deflation. Simply put deflation is when the supply of money is not sufficient to meet demand for money. This causes prices to fall (hence the term) as the real value of money vs goods and services rises. Increasing real money value and declining nominal prices are not bad when considered in isolation but together and in combination with the rest of the economic system they trigger secondary and emergent effects that are largely negative. Some of these arise due to deflation's interaction with other aspects of the economic system while others emerge from human psychology.
Significant deflation increases the real value of loans, compounding real loan interest during what is typically a time of recession and leading to what can become a self-reinforcing cascade of defaults. It encourages investors to simply hold money to realize low-risk gains through monetary appreciation ("hodling") rather than investing in real ventures or making purchases. It reduces liquidity (credit, market maker trading activity, etc.), reducing the ability of financial institutions to reallocate assets and businesses to bridge temporary shortfalls or re-structure debt. Finally it causes nominal wages and profits to fall, leading workers to see themselves as losing ground and businesses to appear less healthy. These perceptual effects can themselves become a self-reinforcing feedback loop that causes people to withdraw from participating in the economy. Applying post-corrective filters to negate these perceptual effects increases the cognitive burden of economic participation.
Most current generation cryptocurrencies are extremely deflationary. Absolute monetary limits or money creation rates that fall exponentially toward zero are combined with breakage due to lost wallet keys, occasional intentional "burning" of coins, and reduced fungibility from poor privacy to yield money systems that are even more deflationary than precious metals or other kinds of commodity money.
Two hypotheses are here advanced on the subject of cryptocurrency and deflation.
The first is that the 2017-2018 peak in Bitcoin's price as denominated in mainstream currencies like USD and EUR was actually a large hyper-deflationary recession in the Bitcoin economy when viewed "through the looking glass" from the perpsecitve of BTC's usefulness as a currency. While correlation does not prove causation it's interesting that during and after this peak many of Bitcoin's largest adopters such as Steam and Stripe abandoned it as a payment mechanism in spite what seems to be continuing growth in the cryptocurrency user base. If the exchange rate peak indicated a positive development in the BTC economy its abandonment for payment would not be expected to coincide, but an exchange rate peak coinciding with abandonment due to loss of commercial utility relative to traditional currencies would be expected to coincide under a deflationary effects hypothesis.
The second is that the aversion to modern and flexible economic policy on the part of libertarians, anarchists, voluntarists, and other advocates of minimal state power and individual autonomy is an artifact of an economic thought constrained by technological limitations that can now be rendered obsolete. The advent of software defined money allows any monetary policy that can be expressed mathematically or algorithmically as a pure function of the economy's state to be implemented fairly and openly without coercion. This decouples economics from politics, freeing thought in both areas from limitations imposed by pragmatic structural incompatibilities.
The MoX project addresses all three primary technical concerns described above while also attmepting to innovate in the realm of monetary policy. Its goal is to offer an efficient and scalable truly decentralized digital currency platform implementing modern flexible and progressive economic policies designed to maximize its utility as a medium of exchange (hence the name). The project also hopes to explore ways that economic opportunity and equality might be improved through intelligent distributed monetary policy.
MoX evolved from an internal project by a presently anonymous decentralized networking company to develop an extremely secure and robust distributed database that can remain coherent and stable over networks that are both unreliable and hostile (as in actively under attack). We're staying anonymous for now due to the large presence of criminals and other malicious actors in the cryptocurrency ecosystem. Hopefully if the present mania gives way to a more rational cryptocurrency ecosystem and/or MoX becomes more firmly established we can comfortably reveal ourselves.
Originally our project was (internally) called "Starplane," a portmaneu of backplane and starfish inspired by the fact that starfish can survive losing limbs and being chopped into pieces. The intended use case was similar to that of etcd or the key/value store component of consul. It wasn't originally intended to be used as a public block chain or digital currency. Objectives included ability to run on small(ish) devices, security against active attack on a hostile decentralized network where the network itself and some existing nodes could be compromised, and robustness under a variety of network service degradation conditions. Target applications included industrial, financial, and military networks designed to operate in unreliable or actively hostile environments.
We chose a Bitcoin-like block chain for the simple reason that Bitcoin and its analogs have remained stable for years on the public Internet in the face of a billion dollar bug bounty and constant attack by everyone from skilled independent black hats to organized crime and (very probably) nation states. While existing cryptocurrencies can be criticized on many grounds, robustness is not among these. Few other truly decentralized systems (and none suitable for our needs) have withstood this amount of abuse while maintaining anything close to a nominal quality of service.
Block chains seemed appealing for many reasons but they had a major shortcoming: the high cost of proof of work and the relative vulnerability of the chain if that cost is not paid. Proof of work systems converge based on the idea that the "correct" version of reality is the one that carries the largest investment. This mechanism works but it's a computational thermodynamic protection racket. If the always escalating cost of mining work is not paid the chain becomes vulnerable to anyone who is able to pay that cost. This is already a problem for less popular proof of work coins, but it's a major issue for a private block chain designed to survive attack. An attacker with access over the Internet to commodity cloud computing could easily overcome the mining power of a small network.
A master certificate authority authorizing block creators solves the problem of an external "51% attack" but does not solve and may even worsen the problem of compromised nodes. If the network is split or under attack it may not be possible to reach a certificate authority to obtain a certificate revocation list, allowing compromised nodes to wield significant power unchecked.
A technique called "hash chain lottery" and later renamed "constrained proof of work" was invented to globally limit the work required to amend the chain so large devices have little advantage over small ones. MoX was born when we realized this mechanism was likely secure enough all by itself. It didn't need a signing authority. The MoX code base still supports one but it's not used on the public chain.
CPoW has the potential to solve the massive mining energy use problem. Inventing it gives us the opportunity to introduce something new to the cryptocurrency space. We've decided to take that opportunity to also attempt innovation on other fronts like transaction privacy, performance, and economics. The privacy and pragmatic performance innovations in MoX also emerged from our distributed database work, while the economic ideas behind the project emerged from multiple private conversations among ourselves and with other economics and cryptocurrency enthusiasts over time.
To understand CPoW the block chain and classical Nakamoto consensus based on proof of work must be understood first. An in-depth video explanation of Bitcoin's block chain can be found here with discussion of the chain itself and mining starting around 10 minutes into the video. The video also discusses other aspects of Bitcoin like how transactions work. This information is useful to know as background even though MoX's transaction system is different. The remainder of this section will assume familiarity with the original Nakamoto design and won't bother explaining aspects of the system that CPoW does not change.
CPoW preserves objectivity and decentralization, the most important characteristics of conventional proof of work, but at a significantly lower cost. Instead of replacing work entirely it takes a "tame the beast" approach. It uses a system built on hash chains and verifiable commitments to future values to place a fair limit upon the global amount of work that can (or should, or need, or must) be performed. Other than this global limit and how blocks and chains are scored, the remainder of the algorithm is very similar to Bitcoin.
A hash chain is a series of values obtained by starting with a secret, hashing it, hashing the output of that hash, and so on up to the desired chain length. You can construct a hash chain with length four at the Linux command line like this:
echo 'The bear is sticky with honey.' | sha256sum
echo 'The bear is sticky with honey.' | sha256sum | sha256sum
echo 'The bear is sticky with honey.' | sha256sum | sha256sum | sha256sum
echo 'The bear is sticky with honey.' | sha256sum | sha256sum | sha256sum | sha256sum
On Mac and BSD systems you will need to do this before trying the above example:
alias sha256sum='shasum -a 256'
If you know the final hash and someone gives you the second hash in the chain, you can easily check that it's a member of the chain by hashing it two more times and comparing the result. If it's correct you will obtain the final hash. It is however effectively impossible to go backward. You can't obtain hashes "above" those that have been revealed because good cryptographic hash functions are not reversible. The final value in a hash chain therefore represents an immutable public commitment to a list of still secret pseudorandom values. It's like dealing poker hands without a dealer and being able to prove to the table that you're not modifying your hand but without revealing your cards. The strong and unpredictable pseudorandomness of hashes means these self-dealt poker hands can even be fair since their values are randomly distributed and difficult for even the self-dealer to predict.
These properties make hash chains useful for all kinds of authentication and signing applications. Famous cryptographer Leslie Lamport did a lot of work exploring hash chains and used them to implement clever cryptographic systems like the S/KEY one time password scheme and Lamport signatures.
In CPoW hash chains are central to fair and unpredictable global work allocation under a global work limit. They allow block creators to stake a rigid (in the cryptographic sense) ahead-of-time claim to an unpredictable pseudorandom sequence of values without revealing those values. These secret but immutable values are then used to compete for the right to create blocks within what amounts to a collective distributed mining pool.
A MoX block creator is called a minter as opposed to a miner. Each minter possesses a hash chain whose length is equal to the maximum number of blocks it could have an opportunity to mint. This is in terms of a range of block heights, not blocks actually won, since each possible ticket corresponds to one and only one height. A cryptographic signing key pair is also a part of a minter's identity. The latter plays no direct role in consensus but hardens the chain against cointerfeiting or network level attacks.
When creating a block a minter must include (as a field) the hash from its hash chain that corresponds to the block's height. This value is called a minter ticket and represents a single iteration of a distributed "mining" work function. When nodes receive blocks they can verify its value and position in the hash chain by repeatedly hashing it as described above. Minter tickets are used to compute a block score that is then used to implement block chain consensus.
Block scoring begins with a scoring hash. This is computed by hashing the current block's minter ticket followed by the scoring hash of the previous block. This implies that each scoring hash is dependent on the current ticket and all preceding tickets all the way back to the genesis block.
The incorporation of all previous blocks' tickets into the scoring hash means that a minter's block scores are dependent on the tickets put forward by other minters. Barring extreme levels of minter collusion it's not feasible to know ahead of time what these will be, and even with collusion the attack is difficult and fragile as any successfully minted block by any non-colluding minter fully randomizes all subsequent scores. The ability to unilaterally amend the chain for a prolonged period of time requires control of much more than 51% of the minter population.
Fields other than the minter ticket are not used in scoring because these fields are not rigid. They have additional degrees of freedom that could be adjusted by the minter or other colluding minters to permit back-door re-introduction of unlimited iterative work.
Once the scoring hash is computed it's compared to a difficulty threshold defined in the active chain policy. Unlike conventional proof of work this is a constant, not a computed and constantly adjusted variable. If the hash is greater than this threshold the block is considered invalid and is discarded. Next a check is performed to see if this is an old minter that has timed out (died), in which case the block is discarded. Otherwise the block is scored by starting with the integer (floor) log base 2 of the scoring hash and then adding various bonuses if they apply. The nature of the difficulty threshold and these bonuses is elaborated upon in the next few sections.
The following rough pseudocode perhaps more clearly explains the algorithm:
scoringHash := hash( this block's ticket | previous block's scoring hash )
if scoringHash > DifficultyThreshold
reject block
else
score := floor(log2(scoringHash))
if ( block minter has already created blocks )
if (height - last minted block height) >= timeout
reject block
else
score = score + active minter bonus
if ( minter has been assimilated )
score = score + assimilated minter bonus
end if
if ( minter pre-announced prior to joining )
score = score + pre-announcement bonus
end if
end if
end if
end if
The chain score is merely the sum of all block scores. The best or "longest" chain is the one with the highest score. If there is a tie it is broken in favor of the chain whose blocks were received at the earliest local time (not block timestamp time) just like Bitcoin. In the incredibly unlikely event of a double tie the chain ending in the block with the highest block ID (content hash) is chosen.
The imposition of a global work limit apportioned to minters makes the fair introduction of minters and the management of the minter population very important. Completely free introduction of new minters would open the door to a variety of Sybil attacks and attacks that defeat the purpose of CPoW by re-introducing iterative work.
Three different bonuses and a timeout implement an interlocking set of integrity checks that bound the minter space and give rise to a minter life cycle:
All three of these bonuses are substantial, making them behave more like hard rules. Scoring bonuses are used instead of just rejecting blocks based on boolean flags to simplify chain scoring and best chain determination logic as there are rare cases where there may be no best chain whose blocks all earn a bonus.
Existing active minters always win due to a large active minter bonus, but sometimes no active minter is able to clear the difficulty threshold. This is called a stalled chain and provides an opportunity for new minters to introduce themselves. The probability of a stalled chain can be computed with this formula:
P(stalled chain) = 1 - N * D * (1 - D)^(N - 1)
In this formula D is the probability of any score clearing the difficulty threshold and N is the number of active minters. It was derived by considering the binomial distribution probability mass function for one success among N events with probabaility D and then simplifying algebraically. Subtracting the result from one converts probability of success into probability of failure (stall).
As the minter population grows the probability of a stall and thus of new minters being admitted approaches (but never quite reaches) zero. The difficulty threshold therefore sets the stable population size and by implication the global cumulative amount of work done for each block. The active minter population is effectively a mining pool with evenly divided work units where membership is awarded by fair lottery and whose hash rate per block equals its size.
A new minter becomes active after it adds its first block to the chain, but full assimilation requires minters that already existed prior to this new block to approve it by adding subsequent blocks. The fraction of pre-existing minters that must build on the chain to achieve assimilation is the assimilation quorum.
This is effectively a voting mechanism since on a block chain adding a block implies approval of its ancestors. Minters could refuse to build on a block that seemed suspicous or bad in some way. This can also be thought of as implementing a probation period to rate limit new entrants.
The assimilation criteria protects the chain from offline simulation attacks, a type of zero cost or "nothing at stake" attack. In an offline simulation attack the attacker forks the chain at a specific point (like when they obtain a minter through normal means) and then simulates alternative chains until one is found that scores higher than the current best chain. The assimilation bonus ensures that such efforts will be impractically computationally expensive. The cumulative score of the new chain would have to exceed the score of the main chain (that's constantly being extended) plus the assimilation bonuses of legitimate minters while coping with the randomizing interdepencence of hashes on a hash chain, block and minter work requirements (2.7 and 2.10), and combinatorial interaction among simulated minters. The score of the main chain would need to be exceeded by a significant margin to rule out main chain minters re-minting after any of the new chain's blocks since the new chain would furnish all pre-existing main chain minters with an entirely new set of possible scores for their tickets.
The pre-announcement bonus gives priority to new minters in minting their very first block when they pre-announce themselves before doing so, an act that limits their ability to iteratively optimize their hash chain. A minimum elapsed time (in blocks) is required between the announcement and the first block created to allow sufficient entropy from other minters' tickets to randomize the first minted block's score.
Announcement is done by storing the minter's ID (the content hash of the minter record) to the chain's key/value store (3.4) as the (masked) record key. The value of this record is arbitrary and could be padding to randomize its length. This can defeat any possible attempt by selfish minter cartels to censor minter announcements by guessing them based on value length. Announcements are indistinguishable as such until the minter reveals its ID (and thus the announcement's key) in its first created block, at which point it's too late to censor anything.
Without pre-announcement a node can generate and cache huge numbers of potential minters and pick the best one at the next stall, effectively re-introducing a form of work beyond the global work limit. By the birthday paradox their probability of successfully extending the chain at the next stall would increase exponentially with storage space. The pre-announcement bonus "nerfs" this tactic by ensuring that minters that instead pre-announce themselves before they add their first block (when they aren't yet able to determine its score) always have priority over those that don't. Note that minter work requirements (see next section) also help to defeat this attack by making it more expensive.
While CPoW is not a proof of stake system this pre-announcement does cost something. The cost of a pre-announcement transaction is either financial or computational if the chain's policy allows free non-monetary transactions (3.5). This plus the minter work requirement discourages spamming the chain with announcements.
The only reason pre-announcement is not absolutely required is to prevent a permanent chain stall if nobody is actively pre-announcing and a regular stall occurs. In this case a new minter that hasn't pre-announced can jump in and keep things moving.
Each minter record contains a one time proof of work field that must be filled with a work hash of the minter's final hash chain value. Work is done using the wharrgarbl (5.3) work algorithm. The difficulty requirement for this is a constant in the chain's policy and is set high enough to require on average a non-trivial amount of time to create a new minter.
This is a defense in depth measure to increase the difficulty of any attack or unfair minting tactic that depends on iterative minter search.
Active minters must keep creating blocks. If a minter fails to add a block after a minter timeout measured in blocks it's marked as dead and can no longer create blocks. This prevents new minters from being created and withheld until some threshold is reached and a hostile fork or other attack can be attempted. The timeout is set to a multiple of the equilibrium active minter population.
There is some probability that an active minter could by chance fail to win a block for long enough to time out. This imposes a soft probabilistic life span on active minters. This life span coupled with permanent death on timeout prevents minters from living long enough to encourage the formation of active markets in minter identities. Minter markets could encourage centralization or might allow a malicious actor with sufficient funds to accumulate minters to accomplish an attack. It also makes theft of minter secrets less valuable to avoid encouraging widespread attacks against nodes.
Blocks are rewarded from a fraction of transaction fees paid by the transactions they validate. Remaining transaction fees are "burned" and therefore are implicitly recycled by the inflation targeting algorithm (4), effectively redistributing them across the economy.
This fractional reward is to avoid over-rewarding minters and thus incentivizing extraordinary efforts to circumvent the work or minter limit. It also keeps minters from being able to spam the network by adding endless transactions while recouping 100% of their fees or from gaming the inflation targeting algorithm with wash trading. A minter should earn enough to operate the node plus some profit but not so much that minting becomes a primary economic activity and minter identities become coveted commodities.
There is no additional block reward beyond transaction fees in MoX. Newly issued coins are distributed through monetary base inflation via interest earned on deposits (4).
Only minters that are both active and assimilated can claim block rewards. This avoids incentivizing attempts to create large numbers of ephemeral minters, mass denial of service attacks against active minters, etc. Transaction fees in blocks that cannot claim a reward are fully recycled.
Since work is constrained and difficulty is not adjustable the work mechanism cannot be used to enforce timing discipline on the chain. Block timestamps are used instead.
Block timestamps are subjected to a sanity checking rule similar to that in effect for Bitcoin but with tighter parameters. Block timestamps must be greater than an average of the timestamps of past blocks plus a target block interval (adjusted for the interval between the blocks averaged) and must not be more than a very small fuzziness tolerance value in the future (relative to network time). Nodes in MoX must have somewhat more accurate clocks than Bitcoin nodes.
The use of timestamps to enforce block rates might result in more timing inconsistency than conventional proof of work but this is tolerable as long as the rate remains within reasonable bounds.
A relatively modest and fixed proof of work is required for each block as a final defense in depth against flooding attacks as well as against simulation and other attacks that rely on an ability to rapidly generate a lot of blocks. The chain is likely secure without it but the paranoid live longer and attacks only get better.
A MoX transaction consumes one or more inputs to create or modify one or more outputs. A sorted list of inputs and outputs is all a transaction contains.
The most significant difference between typical cryptocurrency transactions and MoX transactions is the identity of the signatory or "witness." A MoX transaction is signed by its inputs, not its sender. Sender and recipient addressing is an added convenience feature that doesn't even exist at the transaction level.
In MoX money is held by ephemeral entities called deposit tokens. A deposit token is a cryptographic public signing key identified by a token ID. The token ID is just a cryptographic hash of the key.
Deposit tokens used as transaction inputs are comprised of the full token public key and a signature of the enclosing transaction. An input deposit token's full value becomes available to be applied to transaction outputs and fees, with any unclaimed value being recycled. A token deposit output contains only the target token's ID and an amount to deposit to that token.
A token can receive any number of deposits but can only be spent once. A spent token in an input or an output causes a transaction to be rejected. Technically it would be possible to allow re-use of tokens within the current system but this is explicitly disallowed for future-proofing reasons. It's bad for privacy, would make certain future features like sharding or second level defenses against double spending harder to implement, and is not compatible with several candidates for very compact post-quantum signatures. The token ID space contains 2^256 possible IDs, making a token ID collision before the sun becomes a red giant and incinerates the Earth unlikely.
The transfer of funds using ephemeral deposit tokens is termed the invisible hands protocol for reasons that will become obvious. It operates in two ways: receiver initiated invoicing or sender initiated unidirectional transfer to an address. The former requires one on chain transaction while the latter requires multiple transactions.
The fastest and cheapest (in terms of transaction fees) option is to use an invoice to send a solicited payment. This is possible if the funds transfer has been pre-negotiated between both parties, such as when checking out at an e-commerce site or discussing a sale in a private chat session. The receiver starts the process by assmebling an invoice, a list of one or more token IDs that should receive funds (plus meta-data), and sending that invoice to the sender (off chain). The sender can then execute a transaction sending funds to these token(s) while also allocating any remaining overflow funds from the input tokens consumed back into other tokens under their control. The transfer is complete when this transaction is confirmed and the receiver's tokens show an increased balance.
If the sender and the receiver do not know each other or have not pre-negotiated the transfer an alternate slightly slower mechanism called a token handoff can be used to send an unsolicited payment with multiple transactions. In this method the sender first obtains one or more tokens whose balances add up to the funds to be sent plus transaction fees. If the exact amount isn't available by selecting pre-existing tokens the sender must execute a transaction to shuffle and reallocate funds. The sender then creates an envelope (see the next section) to the recipient's address and seals inside the secret keys associated with the tokens carrying the balance to be sent. The sender sends this envelope on chain (in a separate transaction from any shuffling for privacy reasons) or via off chain signaling if available. When the receiver gets the envelope they decrypt it, obtain the token secrets it contains, and execute a claim transaction to claim funds into tokens whose secret keys they control. The transfer is not final until the claim transaction is confirmed. The sender may optionally cancel the transfer before funds are claimed by executing another transaction to move sent funds to new or different tokens. This can be done to implement a transfer timeout to prevent loss of funds sent to a dead address. It's not a double spend vulnerability since it causes the claim transaction to fail and thus the transfer to never complete.
All of these transactions look identical on the block chain and since inputs authorize their own expenditure there are no easily identifiable actors. Picture a room full of invisible people exchanging bills and coins. Bundles of cash float around under the direction of mysterious forces. Another way of considering the privacy features of this system is that it practices consistently and by default the security techniques required to use transarent sender and receiver block chains like Bitcoin privately. All addresses are always ephemeral and are never re-used to send funds to multiple recipients.
Since ephemeral tokens are inconveient to handle manually and receiver initiated invoicing is not always desired, MoX contains an addressing and messaging system capable of providing the familiar "send money to address" user experience common to other digital currencies. It could also be used for invoicing, though this is usually not necessary. This system is highly obfuscated and anonymized to preserve privacy.
MoX addresses are concatenations of two public keys. In string format they look like:
m02BRTpVNCmc2pEQUNLbnZcdvAxZbtR2C32VLetBqSNErYQi1cCAw4aViAR1xKEobt7NTVnRRMoMkoDyFJVhoYwFh5QVCCYcG7ACKhHsETFVZKmbogjGZBC
Addresses are string encoded with base58 (Bitcoin alphabet) and contain a CRC check to detect errors and a chain identifier to avoid using them on the wrong MoX chain (e.g. a test or private chain). The "m0" prefix denotes a MoX address and since zero is invalid in a base58 address these addresses are hard to accidentally misuse with another currency.
Using an address it is possible to send an encrypted envelope to the address holder. Envelopes can be sent on-chain by creating a transaction with an input to pay the required transaction fee and the envelope itself as one of the transaction's outputs. They can also be sent via other mechanisms.
The typical use case for envelopes is to send deposit token secret keys. When a recipient address holder's wallet software receives and decrypts an envelope containing a set of token secrets it can automatically generate and submit a claim transaction. Envelopes can also contain invoices, transaction meta-data such as order or invoice numbers, e-mail addresses, signatures, etc.
Addresses contain a Curve25519 outer public key and a NIST P-384 inner public key. The inner key protects envelope payload while the outer key and its hash provide a way to allow selected nodes to match envelopes with recipient addresses (but not decrypt their contents, which are still protected by the inner key) for efficient receipt of envelopes sent on chain. These two public keys are used to generate two ephemeral symmetric encryption keys (by way of ephemeral key pairs whose public keys are also sent) and encrypt the envelope payload twice.
The outer and clearly visible layer of an encrypted envelope is prefixed by four envelope fingerprint bytes (discussed below) and a partially masked ephemeral public key. Key masking is done by encrypting the first 16 bytes of the ephemeral key with AES using a hash of the outer public key as its key, making it impossible for third parties who do not know the recipient address to attack the outer ephemeral key by any present or future means. This is followed by an AES-256 GCM authenticated encryption envelope containing the inner layer. The inner layer is like the outer layer but minus the finterprint prefix and using the inner public key and a compatible inner ephemeral key to initiailize AES-256.
Envelopes are, like unsigned PGP/GPG messages, one-way encrypted messages to a recipient address. The sender address plays no role at all in envelope encryption.
Envelopes are almost pure "noise." There's nothing about an envelope that can be used by a naive third party to group it with others by recipient with more than a thin statistical margin (around 0.002% confidence). Even if you know a given public recipient address it's only possible to use fingerprint bytes to determine which envelopes belong to that address with an accuracy of one in 65,536. There won't be any false negatives but plenty of false positives. The busier the chain is the more useless this becomes. In any case matching an envelope to its recipient only confirms that some message was sent that is likely a money transfer. Nothing about envelope plaintext ties it to any token.
To exactly match envelopes with their recipients requires an address's discriminator. Sharing this discriminator is how the owner of an address authorizes a MoX node to match envelopes on their behalf. The address discriminator is the secret key for the address's outer public key and the first 16 bytes of the hash of the outer public key (the address key, not the ephemeral one). The discriminator matching process starts with this 16-byte hash. Each of the four fingerprint bytes at the start of an envelope were picked at random from these 16 bytes, so using the hash portion of the discriminator a much shorter list of candidate envelopes can be obtained by selecting those envelopes where each of their fingerprint bytes are in this set. This is a very fast search and narrows the pool of all envelopes on the chain to a subset of one in 65,536 of the total population. Exact matches are made by trial decrypting the outer envelope and authenticating with GCM. Since the inner envelope is still encrypted this does not reveal envelope contents.
Curve25519 and AES-GCM are fast. Outer envelope trial decryption can be performed at a rate of about 24,000 envelopes per second on a single core of a 2.9ghz Intel Core i7 CPU (2018). If the network were handling 50,000 envelope mediated transfers per second (far more than are possible today), a single core of such a CPU could search all envelopes for ten years worth of transactions in about three hours. These numbers were computed from the performance of a naive Go implementation. There are numerous things that could be done to optimize this further by for example caching elliptic curve computation intermediates, more efficiently pipelining data from storage, or implementing it in very low-level code using CPU vector instructions or GPU worker programs.
The discriminator itself does not contain the full address, but it is quite easy to check whether a given discriminator matches an otherwise known address. If better privacy is desired the most secure way to use discriminators to match and receive on chain envelopes is to run a private node so the discriminator is never shared with any third party. Another approach is to share the discriminator with select nodes on or via anonymity networks like Tor and I2P.
MoX implements a simple on-chain encrypted database for small data objects. Records are added or updated by posting them to the chain as outputs in a transaction whose inputs include a sufficient transaction fee. The eternal life span of the chain means that this key/value store keeps a somewhat ordered (at the resolution of blocks) collection of values rather than a single value for each key. The latest value or some subset of all values for a given key can be retrieved.
Keys and values are anonymized in this system by taking the plaintext key for an entry, hashing it twice, using the middle (hidden) hash to encrypt the value (with AES-GCM), and using the outer hash as the publicly visible record key. Records' plaintext keys and values cannot be read by anyone who does not already know the plaintext key, making the MoX on-chain database selectively private depending on whether or not keys are published and to whom.
If the first writer of a key wishes to prohibit others from adding values to the same key they can protect it with an update key. An update key is a public key that must sign subsequent updates. This key can be changed later as long as the change is also signed.
The key/value store exists to support distributed applications where the code runs at the edge and the data is stored on the chain. These could include name resolution systems similar to Namecoin, identity management and authorization, messaging, voting, marketplaces, and more. Distributed apps of this type differ from smart contracts in that the code does not live on the chain, only the data. Large data objects can't (affordably) be stored on the chain but these can be handled by storing things like URLs, BitTorrent magnet links, or IPFS hashes. The key/value store is also used for minter pre-announcement (2.6), leveraging ordinary user use of the key/value store to hide these to eliminate potential exclusionary censorship by existing minters.
Chain policy may permit and set a difficulty threshold allowing the byte overhead or other non-monetary portions of transaction fees to be paid with a non-trivial amount of computational work a.k.a. "hashcash". This is done by creating a hashcash transaction input containing the required work. This allows transactions that do not transfer money to be free, at least in MoX monetary terms.
"Free" hashcash transactions allow nodes to bootstrap themselves as minters with full minter pre-announcement (2.6) even if they do not yet possess a monetary stake. Node softawre can start minting by default with zero user interaction, increasing the diversity of minters and thus helping maintain decentralization. Free transactions are also useful to enable distributed applications using the key/value store to function to some minimal degree when first installed by a user who hasn't yet provided a source of funds. This reduces the friction of application adoption.
The difficulty threshold for this work is set high enough to be costly to buy (in quantity) as cloud computing and to be very noticable if done in the background by a web page or a botnet agent on a compromised system. Paying for a transaction with actual MoX coins should ideally be cheaper as well as faster than using computational work.
Decentral banking refers to the implementation of modern monetary policies similar to those enacted by central banks by way of transparent pure mathematical functions of the global state of the economy.
The decentralization of central banking is enabled by the fact that a block chain is an objective globally transparent ledger. While the invisible hands protocol anonymizes on-chain activity with regard to senders and receivers and allows amounts to be subdivided arbitrarily among tokens, global aggregate balances and money flows remain visible. Coupled with the strict and timestamped ordering imposed by the block chain this allows a variety of statistics to be computed from the chain including the global money supply (similar to M0), first-order monetary velocity, mean and median transaction value (and thus estimations of the price level), and so on.
A MoX block chain carries with it a monetary policy. In the present implementation the policy is set in the genesis block and can only subsequently be changed if the code is changed to allow this, but mechanisms for on-chain governance could perhaps be explored in the future. In a broad philosophical sense the sum total of all MoX program code also makes up the active policy, but the policy as described here is a data structure containing key tunable constants that strongly influence macroeconomics and other central aspects of the chain.
The policy contains a number of parameters, but those directly impacting macroeconomics are:
Two inflation policy types are presently supported: ConstantRate and LogisticRamp. The former is self-explanatory while the latter takes the inflation rate from a starting value to an ending value over a period of time using a formula that yields a logistic or "S" curve. Rational integer math including a rational integer Padé approximant of the exponential (e^x) function are used to calculate this curve to avoid floating point variation across langauges and platforms.
Parameters in the logistic ramp inflation policy are:
Deposits in MoX earn interest. This is how new money is issued. Unlike interest on a bank account interest on MoX deposits is not realized over time as actual growth in nominal deposit amount. Instead it is computed and applied at the moment a deposit is spent based on how long it has been since the deposit was made and on how well inflation is keeping up with the target.
Two statistics about the global money supply are maintained by MoX nodes: M0 and M1. M0 is the sum of all unspent deposits, but not including interest. M1 is the ideal target money supply, meaning what the money supply would be if inflation were fully realized and all interest were redeemed since the genesis block. These are close to the traditional meanings of M0 and M1 as base currency and base currency plus withdrawable demand deposits.
M0 and M1 must both be computed on a block by block basis and are calcualted using rational integer arithmetic to avoid floating point result variation. M1 does not depend on balances and could in theory be calculated overall, but it must be computed block by block like M0 due to integer truncation on division of rationals.
The fact that new money is only created on spend means that M0 will almost always lag M1. Computing ((M1 - M0) / M0) yields the instantaneous inflation rate that would be needed to close this gap. Note that the inflation rate is never allowed to be negative. In the unlikely event that M0 exceeds M1 inflation will be zero until M1 catches up.
When a token is spent its actual value is computed from the sum of the cash values of each deposit that was made to it in the past plus interest earned on each since that time under the current instantaneous inflation rate. Each deposit to a token must have its value calculated independently since each was made at a different time. Block timestamps are used for inflation calculations to allow inflation rates to be expressed as standard annualized percentages that are easy to understand.
This calculation is overall more complex than simply applying the target inflation rate to deposits because it has a secondary macroeconomic objective. The instantaneous inflation rate computation has the side effect of implicitly applying economic stimulus during times of low monetary velocity. Unlike stimulus and quantitative easing in centralized hierarchical fiat money systems the stimulus delivered by MoX is distributed equitably across the economy. When the MoX economy enters recession money is dropped from helicopters.
This algorithm has other beneficial side effects. Any coins "burned" (like transaction fees beyond those redeemable by minters) are no longer counted as part of M0. This boosts the instantaneous inflation rate so as to implicitly recycle these coins back into the economy. The realization of interest on spend also avoids depositing new money to dead tokens such as tokens whose keys have been lost. If interest were distributed to lost tokens this would bias the overall inflation rate downward by an unknonwn amount, throwing off other potential macroeconomic calculations as well as reducing the effectivness of the existing model.
MoX inflation is gameable to some small extent. A bot could watch the instantaneous inflation rate and shuffle money around between its own tokens when the rate is high. Fortunately this is not a serious problem and may even have beneficial side effects. It's intrinsically self-limiting since it would only be profitable if few people do it, and it would dampen out extremes in the inflation curve. It would also slightly improve privacy by creating noise. Any privacy network that uses traffic anonymization and obfuscation (like Tor for example) depends in part on there being enough usage to make correlation of events in time difficult.
Note that interest in this system means almost the opposite of what it means in the US Federal Reserve system and similar money systems. Interest here is the rate of new money creation not its rate of removal. A higher interest rate here is analogous to a lower US Federal Reserve interest rate or a "negative" rate.
The following cryptographic algorithms and modes are used in the current MoX reference design:
| Algorithm | Mode | Role(s) |
|---|---|---|
| AES-256 | GCM | Envelope encryption (both layers), network transport encryption, and value masking in key/value records. |
| AES-256 | ECB | Single 16-byte block masking of the outer ephemeral public key in envelopes (not security critical). |
| SHA-384 | Chained with SHA-256 to create the ShaSha256 compound hash. | |
| SHA-256 | Block scoring hashes, minter hash chain, chained with SHA-384 to build ShaSha256. | |
| ECDHE | NIST P-384 | Inner envelope layer encryption, network transport encryption. |
| ECDSA | NIST P-384 | Transaction signing (tokens), block signing, key/value entry authentication. |
| ECDSA | secp256k1 | Supported for tokens to allow address-to-token mapping from Bitcoin, Ethereum, etc. |
| Curve25519 | Outer envelope layer encryption and discriminator matching. |
These are used to construct all higher order cryptographic constructs including the block chain, minter hash chains, transaction and block signatures, masked key/value pairs, transaction and block IDs, block scoring hashes, transport encryption, and anonymized envelopes.
Excepting Curve25519 (which is used for the less security critical outer layer of the envelope) all of these are NIST approved NSA Suite B algorithms. Certified algorithms were chosen because in addition to operating as a public block chain MoX was designed with specific private applications in mind involving financial and/or US government use cases. These often mandate certified cryptographic algorithms and require FIPS certification. Since the Dual EC DRBG scandal and information about project Bullrun was leaked by Edward Snowden there has been some concern over the NIST curves but so far no actual evidence has emerged for vulnerabilities. These curves are still recommended and in use for US government intelligence, diplomatic, and military applications up to top secret security classification. It's hard to imagine this would be the case if these curves were known to be weak, especially in an age when agency compromises by foreign black hat hackers and insider leaks are commonplace.
While there are no known attacks against anything approaching full round SHA-256 (and a massive bounty on any effective attack due to Bitcoin mining), a stronger method of hashing for the most critical identifiers like transaction IDs, block IDs, and token IDs was desired. To accomplish this while still building on standard NIST and Suite B algorithms a chained compound hash called ShaSha256 was created. ShaSha256 is:
ShaSha256(x) = SHA256(SHA256(SHA384(SHA384(x))))
This provides an enormous amount of additional security margin. Even if SHA256 or SHA384 are weakened or a large scale quantum computer is developed this should have little impact.
The Wharrgarbl momentum hash algorithm is based on Daniel Larimer's momentum memory-intensive work function. It relies on finding collisions between hashes using a sort of birthday attack via a local memory cache. The result is slow to compute since many hashes must be tested and cached but fast to verify since all a verifier needs to do is to check that the result accomplishes one collision. Its name is taken from a classic meme that seemed appropriate given how it works.
Our version begins by hashing the input with SHA-384. A series of threads then search using a common key/value map for cases where a hash (SHA-256) of this value in combination with a 64-bit nonce and masked for a certain number of target collision bits collides with another hash value produced using a different nonce. The number of bits to be collided determines difficulty. Final output consists of a SHA-256 hash of the original SHA-384 hash and the two colliding nonces followed by the colliding nonce values themselves.
The following list summarizes the known security implications of a break in each core algorithm:
For all the above cases only practical and relatively catastrophic breaks are of immediate concern. Theoretical or "academic" breaks might encourage an upgrade for the sake of safety if they seemed likely to lead to further breaks or were on the edge of practicality.
This section is under development. A deeper discussion will be added later once the protocol is solidified before phase I release.
The MoX network protocol is a very simple UDP messaging protocol designed to efficiently support a low latency richly connected mesh model. It's very simple, but if it proves too simple it could be switched out for something smarter like QUIC. It implements very basic encryption, which isn't strictly a requirement as the chain is secure without it but helps to protect privacy and defend nodes from network-level attacks.
The flow control implemented in the MoX wire protocol is based on a continuous maximum outbound rate model, not an adaptive model. It could be made adaptive fairly easily but the nature of a cryptocurrency network is such that there is a minimum bandwidth requirement to remain meaningfully synchronized. There's not a lot of point in running a full node if it doesn't have enough bandwidth to keep up with the chain.
The send queue employed by the protocol implementation guarantees fair distribution of bandwidth among outgoing messages.
This section briefly discusses numerous areas of continuing research or planned future improvement. We hope that our proof-of-donation pre-allocation will include some donations to us as well as to the charities we support to help us realize these improvements sooner rather than later.
MoX intends to support distributed applications as well as simple money transfers. The two go hand in hand in enabling a new generation of electronic commerce.
There are two ways such applications can be built. One is to run code entirely outside the block chain and use the chain only for storage of small key items of data and currency transfer. This is already supported via the key/value store described in section 3.4. The second is smart contracts like those pioneered by the Ethereum project. Smart contracts don't currently exist in MoX but we intend to implement them in some form in the future.
Before doing so we'd like to conduct quite a bit of research in several areas. We'd like to research better low-level microcode for smart contracts since it seems clear (at least to us) that none of the current platforms are ideal. Secondly we'd like to find a way to address the immutability problem and make it easier for contracts to be conditionally upgraded if vulnerabilities or other major problems are found. Creating a new contract and migrating everyone is clunky and inconvenient. Lastly we'd like to address smart contract usability by including a native mechanism for easily annotating contract APIs and asserting contract capabilities and compliance to standards. It would be nice if the latter were computable, though the halting problem suggests this may not be the case.
The invisible hands protocol lends itself very naturally to off-chain or "layer two" settlement networks. This was already discussed to a limited extent in section 3.2. It would be possible to implement off chain settlement by simply transferring envelopes.
More advanced systems could batch tokens to reduce the number of actual transfers that must be executed on the chain. This is an area we'd like to research once the core MoX block chain is deployed and entirely stable. It will require methods to prevent the agents batching and unbatching funds from stealing, and an implementation that also improved privacy as a side effect would be ideal.
One form of off-chain settlement that has so far been largely neglected by the cryptocurrency community (other than novelty "physical Bitcoins" and the like) is paper and other forms of physical cash. The MoX deposit token system lends itself naturally to the creation of independent forms of tradable cash for the same reason it makes other forms of off-chain transfer relatively easy.
To create cash a mint (not to be confused with a block minter) would begin by transferring funds to a new deposit token. The secret key for this token might then be imprinted securely within an inner sealed portion of a paper envelope, flashed onto an RFID tag, or otherwise imprinted securely within a piece of paper money or coin so that obtaining it requires visible intrusion into or irrevocable electronic extraction from the medium. The public token ID is then printed on the outside, likely as both a hex number and a scannable QR code. After the cash is created the creator erases the original secret key leaving the copy stored inside the new physical currency as the only one in existence.
It would be trivial for any holder of this cash to verify the balance of the associated token using any full MoX node. This is fast and free and open to anyone with an Internet connection. To transfer the value of cash back into the digital world the holder need only open it (however this is accomplished) and obtain the secret key inside.
We think it would be interesting and innovative to publish a do-it-yourself set of instructions using commodity parts and supplies like injket printers, security ink, secure envelopes, RFID tags, etc. to allow anyone to make physical MoX cash. This could be particularly valuable among the poor, refugees, and other "unbanked" persons, or people living in parts of the world that lack reliable and trustworthy maintream financial institutions due to war, corruption, or just extreme regional poverty.
MoX was designed to avoid any cryptographic requirements that lack already known strong candidates for post-quantum (quantum computer attack resistant) cryptography. Here are some likely post-quantum alternatives to current algorithms believed to be vulnerable to attack by a sufficiently powerful quantum computer:
ECDSA: Winternitz one-time signatures can be compact enough to be useful for input token endorsement of transactions. The spend-once nature of tokens was intentionally designed to allow a one time signature algorithm to be used. More sophisticated hash-based schemes like XMSS and Sphincs+ are too heavy for tokens but could be used to sign blocks. Other possibilities include lattice based signature schemes like NTRU and various isogeny signature algorithms.
ECDHE and Curve25519: Good alternatives to ECDHE for envelopes and transport security include NTRU Prime and supersingular isogeny key exchange.
AES and SHA are not believed to be vulnerable to quantum attack beyond Grover's algorithm which under best case scenarios could reduce their strength from 256 bits to 128 bits. Brute force search of a 128-bit key or preimage space remains entirely impractical, especially given that the iterative search speed using a practial quantum computer would likely be slower than the hash rate of a classical computer due to latencies incurred in quantum circuit setup, execution, and result extraction. Brute force search of a 128-bit space at a rate of one petahash per second would require thousands of trillions of years. Partial breaks of any algorithm could reduce this time, but likely not enough to become practical unless the break were catastrophic.
Post-quantum algorithms were not used in the initial design because they're not necessary yet, won't be needed needed for at least a decade under the most fantastically optimistic QC development timelines, are typically more CPU and/or bandwidth intensive, and most importantly have (in most cases) not received enough conventional cryptanalysis. It wouldn't improve security to use a supposedly quantum-resistant algorithm that turns out to be vulnerable to classical cryptographic attack. Instead we simply planned ahead and ensured that the design would be able to be upgraded to quantum-resistant cryptography with minimal disruption when it is both needed and ready.
Invisible hands manipulates funds without the involvement of sender and receiver addresses, but funds themselves and their patterns of flow are still visible on the chain. This is essential to allow for decentral banking. Without this degree of transparency nothing useful could be concluded at a macroeconomic level.
The transparency of money flows means that a resourceful attacker could use digital equivalents of classical money tracing and monetary forensic techniques to selectively de-anonymize transfers. An attacker could for example send a small amount of money to an individual he or she wished to identify. On receipt these tokens would be transferred to other tokens held by the recipient. During the course of normal transaction activity the attacker could observe how these coins are mixed with others and trace the path of these funds through the network. The network could be observed until some component of these funds entered the custody of someone cooperating with the attacker or identifying information is otherwise leaked. Inference using transfer amounts and other information could assist identification. Once a later recipient is known more manual investigative work could be undertaken to trace funds backward until the target is unmasked.
At the aggregate level statistical chain analytics leveraging economic models, pricing information, machine learning, etc. could be used to gather information helpful in de-anonymization efforts. It may be possible for example to identify likely customers of certain goods and services based on amounts and patterns of activity.
Countermeasures against these types of attacks are possible and include a wide range of techniques:
This is an open area of inquiry and ideas are welcome.
The inflation targeting algorithm (4) used presently by MoX is a workable proof of concept. The MoX developers are only amateur economists. The decentral banking concept has the potential to be a major area of economics research. Any policy that can be properly expressed as mathematics and algorithms as a pure function of the economy's public state and that's game theoretically sound and able to resist attempts to game it could be a viable policy. Real economists and experts in areas like game theory are invited to become involved and propose ideas.
The MoX project hopes to deliver a scalable, fast, affordable to (collectively) operate, secure, and private digital currency designed to embody monetary policies that prioritize its users for commerce over gamblers and speculators. Its design is unproven but seems theoretically sound. We welcome any feedback, criticism, or potential improvements, and plan to reward those that are significant with a modest allocation of coins from the initial genesis transaction.
Visit https://mox.network/ for more information about MoX, its status, and how to get involved.
