[upper bound fees] (Version: [1.10.0])

[shortthefomo]

Summary

rippleitinNZ provided a very insightful thread around some very unfortunate transactions on the XRPL.

• "That means those 4 transactions alone account for almost 3% of all fees ever burned on XRPL."
• "ALL transactions that paid 1 XRP or more in fees totaled 4959129.962 XRP - in 1055572 transactions -accounts for approx 44% of all fees burned. That equates to roughly 4,959,127,950,000 transactions that could have been paid at 0.00001XRP with the excess XRP"

Highlighting that there are many cases where by transactions are consuming excessive fees, the ledger provides no upper bound validation. So these often poorly coded transaction go though.

Motivation

The ledger provides many safety gates to protect its self from spam, usually via fee escalation. We should extend at very least some basic protections to the user as well.

@WietseWind pointed out that there are several lib, wallet and cluster fixes already implemented by many of the network operators already. Thank you every one for this.

However not everyone will use these services, and with no cap/error/warning/confirmation at ledger level this is still more than possible today.

Solution

Two viable solution have been covered already via @mvadari and @WietseWind

• A cap on the submit RPC command of 2x account reserve, enables by default - but if you really want to: overrule with a submit RPC option. (The submit RPC solution is simpler - no amendment needed, and it could be configurable per-node.)
• A flag (Anything in the transaction processing layer (e.g. a flag) would need an amendment, and all nodes would have the same limit.)

[intelliot]

Personally, I don't think the transaction-breaking flag is worth doing. The restriction on the submit RPC command should be fine if it returns a very helpful error message, and the cap is configurable. I think it's technically an API breaking change, but I think it's a rare enough edge case that it's OK not to bump the api version.

[WietseWind]

I think the submit command should protect against this but allow for opting out with an option for the submit command, just like the fail_hard option.

E.g. fee cap = 2x account reserve, but if you really want to see the world (your account) burn, you can submit with no_fee_protection or something like that.

[intelliot]

high_fee: true

[WietseWind]

@intelliot I don't think high_fee describes what the option will allow. This suggests it'll add/set/... a high fee. I think it makes sense to name the property in a way where someone can explicitly realize they opt out of something (protection against failure).

[MarkusTeufelberger]

force: true?