Zero fee Grin transactions?

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 :grin:.

Links to previous discussions on this topic

https://forum.grin.mw/t/why-are-there-transaction-f
ees/8622/4

2 Likes

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.

2 Likes

Have you read https://github.com/mimblewimble/grin-rfcs/blob/master/text/0017-fix-fees.md ?

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.

This is addressed in the RFC.

3 Likes

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.

1 Like

I donā€™t see how exactly Nano is dealing with the spam. Taken from their whitepaper:

Unlike Bitcoin, the PoW in Nano is simply used as an anti-spam tool, similar to Hashcash, and can be computed on the order of seconds

I guees we have to read the Hashcash paper to know more about http://www.hashcash.org/papers/hashcash.pdf

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.

2 Likes

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.

5 Likes

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).

1 Like

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.

2 Likes

why LN bitcoin choosen 0 fee ? i dont understand really.

Lightning charges routing fees on every tx.
Which serves both as reward for routing nodes and as DDos protection on the LN network.

2 Likes

From my perspective. Current fee is cheap, zero fee is degrading the value.

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.

Yes, people running nodes (including pools and miners) can just agree to lower the setting

#base fee that's accepted into the pool
accept_fee_base = 500000

in grin-server.toml

Which might makes sense if Grin is priced above $3 for a longer period.

2 Likes

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

thnx.

There is still a fee. The merchant just sells coffee inclusive of fee for $0.5 (which btw, would only cover a few sips in most coffee shops:).

Just like in European stores, all consumer prices quoted are inclusive of tax.

1 Like

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.

2 Likes

Interesting, I didnā€™t know much, thanks for the information!!

The Nano Blockchain has been spamed by a 14 year old kid, causing network-wide settlement delays:
https://www.reddit.com/r/CryptoCurrency/comments/uqbllg/the_nano_network_has_been_subject_to_ddos_and/

Although lack of fees is one DOS vector, there are apparently several other DOS vectors at play in this recent attack.