krzysztof.jurewicz@gmail.com
BLK: BBny1VLLjpn8U9TGpan6VyZy2bAKvceuy1
BTC: 1Hsy6JuXiHC4CUQojLxD1zhQhu5vf23qoZ


Abstract

This paper presents transaction fee related threats to cryptocurrencies with high block frequency and low transaction volume (relative to market capitalization), taking BlackCoin as an example. It then presents a possible solution: dynamic block sizes, which would allow for market adjustment of transaction throughput. Disadvantages of dynamic block sizes are then presented and dynamic minimum transaction fees are introduced. Possible collusion of miners with users is then discussed and partial fee destruction is proposed as a remedy. Finally, negative transaction fees are discussed.

Present state

BlackCoin is a Proof-of-Stake cryptocurrency, founded in 2014. It currently generates a new block every 64 seconds, with the maximum size of 1 MB, giving it over 9 times bigger possible throughput than Bitcoin’s. This in itself is a good thing, as BlackCoin in the nearby future will not have Bitcoin’s problem of high transaction fees due to scarce blockchain space. However, there is also a threat associated with having large blocks and low transaction fees.

BlackCoin client by default charges 0.0001 BLK per kB of transaction. Rough estimations say that if someone wants to flood BlackCoin’s network and fill the blockchain completely for, say, a week, which will result in 9.45 GB being stored, he will need to pay 967.68 BLK, which is about $31.81 at current prices. Current Bitcoin blockchain size is nearly 57 GB. Storing this amount of data in BlackCoin’s blockchain would cost less than $200. This data would be stored permanently in many places even when BlackCoin core client adopts blockchain pruning. Additionally, size of the UTXO database (which is not subject to pruning) may grow as a result of these actions.

It is up to the miner to decide which transactions to include in a block, with a default behaviour being provided by the reference client. If a particular miner feels that transaction fees are too low, he may change fee policy for the blocks he generates. Therefore the overall transaction fee policy is a sum of transaction policies of all individual miners.

Economic incentives in per-block transaction fee policies

A problem with setting transaction fee thresholds per individual blocks is the tragedy of the commons. While newly created coins and transaction fees are gathered by the block creator, storage costs are taken by all full nodes. Therefore every miner has an economic incentive to take more transactions into a block than he would deem optimal for the network in the long run. The result may be a blockchain flooded with more transactions than a miners’ consensus would bring.

Dynamic maximum block size

BIP #100 proposes a voting system in which miners put their preferred maximum block size into blocks they mine. Inspired by it, we can propose the following solution for BlackCoin:

  1. Miners optionally put preferred block size into blocks they generate.
  2. Maximum block size is set as the median of the preferred block sizes from the previous 501 blocks. (501 is an arbitrarily chosen number; it is the number of coinbase confirmations for BlackCoin).

Dynamic maximum block size allows miners to limit predicted volume of transactions, so that a fee market emerges, encouraging them to omit transactions with very low fees. If the hard-coded limit of 1 MB per block is left intact, it can be introduced as a soft fork.

There are some disadvantages of limiting block size:

  • Miners may not be able to predict transaction volume accurately. In case of a sudden spike or decrease, rapid adjustment will not be possible.
  • It is hard for a user to guess a minimum fee which will allow a transaction confirmation in n number of blocks. RPC calls like estimatefee can be provided to faciliate this, but still a relatively high degree of uncertainty is involved.

Dynamic minimum transaction fees

Limiting block size means introducing artificial scarcity of a resource (blockchain space) which is generally not scarce, in a hope that emerging fees will make processing transactions profitable for the whole community. Can we find a more direct way to achieve this?

Fee profitability threshold is a value that can be estimated. Based on that, we can try to achieve a consensus on minimum fee required, in the following way:

  1. Miners optionally put preferred minimum transaction fees into blocks they generate.
  2. Minimum fee is set as the median of the preferred block sizes from the blocks of depth from 51 to 551.

This solution is much more flexible in case of rapid volume changes and it allows a client to predict, with a high level of certainty, exact value of fee which will alow its transaction to be mined in a few blocks.

What factors impact transaction processing cost?

