Updated on:
13 March, 2018

by DS, Stas Sheliakin and Vlad Timm

Cryptocurrency mining economy and motivation for Hlor development

High-level mining description

Mining in blockchain ecosystem is a core utility to proceed all transactions, but available configurations of Proof of Work (PoW) consensus protocol have significant weaknesses. One is an inefficient reward system of miners regarding existent power of cryptocurrencies networks.

PoW protocol was initially created in Bitcoin blockchain, and its idea of rewarding is aiming to attract additional computational powers for external miners to ensure none could consolidate more than 50% of available computational power in a network. And to enforce this requirement, PoW protocol includes continuously growing difficulty of mining. To limit the pace of miners’ power growth, initial Bitcoin protocol reward is declining discretionally and the time frame for this decline was established manually based on Satoshi Nakamoto’s estimation with no credible estimations.

After Bitcoin’s fast spreading and its followers hit a critical number, a lot of new developers create blockchains with other parameters of PoW protocol, but the idea of reward for mining remain unchanged. In blockchain’s excellence in trust implementation in the decentralized system, lack of precise view on mining problems resulted in the crypto economy being over supplied with computational power that is not utilized. If we compare power to potential number of transactions, it could proceed.

Motivation for miners to add new componential power to blockchains is growing with increasing value of Bitcoin and other cryptocurrencies. As a result, mining is becoming a huge consumer of energy in the world, where developed specialized devices with power in 100x times more than private laptops and computers and the possibility to mine blocks only through mining pools that have a kind of “political” power in crypto economy.

On the other side, there is unutilized computational power and unpredictable reward for investments in mining. In traditional economy, computational power used for mining of each block is a pure added value for the blockchain system because it ensures equilibrium of control and adds solved nonce that required to write block in distributed tables. However, a reward is received only for one nonce that is a right solution for Hash-function, which is a key inefficiency of PoW protocol.

To be specific, for the beginning, let’s understand how the mining process works.

Block is a collateralized blockchain asset that includes an initial chain and contains all critical information about transactions (particularly wallets addresses, time stamps of transactions and results of them). To ensure a blockchain system where all transactions are valid and to receive permission to write block in chain, a blockchain network requires computational power to solve a hash-function that, in the case of Bitcoin, is based on a semi-random function called SHA-256. The nature of this function means that to solve it is the only way – to try each nonce (value) of this function. This process is calling mining.

Note that SHA-256 is a hashing one-way function, and it cannot encrypt information. That is why blockchain is a pseudo-anonymous system; PoW and the entire blockchain could not encrypt information about a transaction. Anonymity is established at level of wallets, where you represented to the system as a result of hash-function.

