fatfinger prevention methodology

[Hyung-bharvest]

Summary

The concept of fees, gas, and gas-price is super confusing for normal delegators.
It is very likely that delegators will keep make mistake on transaction fee setting.
Especially when a tx generator put gas amount to gas-price, the result is catastrophic.
We should discuss on the prevention methodology of these kinds of mistakes.

Proposal

Set a parameter on genesis.json called "max_fee".
Any transaction with more than max_fee will be rejected and refunded minus max_fee
max_fee can be 100atom(enoughly high) so we don't interfere natural economics of chain.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[fedekunze]

imo this should be done on the client side, not on genesis. Also if you have a ledger you already can check the total fees on the display. #3689 also addresses this issue with a different approach

[Hyung-bharvest]

imo this should be done on the client side, not on genesis. Also if you have a ledger you already can check the total fees on the display. #3689 also addresses this issue with a different approach

Why can't we have in both sides? Why we can't do that on genesis? Please elaborate possible side-effects. Not all clients are perfect safe in blockchain world. It will be very helpful if the chain has a safety hurdle.

I checked the #3689 and #3653 but both are not covering the problem completely.
I know that suggested method will interfere the liberty of paying more than 100atom as a fee.
But it is very unnecessary for most of users and it can be sacrificed for safer network for mass users.

[alexanderbez]

To be honest, I'm not sure we should have this in genesis. We already have a prompt when sending txs via the CLI (can't really do this via REST) and the ledger also required you to review the tx. However, I can still see this being beneficial. Would be interesting as a governance proposal.

[Hyung-bharvest]

We want to hear about any possible side-effect from dev team before voting. I have not much of an idea of technical problem which might occur by this. Teams will know much more than validators and delegators.

Also, reviewing might help but many people can be not very attentive on review. And currently delegators need to withdraw and delegate quite often, increasing the risk of inattentiveness.

[ValarDragon]

I am opposed to enforcing a price ceiling on chain without significant macro-economic rationale. This just seems too arbitrary. This also doesn't scale well to post IBC, is there now a new parameter for every token to appear on the hub? Thats too much work, especially in the crypto world where 10x price differences month-to-month isn't unheard of.

This should be the responsibility of wallet software, if you would like gaiacli / wallet software to standardize around "If someone attempts to make a tx with a gas of over 100 atoms, print out a warning such as Holy smokes, are you sure you want to pay 100atoms???", I think thats very reasonable, and wallets can move faster than onchain governance.

[Hyung-bharvest]

I am not denying client side protection. I think it is a seperate topic. Good client will do that but not all will. And it is beyond our hands.

The hurdle in genesis will work as the final rescue when all the procedure on the front failed.

I agree with your statement about multi token fee thing. If we setup with several major tokens for the hub, at least we can prevent 95% of transaction.

I know crypto price moves very fast, but +1,000% in weeks for well spread crypto is practically very rare so I think we can deal with it. 100atom max_fee will work well between +1,000% and -90% without changing the param.

But, the governance proposal on max_fee change should be applied without chain halt using parameter gov. Hope it will be ready soon.

Basically I hope the network could be practical enough for mass users' risk sake even though it might sacrifice some theoretical consistency.

[alexanderbez]

Yeah my gut tells me this is not a good idea in the long term -- just seems too complex. This should really only be done client-side.

[jackzampolin]

Just jumping in here, Agree with @alexanderbez, this IS NOT something we want to enforce in protocol. Client side tooling should provide guardrails here. The answer to "This knife is too sharp, and I don't want users to cut themselves" is not "make the knife more dull" its "put the knife in a sheath"

[Hyung-bharvest]

Guys, thank you so much for expressing opinions. While I still don't get the exact practical reason why all devs against this, I am also feeling that all professional devs would not like this kind of manipulated fix in such a well organized program.

Please understand that because I am not used to big size programming, I don't have much understanding on structural side of a program.

[alexanderbez]

Absolutely valid concerns @dlguddus! Thank you for bringing issues like these up for discussion. It fosters excellent discourse that makes our community and software thrive. Please don't hesitate to bring up questions and concerns in the future :)