Currently transaction fees depend only on transaction size. However, in general, transaction processing cost for the whole ecosystem is related to at least the following:

  • cost of long-term storage of the transaction;
  • cost of storing transaction outputs in the UTXO database;
  • computing cost of transaction verification (which is not proportional to transaction size, at least in the case of Bitcoin).

Therefore we can propose minimum transaction fee as a linear function of the above arguments, with the three relevant coefficients to be voted by miners. Transaction fee will be computed as the maximum of 0 and the following:

size in kB · price per kB + (no. of outputs – no. of inputs) · price per UTXO + computing cost · price per computing cost unit

If the calculated fee is 0, a client may want to pay a small fee anyway to encourage miner to actually put it in a block. (We will come back to that issue later).

Collusion threat

A greedy miner can announce a feeback programme: if someone decides to wait and allow specifically him to mine his transaction, he will give back some of the fee under-the-table. This will result in actual fees in his blocks being lower than the consensus-determined threshold and may result in flooding the network.

Fee destruction

In BlackCoin, fees are given to the miners, giving them an incentive to include a transaction inside a block. Peercoin on the contrary has hard-coded fees which are destroyed, mitigating the risk of flooding the network. We can combine these two approaches to ensure both that transactions are being mined and that it is difficult to flood the network. If a miner gets only a part of a transaction fee, he will still have an incentive to include the transaction inside a block, while it will be more difficult for him to introduce dumping prices for transaction processing. Fee destruction ratio can be either hard-coded or determined by miners using a voting process similar to the ones already described, aiming to achieve a level which is high enough to give miners a compensation for increased latency related to broadcasting bigger blocks. To be fair, we can calculate fee amount being given to the miner based only on the size-related part of the transaction cost processing. If we denote by R the fraction of the part described above which is given to the miner, then his profit from a transaction can be calculated in the following way:

(size in kB · price per kB + computing cost · price per computing cost unit) · R

The amount of coins destroyed will be the maximum of 0 and the following value:

(size in kB · price per kB + computing cost · price per computing cost unit) · (1 – R) + (no. of outputs – no. of inputs) · price per UTXO

Negative transaction fees

All the above measures can be taken with a soft fork, i.e. all blocks mined under the new rules will be valid also under the old rules. If a majority of miners makes a switch, there should be no network split problems. Now we will perform some academic considerations by asking ourselves whether it is necessary to constrain fee amount to be always positive. Changes described in this chapter would require a hard fork.

If a transaction has many inputs and few outputs, and also UTXO database resources are considered pricey, then processing this transaction may be deemed good for the overall network health, possibly resulting in negative amount of coins destroyed being calculated. Allowing this would mean that in some transactions sum of outputs plus sum of miner’s fees would be greater than sum of inputs. Where should we get that coins from?

It’s obvious that in general case we cannot get these coins from the miner, as it would create a disincentive for him to include such a transaction in a block (especially when coins created would be greater than fees he would otherwise gather). We can bypass this by deferring this cost for a fixed number of blocks, hence creating coins on credit.

A more straightforward and flexible approach is to keep UTXO-related fees out of miner’s area of responsibility and to allow coin creation in ordinary transactions. A transaction broadcaster will need to determine whether the amount of coins created will be accepted by the network, but it will be as easy and deterministic as in the case of positive transaction fees.

Changes to the client

If we wanted to implement a soft fork with dynamic minimum transaction fees and fee destruction, adding configuration parameters like the following would be handy:

  • preferredfeeperkb
  • preferredfeepernewutxo
  • preferredfeepercomputingcost (the notion of “computing cost” would obviously need to be precised)
  • preferredfeedestructionratio

Adding also relevant RPC calls would allow stakeholders to do things like fetching the current RAM price and adjusting preferred UTXO creation price based on that information.

Summary

Bitcoin, BlackCoin and other cryptocurrencies contain some hard-coded, ad-hoc measures against blockchain flooding. Being based on static values, they are either ineffective or too restrictive, resulting in blockchain repleteness. We have drafted some ways to improve this situation by giving miners’ consensus the ability to decide about key blockchain parameters, which should result in the market being able to react smoothly to constant changes of external economic conditions.