Blockchain creates a task for miners, when hash-number t with particular length (for Bitcoin it is 256 bits) is proclaimed. Total hash code looks like 0x0000000000a8a32b1cb9d9a09aa 2325d2430587ddbc0c38bad911525 (it is theoretical example with increased number of non-zero points). Hash code always has a leading number of zeroes, and miners received only non-zero points (kind of #a7e741e671d7401bfd4), and the task is to prove that miners provide computational power to write block. The idea is to find previous hash proclaimed that particularly looks like trying each value that goes under 0a7e741e671d7401bfd4; if there is no right value, the miner changes nonce (additional field in block table), and runs all values under 00a7e741e671d7401bfd4, then under 000a7e741e671d7401bfd4 and goes on until they find the right solution. Based on heaviness of the network, this possible number of leading zeroes increases, while non-zero length is declining.

Basically, hash function creates a hash with 256 bits length, including nonce, target complexity value and coinbase parameter with extra-nonce.

hash function

Miners are not able to change tasks due to unpredictability of hashing function. Even a slight change in initial task description will lead to different hash-function to solve. That is why the system always knows when all miners solve the same task.

In more proficient manner, a mining function looks like an equation with a reverse SHA-256 function (or other hashing function that could SHA-512, Whirpool, zkSNARK, BLAKE, Grostl, Keccak, Streebog, etc.) on one side and target mining value that declines with difficulty increase:

SHA256 ( SHA256 (block info + nonce)) + extra-nonce < Mining threshold × (-1 × f(difficulty))

Please, note that extra-nonce is a piece of information that won’t be included in block data and used only to ensure ability of miners to run all values without changes in time stamp of block. Time stamp is a critical piece of data because it is used to look at each transaction root.

Finding a valid block

Those miners that find the right value will receive reward in Bitcoin and additional commission on transaction, because he is a computer with permission to write block in chain.

Mining economy basics

If we represent this situation in graphic form, it will be visible the initial idea of the reward system in Bitcoin looked like this:

mining reward

The idea was that computational power will grow more or less linear, and to increase Bitcoin’s capacity to process transactions, and in the initial phase, miners’ rewards will attract additional computational power, and with time, the average revenue per node from transactions will be higher than its reward. In this scheme, only computational powers in area A remain unrewarded, but with time, revenue from transactions will cover those losses and will provide additional profit to ensure Return on Investments for used powers.

The key problem is in estimation of Network complexity rate represented as a function from computational power in the network that is growing with time. There is a second part of this function, including limitations on distribution of computational powers (up to 50% in one hands). It is a critical issue raised when Bitcoins rate rocketed dramatically, and miners’ rewards cover huge investments in mining farms.

As a result, the situation in reality looks like this:

mining reward reality

Level of computational (hash) power in the network is growing exponentially, while the number of transactions per nodes is growing slower than predicted. The area expanded dramatically and revealed that numerous computational powers in the system remain unrewarded and inefficient. The key idea of miners’ power increase is to receive reward and help the network to protect itself from computational powers consolidation.

On the other side, such added value to the network requires additional costs from miners and pools not covered with revenue. Only miners with huge investment capacity have positive surplus over investments and costs of electricity, while smaller ones have gradually declining opportunity to receive any compensation for their added value to the ecosystem. Add to this environmental damage from electricity production used inefficiently.

To understand reasons for such reality, it will be useful to indicate reasons of Bitcoin (and other cryptocurrencies) exchange rate with fiat money growth in the traditional economic view. We are indicating 3 major components:

  • 1. Demand on cryptocurrency as digital asset – each coin/token has unique features that distinguish it from others, and it belongs to a finite number of such assets with predefined emission; that is a key differentiator from fiat money (emission for fiat money is not predefined that makes them almost infinite). Due to finite number of cryptocurrency, there is a limitation on the ability to satisfy growing demand, and it is hikes the price. To be more specific, it is not a core reason for price growth, because there are infinite ICOs and hardforks that lead us to the conclusion that cryptocurrencies are a quasi-finite and core driver for growth.
  • 2. Network effect – each coin/token has a unique ID (hash code) that ensures creation of a closed ecosystem, where only holders of wallets that could read this ID have the ability to use them. This is a core of network creation, and the value of each cryptocurrency will rocket in case of increasing number of users. The idea behind it is the same as Facebook, Instagram, Snapchat and other networks, which market value generated from network effect. Those network effects are boosting the number of transactions and market prices.
  • 3. Value created by network infrastructure – similar to social networks or cloud technologies in pair with network effects market value (or if you like capitalization) is generating also with added value of their infrastructure (in case of clouds, it is more visible). For Blockchain, its infrastructure added value created by miners.
  • As in a real economy, disproportion of compensation for each value driver leads to market fails, and in crypto economics, key market fail is in lack of compensation for infrastructure.

Hlor development motivation

The idea behind Hlor is very straightforward – to provide reward for miners in an amount equal to areas A and B per each transaction.

Logic we are using behind Hlor:

  • 1. Each miner receives a task from network; in case of pools, it receives only a part of a task through a kind of map-reduce function and tries all value underclaimed nonce with 1 leading zero.
  • 2. If there is no right answer, miners change additional nonce and try all values with 2 leading zeros, and it will continue until some miner finds the right solution.
  • 3. Each miner is a robot that provides useful work and, through this, creates added value to the system.
  • 4. To measure this added value system, use a particular number of hashes provided by miner to try all values.
  • 5. Particular added value of miner is its hash output through useful time of work – it is similar to human-days measure, but we propose to use robot-days (or better robot-seconds).
  • 6. Blockchain has a unique ability to measure robots value, because productivity of each miner’s measure through unified standard value – hash that is a productivity of computational power.

So, our idea is to:

  • 1. Indicate each hash output of each miner from the mining log – we took hash rate per each nonce from log and multiplied it on particular time to calculate all values in this nonce.
  • 2. Indicate useful time of miners’ work – we calculate working time from the moment a miner begins to try values in nonce until nonce with break (due to system stops calculation because another miner finds the right value or due to miner owner’s decision to stop work). In this case, only the last nonce not finished will not be included in time of useful work, because it was not uploaded to network and not provided any value for it.
  • 3. Unify all hashes’ output per standard time measure – hashes per useful work seconds (not generalized hashes per second used in major Blockchain networks).
  • 4. Hlor will be provided for each miner, according to his hashes per useful work seconds on unified ratio.

Generally, Hlor will be calculated as a sum of exact number of computational power provided to the system per 1 second (minute, hour etc. – depending on efficiency of data transfer via internet that won’t lead to any lags in miners’ work).

We are assuming the 2nd factor of cryptocurrencies price growth will drive Hlor market value, because ideally, all miners will create network effect and due to infinite emission of Hlor, 1st factor will not create hype around it. We are planning to measure blockchain infrastructure value through Hlor market rate.

And with Hlor price increase, we estimate that smaller miners will create pressure on consolidation of computational power, and it will lead to lower complexity level growing pace.

mining reward with hlor

Our idea in graphic terms is to increase compensation for miners from sum equal to area B to sum that equals to area B+B’. And to make mining more efficient in terms of environment and electricity consumption, we are estimating that inefficient computational power will reduce from sum equal to A+A’ to sum equal to area A’.

There is a variation of area B+B’ for different cryptocurrencies and even per each transaction (unpredictable change to find right solution to task). Addressing this challenge, we are planning that Hlor value will be dictated by market, and calculation will be made by specially developed add-on for miners.

And we are aiming to ensure efficient distribution at mining pools. Hlor will be generated by each miner and calculate number of calculated and outputted to mining pools hashes, so it will be easy to distribute rewards from mined block and distribute it based on number of generated Hlor. It will make personal mining more profitable and will lie in the basic idea behind Bitcoin, that each user could be a miner (not node) in the system.

Specifics of Hlor blockchain architecture

Partition of Hlor

Hlor is not a pure mineable token, and it is permanently emitting. Like added value generated by labor force, and as we believe by robots, miners’ added value is not limited by exact number, and it is infinite. The idea behind Hlor is to define 1 hash provided to blockchain as an equivalent of the smallest Hlor part, called Hloride, and will be emitting each 1 hash output. According to this, 1 Hlor is an exact 10 Exahash (1 Hash × 1018 or 1 Hlor = 1018 Hlorides) in all PoW blockchains.

1 Exahash is more applicable intuitively for calculations, but we know that from the beginning, we will not cover all miners, and Hlor will be undervalued. From this point of view, this ratio may vary depending on the emission reduction mechanism as the network hashrate grows.

Process of Hlor calculation

Hlorides will be generated in blockchain based on data collected by special add-on for miners’ operation environment that looks on log of mining and reads number of outputted H/s and time on one extra-nonce iteration. This add-on will have unique addresses, similar to wallets that will receive Hlor/Hlorides on its account. This address could also be replaced with another miners’ wallet.

Formula of add-on calculation is simple:

hlor emission

where H/S – Hashes per second outputted during nonce calculation iteration,

t1 – actual time to finalize iteration,

t0 – actual time to finalize previous iteration.

So generally, logic is the following:

  • 1. When miners are starting to mine, control station (interface of mining machines with operating system) is creating a log file, where it is possible to indicate all mining iterations. This file is generated locally by the system and has no influence on relations between miners and blockchain environment. We are using existence of this file to our add-on work and using it in read-only mode.
  • 2. Add-on starts time counting function at the moment first mining tasks are received in miner’s log.
  • 3. From log add-on read actual time of first and all next nonce solving iteration and this iteration’s H/s rate (also outputted to blockchain and pools, that’s why it is possible to see H/s rate for mining).
  • 4. Add-on calculating actual hashes of mining and send it to Hlor blockchain each 60 seconds.
  • 5. When miner stops receiving tasks, another miner mined block or miner solve task leads to additional log information. This information is triggered for add-on to stop counting function, so all Hashes used for unfinished iteration will not receive Hlor compensation (because that has no added value for system). The same applicable is used for iteration during which a miner solves the tasks. We think it is fair, because the miner that solved the task receive a mining reward, a significant amount of cryptocurrency.
  • 6. This is a repeatable cycle. Add-on will start work again with new task or when miner will be turned on.

Add-on will be continuously sending information to Hlor blockchain nodes, and, if miner agrees, coping this info to mining pool. To secure those transactions, we will use SHA-256 hashing plus time stamp for each piece of information. That will help us to ensure security and trust, even in case of lags in blockchain (unavoidable due to different speeds of total mining computational powers increase and Hlor nodes computation power growth).

After that level of add-on, those parameters will be unified by time feature and calculated as hashes generated by miner. After that, add-on will send aggregated data for each 60 seconds to Hlor blockchain – that is a primary transaction for emission. Hlor miners will solve own PoW consensus, write block that will lead to new Hlorides emission, and send it to miner’s add-on/wallet addresses.

There is an additional ability of Hlor blockchain, unique and new for all blockchain systems – infinite emission of new Hlorides.

Emission transaction - coinbase parameter modification

Schematically, Hlor emission will be like:

hlor emission

Key comments to visual interpretation:

  • 1. Data from Add-on (transfer direction under blue arrow) have no connection to miners’ wallet, do not store its address, keys, semantic words etc. It is only a counter for processors’ output (hashes) with own identification for Hlor blockchain.
  • 2. Data from Add-on is not a cryptocurrency until emission transaction ends.
  • 3. Only Hlor full nodes (definition is below) can create new Hlorides from Add-on information.
  • 4. Emission transaction inputs are Add-on data and balance of Hlorides on full node address.
  • 5. Key rules of UTXOs:
    • a. UTXO for full node + UTXO for miners ≤ # of Hashes in data from Add-on
    • b. UTXO for full node + UTXO for miners ≤ 2 × full node Hlorides balance
    • c. UTXO for full node ≥ UTXO for miners

Miners could use the specialized Add-on to count their hash’s actual output, and this Add-on will have a unique identification in the Hlor blockchain ecosystem. This Add-on will send each 60 seconds of information to any randomly chosen full node (addresses of each full node are predefined in blockchain). Only this node is able to convert data of counted hashes in Hlorides (1 Hash = 1 Hloride) through initiation of new transaction to miners from which full node received Add-on information. Full node executes PoW protocol to put this transaction in blockchain, where this transaction will have all UTXOs (unspent transaction outputs – full sum of output transaction without commission for miners).

Regarding the basic idea in Bitcoin, to avoid double-spending attacks, each transaction means the system takes input number of coins from wallet and “burns” it, while at output of transaction, it creates 2 bunches of coins – Bitcoins that will remain at input wallet and Bitcoins transferring to recipient wallet.

We will add additional feature in coinbase parameter that will ensure data from add-on converted in coins, coins from input wallet (nodes one) will not be “burned”, and at output, we will have remains in value of initial transaction and validated value of Hlorides that will go to the miners. In this scheme, nodes will have unlimited and transferable amount of Hlor to provide infinite emission of Hlor.

The key idea behind that modification is to create wallets with nontransferable amount of Hlor, working as ATM machines for miners in their robots’ ecosystem.

Logically it looks like:

  • 1. Through using understandable blockchain structure (basically similar to Bitcoin, Litecoin etc., except Ripple, Cardano and other non-mineable cryptocurrencies), we will include in coinbase parameter list of wallets that will have nontransferable funds (around 100 thousand wallets).
  • 2. To become a full node, the miner must have this wallet. At stage of ERC-20 Token, it will be purchased through capitalization of Hlor by other currencies, after Hlor blockchain launch – by providing Hlors to those wallets and after voting of other nodes to accept new full node.
    Private keys for those Hlor wallets will be placed in colored token of Monero or Emercoin blockchains and will be distributed via depositing transaction. Monero and Emercoin are chosen to provide confidential transmission of private key.
  • It requires an additional description. To avoid centralization of Hlorides emission and to ensure the core team of Hlor developers have no access to full nodes addresses, it was decided to use public blockchains to transmit private keys for wallets.
    We are considering 2 basic ways to do this:
    • I. Obtain several Monero tokens and put hashed private keys in them to full nodes addresses. This will make those Monero tokens as colored tokens (basic tokens with specialized info that distinguishes them from all other tokens). Monero blockchain provides the ability to make transactions amount and hashes of transferred tokens confidential. That means we could transfer colored token with private address in hashed form to a new address holder without disclosing private key hash publicly. The 2 ways to solve hash and discover private key is to unlock it with corresponding public and private keys or through trying each value until finding the private key while having the public key. To minimize the possibility of second way, we will use confidential transaction of Monero to transfer the public key (hashed information in colored token). It will also provide additional protection in case full node private key is compromised – public key remains undisclosed.
    • II. Second transmission way is more traditional/less exotic but more expensive for those who want to become full node. The idea is to use Emercoin ability to provide decentralized public key infrastructure for keys exchange. We will obtain service of user identification with Emercoin to create our private and public keys to full node address. User that purchases the right to became new full node also must obtain the same service from Emercoin. Specialized transaction in Emercoin will ensure transfer of full address private key from Hlor developers team to new full node holder. Under this transaction, the public key remains transparent that could be used to solve hash function and disclose private key to full node address. Soon, it will not be a problem due to high costs of such activity.
    User can choose the way for private key transfer in blockchain development period. After that, when blockchain will be deployed with all addresses in coinbase parameter, we will use the most trusted way of transmission.
  • 3. Hlor blockchain is configured in such way that it will not allow output transactions from listed in coinbase wallets if this will lead to reduction of Hlor amount. This applicable is only for transactions that lead to transferring of funds from wallets, because emission transaction will not lead to reduction of Hlor amount on wallets.
  • 4. When nodes are receiving information from add-on, they are solving tasks similar to Bitcoin miners – find value that is lower than target value. After this PoW, full nodes may provide emission on this transaction to miner wallet.
  • 5. Emission transaction requires: input transaction from wallet in list in coinbase parameter, value that is lower than target value, output address, amount of output Hlor.
  • 6. During the emission transaction, blockchain will acquire all full nodes funds as an input. At output, it will have the same amount as an input to full nodes address and amount of output Hlor to miner address (but not more than full node has). If full node has less than is owed to miner, emission transaction repeats until output Hlor amount to miners’ wallet is less than full nodes’ wallet amount.

In logic operations in blockchain, it will look like:

  • 1. Alice has a full node with wallet listed in coinbase (let’s it call “coinbase emission wallet”).
  • 2. Bob is a miner with add-on and a wallet receiving Hlorides.
  • 3. Add-on from Bob’s miner indicated 90 TH (that is 0.09 Hlor) in output during Bitcoin mining session and sent it to Hlor blockchain.
  • 4. Alice’s node is the first to solve PoW task (has hash value lower than target value) and has 0.05 Hlor on its “coinbase emission wallet”.
  • 5. Blockchain network looks on following parameters:
    • a. If Alice’s node has hash value lower than target value, if yes – goes to b, if not – transaction is not allowed.
    • b. If Alice’s node wallet address listed in coinbase parameter, if yes – goes to c, if not – goes to h.
    • c. New transaction created, where 0.05 Hlor consumed and in UTXO created 0.05 Hlor to Alice and 0.05 Hlor to Bob.
    • d. If Bob’s input transaction (0.09) > Alice’s Hlor in wallet (0.05), if yes – goes to e, if not – goes to g.
    • e. New transaction created, where 0.05 Hlor consumed and in UTXO created 0.05 Hlor to Alice and 0.04 Hlor to Bob.
    • f. If Bob’s input transaction (0.04) > Alice’s Hlor in wallet (0.05), if yes – goes to e, if not – goes to g.
    • g. Transaction(s) included in full block and published on blockchain.
    • h. If transaction from Alice’s wallet leads to decrease of Hlor amount on it, if yes – goes to i, if no – transaction is not allowed.
    • i. If Bob’s input transaction has mark of add-on and timestamp in it, if yes – transaction is not allowed, if no – transaction between 2 simple wallets and goes to block to be published on blockchain.
  • 6. Alice receives additional reward each XX day for storing “coinbase emission wallet” on its simple wallet (see section with miners’ rewards).

Hlor blockchain roles and general transactions processing

Hlor blockchain supports general transactions of Hlorides between different addresses, except full nodes addresses. For this purpose, blockchain will allow not only full nodes, but general nodes and light clients.

Schematically, Hlor general transactions will look like this:

hlor general transactions

* STXO – spent transaction output that is the same as a commission for miner for processing of transaction.

Key comments to visual interpretation:

  • 1. Data from Add-on (transfer direction under red arrow) have no connection to miners’ wallet, do not store its address, keys, semantic words etc. It is only a counter for processors’ output (hashes) with own identification for Hlor blockchain.
  • 2. Data from Add-on is not a cryptocurrency until emission transaction ends.
  • 3. Only full nodes (definition is below) could create new Hlorides from Add-on information.
  • 4. Emission transaction inputs are Add-on data and balance of Hlorides on full node address.
  • 5. Key rules of general transactions:
    • a. UTXOs of general transactions = Input transactions amount − STXO
    • b. STXO < UTXOs
    • c. Input of transaction ≤ Sum of output wallets balances

As it could be seen from the picture above, there is no significant difference between Hlor and other blockchains. One Hlor address holder with a balance of Hlorides initiates a transaction to another Hlor address holder. Blockchain checking if all signs are available under transaction and if output wallet balance is equal or higher than transaction amount. If all requirements are met, miner executes PoW protocol, validates block where we could see valid transaction with all UTXOs and STXO.

Key comments to visual interpretation:

  • 1. Hlor address holder – particularly is a user of Hlorides. To interact with Hlor blockchain, you must have own address in the blockchain. It could be, primarily, miners and any other person who wants to use Hlorides.
  • 2. Hlor miner – is holder of computational power to execute PoW protocol in Hlor blockchain. Generally, it will be CPU miners due to specifics of Hlor hash function (Scrypt/SHA-256). Miners are processing transactions and receiving STXO for this.
  • 3. Nodes – holders of entire blockchain history and key elements to root transmission of mined block.
  • 4. Light client – user of Hlor blockchain that could see only previous block headers to transmit transactions almost instantly. Solution for mobile devices.
  • 5. Full nodes – nodes with specialized address written in coinbase, its fund un-transferable and able to initiate emission transaction. To become a full node, address owner must deposit initial funds to it (similar to master nodes in Dash blockchain).

To equalize all miners - calibration formula implementation

At this moment, key adjustments must be implemented. Major part of blockchains is using different hashing function or combination that lead to variations of performance of miners. With that, each blockchain has a unique construction of its features that makes it possible to distinguish what tokens are mined.

Unfortunately, it is almost impossible to predict miner performance for each hashing function, and there are significant risks that Hlor could become an additional stimulus to mine only the easiest ones, where hashing output is most significant. There are various numbers of hash functions (SHA-256, SHA-224, SHA-512, Whirpool, zkSNARK, BLAKE, Grostl, Keccak, Streebog, Ethash etc.) with various combinations of string length and required types of computational power (GPU, CPU and memory availability). Also, a lot of new cryptocurrencies are trying to use different algorithms to use them (like scrypt execution of SHA-256 in Litecoin). There is a huge difference of mining machines’ performance (in hash production) in different algorithms.

To address this challenge, we are implementing a statistical algorithm to equalize Hlorides emission to each miner. It will be based on each day equalization of mining performance on “average” machine.

The idea behind this is to nominate 1H production of most efficient mining as 1 Hloride and introduce calibration coefficients for others to ensure more or less fair Hlor distribution. Add-on is calculating hashes output per each kernel that provides calculation, so we can now average output per each kernel for each algorithm. Based on this, we could provide calibration with formula:

Hlor Calibration Formula

where MH – is maximal hashes output per period of time in most mining effective blockchain,

∑ Hb, ∑ He , ∑ Hl , ∑ Halt – are hashes output for defined period per each mineable blockchain,

KernelMH – number of kernels that provide calculations for most mining effective blockchain.

After that, we will introduce calibration coefficients for all other blockchains that are calculated as next:

Hlor Calibration Formula

Graphically, it will look like next (illustratively, actual data will vary; not all potential cryptocurrencies are included):

Hlorides Table

Below is a table behind a graph that reveals the idea of calibration formula (in green is a maximum value):

Hlor Calibration Formula Table

Those calibration coefficients will be applied to each cryptocurrency mining during a particular day/week at add-on level.

Hlor consensus

Hlor is a typical blockchain based on PoW protocol and will use Scrypt execution of SHA-256 that will exclude risks for the system from Bitcoin ASICs and ensure scalability of the network at the beginning of its existence. However, our PoW protocol will not include reward for miners for solving tasks, only transactions reward.

This consensus of Hlor will be similar to Litecoin (that have few differences from Bitcoin). That means key characteristics of consensus are:

a) Consensus rules

