Now I understand why the time of booting node testnet is much longer than mainnet and size is bigger as well. So the proposal to increase the fee could be first option.
Then, is there such way to ‘refresh’ testnet from mainnet (like fork) to clean testnet?
I did not realize it was that cheap 
.
Can we even address this issue using fees? Even if you would increase the fee 10x, it still would be cheap for anyone who really wants to create spam.
Alternative solutions to a fee bump that I could think of are:
Either way, that would be a consensus change, so would be a fee bump.
Another question came to my mind. Can miners not already spam the chain since they can create mining outputs freely? Or do mining outputs have a special range-proof to proof all outputs sum to the mining reward of 60 grin? There is little to no information about mining outputs and how they are special to my knowledge.
We should raise the fee to a level that makes spamming the network expensive, while still keeping it affordable for the average user. A 10x increase is too small, I’d suggest going with 200x instead. That would bring the standard transaction fee to 4.6 GRIN instead of the current 0.023 GRIN.
Bitcoin fees are dynamic in contrast and not require hardcoding some values, you can raise accept_fee_base at your node and nobody will make txs using your node for wallet API
I dont think we should increase fee, but possibly make it dynamic, like at Bitcoin.
Next time Grin price can increase and you will require to change code again, this is not how decentralization works 
Currently Grin market is not liquid and we can not use oracles, cause lack of DEXs and so on, BEAM uses such oracle and writing price to every block, so idea can be taken from here.
Interesting if we can reproduce this case at Testnet
i made codex write a regtest for it and it’s true.
also how is it possible to increase fees like that? if the spammer is a miner with own hashrate, he can still bloat the blockchain for the expense of the hashrate.
What do you mean? In general, Grin fees works the same way as in Bitcoin, so I’m not sure I understand your claim.
By default, Bitcoin node cannot accept anything below 1 sat/vbyte, in Grin we also set a minimum amount, you can increase it if necessary, when the blocks are full and you want your transaction to be included into the next block, there’s no difference here between Grin and Bitcoin.
Price increase would not be the issue, since a miner could lower the minimum amount individually, so they can accept lower fees transactions along with all the others. That’s what you can observe on Bitcoin network, where pools start accepting transactions with the fees below 1 sat/vbyte.
In our case we have a price decrease, so it becomes cheaper to spam the network and you can’t increase the fees individually in order to stop the spam, because it won’t work, it should be a collaborative effort of everyone, essentially a hardfork.
Sure, they can do it, but it wouldn’t make economic sense for them.
that means grin miners mine without profit incentive?
i think no matter the grin price, fees should be arranged in a way so the fees compensate hashrate, or better, miners shouldn’t just sell for less than the expense of mining.
a similar issue exists with monero. mining is so unprofitable, the hashrate stays low enough for a bad actor (like qubic) to target the network hashrate. maybe it’s a demand problem that voluntary miners are enough to supply the market.
if every miner sold for the profit and not for the “good”, then the economics of mining would be more resistant to a potential bad actor? if i didn’t get it wrong like maybe i messed up correlation and causation, this might be the case?
This implicitly says grin price dropped 200x lower than what you or anyone anticipated, which is not the case surely. At best 5x lower than anticipated, anyone knew at least 0.10$ would be reached.
Also, there are alternatives to increasing fees. E.g. proof of work per output is a reasonable solution if you ask me that is independent of market prices, range-proof adjustment to proof value is above dust level, etc. Simply increasing the fee with 200x sounds like an insane shift in incentive distribution towards miners…
At Bitcoin tx can sit at mempool waiting miners to pick it up and mine, so people can choose amount of fee and calculate possible blocks amount till 1st confirmation.
Sorry @ardocrat I still don’t understand you. I don’t see how the part you quoted related to what you wrote.
Grin works exactly the same way as Bitcoin here.
I mean grin tx with low fee is not sitting at mempool at this case, just instantly rejecting by API at node, I found such issue when took old node config with too high accept_fee_base.
I agree that a higher value of accept_fee_base is desirable. Not 200x, but somewhere in the range 10..100.
However, migrating the entire network to a new value in a non-disruptive way is a challenge. If a pool majority adopts the higher value before the majority of wallets starts using the new value in fee calculation, then users will find their transactions failing to confirm, and may not be able to figure out why.
It’s obviously much better if wallets are upgraded before pools are. Then users will pay a few cents too many for a while, which is of very minor concern.
So, a plan to raise accept_fee_base should start with getting all widely used wallets to adopt the higher value, in anticipation of pools following suit.
The best time to coordinate such a change is along with a wallet affecting hard fork, since that requires everyone to upgrade anyway.
However, we have no hard fork in the pipeline. The next best thing is to decide on a schedule for upgrading wallets and upgrading pools and publicize it wide and far.
We could also generalize the configuration of accept_fee_base to support multiple values, each accompanied by a starting date. Then would make it far easier to coordinate the migration.
For instance, everyone would just agree to use
accept_fee_base = 20000000 starting from Jan 1, 2027,
and keep using the current accept_fee_base = 500000 until then.
In case of rasing the base fee, I would prefer to go for the lower end of that range, e.g. 10x. Regarding base_fee, does that only affect transactions submitted via the API by a wallet to the node or also transactions propegated by the node? It would be nice if any node can decide not to propegate transactions with a too low fee. In that way mining pools can easily adjust and protect against spam attacks.
My example increase was 40x, which makes a standard 2-input 2-output tx cost close to 1 Grin, which at current prices seems reasonable (but uncomfortably high if Grin price increases 10x).
Even at the current rate, no one finds it worth it to spam the network. Seems odd trying to fix something that’s not happening. Go through all that effort to raise transaction fees directly, just for grin price to spike? Or is your thinking that grin isn’t going up in value? Or do yall want more profit from tx fees? There seems to need to be an alternative reason to want to raise fees since no one is spamming the network currently. I don’t know what the real reason is, maybe just trying to kill the project, cuz ya, community will always be against higher tx fees.
These boards have basically become a council echo chamber anyways so honestly I don’t know why I bother. Ardocrat already said it’s not happening so just stop already.
if you want to protect the network by raising transaction fees indirectly, I know how to do it… but you won’t like the answer… raise the price of grin. That means to buy grin not btc! I know how dare I suggest such a thing. I bet each and every one of you council members, hold more value in btc then grin, sucks for you, that 50% drop musta hurt, grin price still doing fine
Your attempt to attack the grin chain by raising fees directly will fail! Sorry, not sorry.
Think about it, if you did directly increase transaction fees by 200x like was suggested, and grin hit all time high again (very likely), how much USD would it cost to send 1 grin?
Exactly, imagine at all time high at 200x increase in fees… even 40x at all time high would basically kill the chain… and you need to hard fork the entire chain just to change it back again? This is a hella bad idea guys. Do not increase tx fees directly (no duh)
You will notice the very same behavior in Bitcoin if you are trying to send a transaction with a fee lower than what’s set in node’s minrelaytxfee value.
