A Deep Dive into Mochimo — Part VII: Dissecting Transactions

This is the seventh part of a series of articles about the Mochimo blockchain, a 100% original, no-ICO, no-presale crypto currency project.
Follow us on Twitter, Discord, Reddit

If you haven’t already, read our previous article A Deep Dive into Mochimo — Part VI: Proof of Proof of Work — On the Edge of Sanity

Structure of a transaction

In Mochimo, data is carried by a structure called TX. Nodes communicate by exchanging TX to notify of a block solve, to send transactions, to download blocks, etc.

Let’s look at the transaction structure from the official repository:

• version: version of the protocol
• network: ID of the network
• id1: value for the Three-Way-Handshake
• id2: value for the Three-Way-Handshake
• opcode: type of message (“block solved”, “get peers”, “dl block”, etc)
• cblock: number of the last mined block
• blocknum: number of the block being requested
• cblockhash: hash of the last mined block
• pblockhash: hash of the previously mined block
• weight: weight of the chain
• len: length of the data being sent
• src_addr: source address of the transaction
• dst_addr: destination address of the transaction
• chg_addr: change address of the transaction
• send_total: amount of MCM sent
• change_total: amount of MCM redirected to the change address
• tx_fee: transaction fee
• tx_sig: signature of the transaction
• crc16: integrity hash of the data
• trailer: some hard-coded data

Even though TX seems to be designed to carry transactions alone, it can be used for any interaction between node, by simply using the bytes from src_address to tx_sig as a byte buffer. This means that a TX can carry 8792 bytes of arbitrary data.

Characteristic of transactions in Mochimo

The minimum transaction fee in Mochimo is 0.000000500 MCM. At the time of writing, all transactions have been performed with this minimum fee, which makes Mochimo a First-In-First-Out network (working on a first come, first serve basis).

Any address holding an amount less than or equal to minimum fee is automatically trimmed from the ledger. As a result, you will not find any address with less than 0.000000501 MCM on the blockchain. This is to limit potential bloating attacks, where thousands of addresses are created with the smallest possible amount and cause the size of the ledger to increase drastically. There are other anti-bloat protections in place that will be discussed in the next article.

Like many other crypto currency projects, Mochimo uses txid as a unique identifier of a transaction. However, in Mochimo, a txid is only unique within a block. In crypto-currencies like Bitcoin, a node can verify whether or not a txid is unique on the blockchain because it holds all blocks ever mined, but a Mochimo node only requires the last few hundred blocks to start. Therefore, it cannot guarantee that a txid is unique across the whole blockchain, only within a block. However, one can easily create a unique ID for a transaction by combining the hash of the block and the txid (example: unique_id = sha256(block hash + txid)).

WOTS+ and One-Time-Signature paradigm

As detailed in a previous article, Mochimo is currently based on the Quantum Secure Winternitz One-Time Signature+ (or WOTS+).

Using a one-time-signature scheme has several implications that need to be carefully addressed. Most of the complexity is hidden from the user behind the Tag system. The Tag is the reusable and unique identifier of an account; every time it is spent, a new WOTS+ is created and bound to the Tag. But what would happen if a Tag were spent but also received MCM within the same block ? Would the receiving transaction be rejected ? Would the MCM be sent to the old WOTS+ address ? Rest assured, our blockchain can handle it.

In the case where a Tag is spent and receives MCM within the same block, all funds received are redirected to its newly bound WOTS+ address. The transaction would be processed smoothly and the owner of the Tag would see their balance decrease by the amount of the outbound transaction and increase by the amount of the inbound transaction.

Another issue caused by using a One-Time-Signature scheme is that it is very difficult to spend an address more than once within a block. This is not practicable for large entities that need to process thousands of transactions every day. The Mochimo development team created a new type of transaction called “multi-destination” (or MTX) with which one Tag can send MCM to up to 100 different addresses every block. That is 255 * 100 = 25.5K transactions per day for a single Tag.

During our stress test of the network, we were able to process around 170 transactions per seconds. Factoring the “multi-destination” feature, the capacity of the network is 170 * 100 = 17,000 transactions per seconds and we expect it to increase even further in the future (more details in subsequent articles).

For comparison, the registered peak for Bitcoin is 22.

Ortis.

Edited by Kashmyr

About the author: I am a contributor to the Mochimo project and a founder of the mining pool illamanudi.
Twitter, GitHub