The consensus rules are the specific set of rules that all Hlor full nodes will unfailingly enforce when considering the: 1) validity of a block, 2) its transactions, and 3) emission of Hlorides. For example, for 1) and 2), the Hlor consensus rules require that blocks only create a certain number of Hlor/Hlorides. If a block creates more Hlor than is allowed, all full nodes will reject this block, even if every other node and miner in the world accepts it. For rule 3), full nodes will be responsible for emission of new Hlorides; that means they will have access to nontransferable wallet from coinbase parameter list that ensures emission.

Adding new consensus rules can generally be done as a softfork, while removing any consensus rule requires a hardfork. Rules regarding the behavior of the mere network protocol are not consensus rules, even if a change to the network protocol behavior breaks backward-compatibility. The consensus rules are only concerned with the validity of blocks and transactions.

These rules are called consensus rules because Hlor requires that all participants in the Hlor economy have consensus (with the meaning of the next definition) as to the consensus rules. If the economy disagrees about the consensus rules, then the currency and economy splits into two or more independent pieces.

For clarity, these rules are called hard rules of Hlor instead of consensus rules.

b) Near-unanimity

"Consensus" can mean something like "no significant objection among the set of people who 'matter'”. In Hlor, this is the standard required to roll out a hardfork: there should be no significant section of the Hlor economy that will actively oppose the hardfork.

