I would like to open the discussion on zero fee transaction for Grin.
Are they technically possible and are they even desirable? I want to discuss the idea since it is intriguing, not because I think they are way to go for Grin, actually I am inclined to think it is not worth the extra complexity.
A while back I encountered two Komodo projects (SmartFi and OpenFoodChain).
To my surprise, both blockchains use a zero fee system for transactions. This aspect of zero fee transactions intrigued me. The two projects made me ponder if it would be desirable, and or technically possible, to have a portion of the Grin transactions with a zero transaction fee.
In the Smartfi blockchain they basically lock the transaction fee for a period of 24 hours after which it will be unlocked and accessible to the owner. This idea is simple and not bad, while stimulating economic activity.
For Grin, if transaction would not create more outputs than a transaction consumes, I do not see any security reasons not to allow having a temporarily locked transaction fee instead of the transaction fee being paid to miners. Furthermore, many security mitigations could be put in place to avoid misuse such as a spam attack. For example,by putting a separate cap in to place, allowing for example only 20% of the space in a block to be occupied by transaction fee free transactions. Also we could prioritize transactions with an increased locked transaction fee, to avoid users to continuously spam this free transaction pool 20% of the block space.
Below are some of the Proās and Conās of such an approach:
PROāS
Free transactions are a great way to stimulate economic activity
More transaction volume would increase the privacy of all users
Free transactions would make Grin stand out, especially since most coins which have somewhat private transactions are expensive to use.
It would incentivize transactions that do not create more outputs than they consume, hence limiting it would incentivize users to keep the blockchain small
CONāS
My biggest concern is unnecessary complexity, would having āyet another transaction typeā make using Grin more complex? Would the implementation make Grinās code more complex, which it against one of its fundamental principals, minimalism
If these transactions can be distinguished from normal fee transactions, this would break transaction uniformity which is important for both simplicity, code minimalism and privacy
Possible loss of privacy, since fee needs to be transparent and go back to the owner?
Grin transaction fees are already rather cheap, is making them lower really what users need, or do we simply have to keep improving the user experience with good wallet software
As I said above, it is not that I think this is something Grin needs since there are many conās, but it is interesting enough to ponder about, discuss the possibility and the possible proās and conās .
My first worry that comes to mind is that zero fee transactions open up a spam vector. Nothing prevents me from creating a transaction with 1 input and the maximum number of outputs. While the attacker can only create full blocks, I think it may be enough bloat to make Grin unusable if sustained for a long enough period of time.
And an even better way to invite spam, as amply demonstrated by Nano currency.
I donāt see how, unless you get more aggregation. For which we have much better proposals. More transaction volume that is unwilling to pay the current sub-cent fees is unwanted bloat. It is unreasonable to expect thousands of computers worldwide to relay your transaction
and store information about your it for eternity for free.
To me, nano stands out in a negative way for their zero fees.
For that reason, if we would ever consider zero transaction fees for some part of the blocks, it would only be for transactions that do not create more outputs then they consume. Also the fee would increase if the 20% of the āfree transactionā block space would run out, so users would start to compete only not in paid fee, but in locked fee. In this way the bloat would be limited to only the kernels that are left once an output is spend.
Yes, it is. So if we would ever consider having some block space for free transactions, this would be a minimal requirements.
Again, not arguing that we ever should go for zero transaction fees, I think there are more important things to improve such as wallets with one time use addresses, multiple accounts and coin-swap. But the idea still intrigued me, hence I opened this discussion.
The biggest issues as far as I can see are the extra complexity and loss of transaction uniformity which outweigh the benefits which are minimal since transactions are sufficiently cheap at the current price of Grin.
B. Transaction Flooding. A malicious entity could send many unnecessary but valid transactions between accounts under its control in an attempt to saturate the network. With no transaction fees they are able to continue this attack indefinitely. However, the PoW required for each transaction limits the transaction rate the malicious entity could generate without significantly investing in computational resources. Even under such an attack in an attempt to inflate the ledger, nodes that are not full historical nodes are able to prune old transactions from their chain; this clamps the storage usage from this type of attack for almost all users.
D. Penny-Spend Attack. A penny-spend attack is where an attacker spends infinitesimal quantities to a large number of accounts in order to waste the storage resources of nodes. Block publishing is ratelimited by the PoW, so this limits the creation of accounts and transactions to a certain extent. Nodes that are not full historical nodes can prune accounts below a statistical metric where the account is most likely not a valid accountā¦
It seems like it requires a little bit more that just prunning.
The problem is that what is one second for a phone can be a millisecond for a GPU. Nano has a lot of trouble balancing the need to limit spam from powerful hardware like GPUs or even ASICs and the need for a simple phone to solve PoW in reasonable time. I remember years ago watching many dozens of spam txs per second flying across my screen on a nano block explorer. That resulted in dozens of GBs of bloat added to their chain in a matter of weeks.
If in the future Grin could let go of keeping all transaction kernels (discussed quite a few times in the past), this would change the situation. In that case Grin would not only become hord resistant, but also bloat resistant. In such a case spam would result in a minor bloat since only the kernels up to to an set event horizon point need to be kept, after which they are not important anymore. Of course this would only work if we have the additional requirement that no more outputs are created then used.
In the current situation the bloat could still be significant. How many transactions fit in a block (I could not find this back)? The bloat would be 20 bytes (transaction kernel ) times the number of transactions per minute times 0.2 (for 20% cap).
Zero fee transactions also incentivize empty blocks for smaller miners. Thereās no benefit for the miner in trying to fill a block with transactions. Or, they incentivize the miner to fill the block with garbage txs so that others spend more time validating the block. Not sure if these are likely to happen but it changes game theory.
According to this chart, the fees trippled this year. I wonder what caused that.
I agree that fees are necessary for spam protection, but I wonder if there is a mechanism to lower fees in Grin if the price of Grin will rise. 0.03 Grin at 30ct/Grin is different from 0.03 Grin at 100$/Grin.
Great, I didnāt notice.
When you say āagreeā, does that mean that there is a majority vote, and an individual node with a different setting would do nothing?
so if someone pays coffee with lightning 0.5$ with no fee ,but if he pays with Grin 0.5$+ fee or merchant can adjust fee in this 0.5$
i mean it can mix a consumers mind ā¦like that
In whatever way you reach social consensus that a large majority of nodes will adopt the new setting. Individual nodes that keep the higher base fee will stop relaying transactions, but still function otherwise. Miners that keep the higher base fee will start mining empty blocks.
So youād want at least all the known pools to agree.
.