I’ll be doing some more reading about Grin. A number of community members on twitter have already sent me a bunch of links to check out.
Here’s a question that comes to mind: How would Grin deal with a potential spam attack?
For example, Zcash was recently spam attacked — the chain was bloated from less than 40GB last year to nearly 220GB today. The attack was extremely cheap to orchestrate on Zcash because they have a foolish fee mechanism where all transactions have a fee of 0.0001 ZEC — no matter how many outputs a transaction has. Moreover, the ECC (the corporation behind Zcash) can’t even address the issue with their proposal (ZIP 317) until they clean up a ton of technical debt first, so Zcash will likely continue to be spam attacked for quite some time.
I was able to find this link:
While it does go over how bitcoin, Ethereum, and basically every other blockchain would deal with a potential spam attack, it doesn’t explicitly point out how Grin would. ツ
Grin already uses sensible fees that are directly proportional to bandwidth and storage costs [1]. So the only thing that could be done if we see unnatural increases in block size that are suspected to be spam, is to scale up the fees by a large factor, e.g. x10.
This would require
having as many network nodes and mining pools as possible change the accept_fee_base value in the node configuration, and
also making wallets default to using these higher fees.
It would be quite a headache to coordinate these changes across all node and wallet implementations, but this seems to way to go if we are determined to make spam more costly…
As long as the networkof nodes and miners have changed to the higher fee, transaction from the spammer with low fees will not be accepted and not be incorporated in blocks.
Can it be done in such a way that network fees can be increased or decreased automatically like ETH? When the network traffic is congested, the cost is high, when the network traffic is low, the cost is low.
Grin already supports 16 different fee prioritization levels to let users pay more fees to get their transactions included sooner.
In theory, minimum relay fees could be made dependent on mempool size for instance, but it seems premature to add such complications when blocks have never been full yet.
In short, transactions with a fee below the minfee will not be relayed and kept in the mempool.
For clarity, let’s adopt the following definitions. Let the feerate of
a transaction be the fees paid by the transaction divided by the transaction
weight with regards to block inclusion (Transaction::weight_as_block).
Let the minfee of a transaction be the amount of fees required for relay and mempool inclusion.
A transaction paying at least minfee in fees is said to be relayable.
Also, the weight of the fee depends on the amount of space used:
The only way to avoid this mismatch between relay and block inclusion incentives
is to make the minimum relay fee be proportional to the block weight of the
transaction.
A user can always outcompete the spammer for block space using a higher fee:
@JasperKai, just like with Bitcoin, higher fee gets priority:
When blocks fill
miners are incentivized to pick transactions in decreasing order of feerate.
Ideally then, higher feerate transactions are more relayable than lower feerate ones.
Ah, so this is only necessary, because wallets today don’t do fee estimation. I see now. Obviously its not a concern today, but at some point we probably want wallets to provide fee estimations based on chain congestion and user priority. Until then, we are somewhat vulnerable to a spam attack, if someone was willing to pay for it.