c) General agreement

Consensus can mean something like "a strong majority when the participants are weighted for expertise and/or strength of argument."

Similar to Bitcoin and Altcoins consensus, Hlor also requires previously unwritten agreement: All Hlor blockchain participants must have agreement that Hlorides have a value that could be expressed in fiat currencies. That means there must be an agreement that miners added value to any blockchain have the same value.

Rewarding of Hlor miners

And any asset created with added value has a life cycle. To exclude situations that miners will mine Hlor, it won’t be generated by Hlor miners. To provide reward for them, except fees for transaction, each inactive wallet for a long period of time will be penalized with reduced emission of Hlor, and those penalties will be distributed between miners of Hlor. This system is aimed to balance transaction fees and reward for mining.

So, miners’ reward in Hlor blockchain will be concluded from 2 elements:

  • I. General miners reward = STXO, but not lower that 0.01% from transaction + discrete distribution of penalties between miners
  • II. Full nodes reward = STXO, but not lower that 0.01% from transaction + penalty for wallets that are not in use

Penalty used only on the generation of new Hlor, all stored Hlor in wallets is not penalized and inaccessible by blockchain without private key confirmation.

Visually, it modifies emission transaction by adding additional STXO to it:

Hlor Calibration Formula Table

STXO for a full node will be calculated as next:

