Transaction fees per byte for extra data

[aivve]

Rationale

A CryptoNote transaction has an extra field that can store additional information that is stored forever in the blockchain along with the transaction. There is no any limit of the size of this additional transaction extra, therefore it can potentially be quite large. We believe that permanent blockchain storage of the extra data, unrelated to the main purpose of transactions per se, namely, storing information about the transfer of money, has to be paid for. The problem is that the size of the transaction has no influence on the fee of the transaction.

Let us remind, what transaction fees are for. Unlike Bitcoin and Bitcoin-based coins, in CryptoNote protocol there is a mandatory minimal transaction fee which is either flat-rate fee in the default CryptoNote solution or size-based like in Monero. The minimum transaction fee solves three problems, - it introduces the costs of spamming the network, helps to motivate miners to continue to support the network and is preventing a transaction flooding traceability attack. This means that the minimum transaction fee can not be too low, as we saw in practice in the spam attack on Karbo network during the beginning of April 2018. The minimum fee was merely 0.0001 KRB ($0,00005) at the time of the attack! Karbo developers were forced to set higher transaction fees (0.1 KRB) to stop and prevent spamming. Karbo has introduced adaptive minimal transaction fees afterwards. It is important to make sure that the algorithm can not lower the minimum transaction fees too low enabling spam again.

In Monero, the most known CryptoNote based coin, the fees are based on transaction size, which solves this problem but creates another one - if a user sends a transaction with many outputs it will render a larger fee amount because of the larger size of the transaction. This is unfair and hard to understand by non-tech-savvy users: why a user has to pay more fees merely because, e.g. he received his money in many smaller transactions or, for example, he wants to send funds in one transaction to many recipients? After the improvement of the RingCT in Monero, the transaction sizes are significantly reduced and this problem generally is solved. But in Karbo the number of inputs/outputs has an influence on transaction size and this approach is not a good option.

In Karbo, as well as other coins based on the Bytecoin flavour of the CryptoNote, there is a special type of fee-less transactions, called a 'fusion transaction', which allows to optimize wallet - reduce the number of wallet inputs, resulting in smaller transactions. This solution was created to reduce the size of a transaction so it can fit into the block and transaction size limit but can be used to reduce the severity of the problem as well if we choose to use Monero's approach and introduce fees for the size of the transaction, however requiring additional steps in form of wallet optimization before sending a transaction, which undermines usability.

Charge for extra size

We propose a different solution: calculate the additional fee only for the size of the extra field of the transaction instead of the whole transaction. Let's call this fee as 'fee per byte'. This way, the normal transactions will all have the same obligatory limit of the 'minimal fee' but for the additional data, the sender will have to pay an extra fee based on the size of the extra data.

The extra field of any normal transaction always contains or may contain some data, like e.g. payment id. The size of the extra field of the typical transaction fits in 100 bytes, therefore this size of the extra field of the transaction is proposed to be free of charge.

The extra field is the vector of uint8_t, and the uint8_t is exactly the one byte, therefore we can easily get the size of the extra field, being the size of the vector, and calculate the 'fee per byte', excluding first 100 bytes.

The cost of one byte of the extra is set as 1/100 of the 'minimal transaction fee'.
The 'fee per byte' is added to the 'minimal transaction fee'. The total transaction fee is calculated as

F = Fb + Fm

where Fb is 'fee per byte' and Fm is 'minimal transaction fee'.

Additional thoughts

The fees for the extra size are received by the miners whereas the size impacts the nodes storing the blockchain in the first place, however indirectly it benefits the whole system including nodes, so in the absence of a better solution, this is the only viable option available.

To allow to attach as many data as user wants for a fee, the removal of limits on transaction size is probably required, which is questionable because this limit is set for protection from:

1. transactions too large to fit into the block;
2. from transactions so large due to many inputs/outputs that are too hard to process on the ordinary PCs; a really large number of outputs can be used for spam (e.g. for traceability attack).

The first problem can be solved by removing of the limit of the block size (the later limit is not hard and can adapt but it does not change rapidly). Alternatively, and probably preferably, user who wants to put into the block a large transaction just has to pay enough fee to the miner that covers the block reward penalty which reduces the block reward it the block size is exceeding current median.

To solve the second problem we could replace the transaction size limit by the limits of the number of the inputs/outputs (as it is done in Monero, where they limit the number of outputs to 16 per transaction). However, the limit of outputs, in turn, makes entirely impossible or hampers a genuine usage, such as payouts from pools or faucets to many users in a single transaction to save on fees.

[aivve]

• This also adds the limit of the extra in coinbase transaction.
• Includes the changes in a min transaction fee calculation.
• This requires a hardfork due to several backward-incompatible changes prelimiary set at height 490000.

[aivve]

BTW, #114 is the example of how the tx extra can be used to store additional data.

[aivve]

There is no any limit of the size of this additional transaction extra, therefore it can potentially be quite large.

Actually there is a limit - of the whole transaction size. But still, we don't want 250KB of external data stuffed into our precious blockchain save for an appropriate fee.