0.0001% of Hlor generated during the week for each wallet that does not provide transactions at the amount of 10% of generated Hlor during the previous week.

0.001% of Hlor generated during the week for each wallet that does not provide transactions at the amount of 10% of generated Hlor during 2 previous weeks.

0.01% of Hlor generated during the week for each wallet that does not provide transactions at the amount of 10% of generated Hlor during 3 previous weeks.

0.1% of Hlor generated during the week for each wallet that does not provide transactions at the amount of 10% of generated Hlor during 4 previous weeks.

1% of Hlor generated during the week for each wallet that does not provide transactions at the amount of 10% of generated Hlor during 5 and more previous weeks.

10% of Hlor generated during the week for each wallet that does not provide transactions at the amount of 10% of generated Hlor during 1 previous year.

90% of Hlor generated during the week for each wallet that does not provide transactions at the amount of 10% of generated Hlor during 2 previous years.

So, we generally have the next reward system:

Hlor Reward Formula

For the additional penalty, each emission transaction will include full nodes pairing simple wallet. That means, in emission transaction, there will be a parameter of commission (the same as in general transactions). In our example with Alice and Bob, we will have the next composition of emission transaction:

Alice is emitting to Bob 10 Hlor. If Bob’s wallet has a history of output transactions of with timestamp lower than block time in the gap up to 1 week and more than 10% of all input transactions amount that is not older than 1 week, UTXO will be equal to input amount.

If timestamp is older than 1 week, but earlier than 2 weeks, and for this week was lower than 10% of all input transactions amount that are not older than 2 weeks, that UTXO will be 10 Hlor to Alice, 9.999 Hlor to Bob, and 0.001 Hlor as a commission to Alice’s mining wallet.

If timestamp is older than 2 weeks, but earlier than 3 weeks, and for this week was lower than 10% of all input transactions amount that is not older than 3 weeks, that UTXO will be 10 Hlor to Alice, 9.99 Hlor to Bob, and 0.01 Hlor as a commission to Alice’s mining wallet.

And this is going forward; the maximum penalty amount after 2 years of inactive wallet: UTXO will be 10 Hlor to Alice, 1 Hlor to Bob, and 9 Hlor as a commission to Alice’s mining wallet.

Each week, when there is a calibration of Hlorides emission, it will also be a discrete distribution of those penalties to all miners of the Hlor blockchain. For full node benefit, it is an additional STXO for a transaction to Hlor miners.