Request: no fee elevation on transaction types with already "elevated" fees

[WietseWind]

With the current fee escalations on the XRPL, people are no longer getting AccountDelete transactions through: at their default 'one object reserve' Fee amount (currently 2 XRP) they are rejected because transaction queues are full.

Often even upping the fee by 50% with one extra XRP to 3 XRP will not get the AccountDelete transactions through.

I feel that, for a specific transaction with high fee like AccountDelete, fee elevation should not apply & they should go straight past the queue, as the fee is already elevated to one object ownership level to begin with.

I would very much like to see that updated in the next rippled release.

[wojake]

But wouldn't that create a situation where the transactions in a queue is delayed which can continue the queue's state of full, since transactions with high fees (like AccountDelete) is prioritized to the next ledger?

From my understanding, this would prioritize transactions that burn high amounts of XRP but if the transaction fails to enter a queue, wouldn't it mean that there are other transactions with even higher fees?

[WietseWind]

A fee as high as one owner count (2 XRP, currently) deserves to be in front of the queue if you ask me.

[WietseWind]

Quote @mDuo13 (off-Github conversation)

I agree with you that AccountDelete is a special case and it doesn't entirely make sense to apply the Fee Escalation rules to it the same way. But, I think we need to be thoughtful about how we handle this special case, because it has the potential to be a heavy-load transaction, so we want to make sure that whatever we do with it doesn't further expose the ledger to load issues. (But, the current cost is probably actually high enough that it can't affordably be a spam mechanism.)

I think the "next rippled release" is going to be a relatively fast follow on 1.8.1 focused on bug fixes, optimizations, and stability. So, I wouldn't want to rush a new policy for AccountDelete out alongside that, unless we're confident it's the best way to handle it long-term.

My reply:

I agree and understand. But the optics (to the users, judging by our support tickets) the AccountDeletes failing due to fee escalation is a direct result/sign of "the XRPL having trouble".

Regarding the heavy load transaction part: that I don't quite understand: an AccountDelete only works if the owner count is zero, it is basically just a Payment and wipe of AccountRoot data. That's pretty light compared to everything that's happening with TrustLines.

So it would make sense (imo) if AccountDelete is just the owner reserve amount (2 XRP), potentially elevated with the costs or a regular transaction. Ledger open fee being say 5000 drops, that would mean 2,000,000+5,000 = 2,005,000 drops. Elevating this with a factor does not make sense imo, and it results in actual (really) pissed off users because XUMM / the XRPL "took their XRP" / "didn't keep their promise" / [insert...]

[ximinez]

AccountDelete can also remove Offers, SignerLists, and probably a few other things. That can translate to a pretty heavy load, which is one reason the fee is so high to start with.

[shortthefomo]

Maybe that draws the case for account deletion not to be 'possibly' doing extraordinary amounts of work and rather require those to be done before deletion.

[Wietse-Livingroom]

AccountDelete can also remove Offers, SignerLists, and probably a few other things. That can translate to a pretty heavy load, which is one reason the fee is so high to start with.

That's new information for me, I thought an AccountDelete won't execute if there are still objects owned, like SignerLists and Offers.

Also, like @Mwni (quote) said elsewhere:

The 2 XRP cost of closing an account should not be seen as a transaction fee, but rather an upfront cost at the time of opening the account. That's how it's been communicated. And there's possibly not one single scenario where one could do a spam attack for 2 XRP a pop

This is another her good point: it's a reserve, not a fee. Now we're 'abusing' it as a fee, by elevating the fee.

[jscottbranson]

I agree with the logic that it's a reserve not a fee, and I can understand how end users would be frustrated when their "reserve" gets burned. Since this has been "marketed" as a reserve, maybe it makes sense to adjust the ledger behavior to be in line with the marketed expectations.

I have a difficult time envisioning account delete transactions becoming an attack/spam vector, particularly with base tx fees so low already, but many of you all are more knowledgeable about this than I am. If people are already forfeiting 2+ XRP, than it seems reasonable that the higher-fee transactions would be prioritized in the queue.

[Mwni]

It's not a reserve. You do not get it back. It is a fee, but ideally one that is fixed and completely separate from the common transaction fee.

[nbougalis]

It's not a reserve. You do not get it back. It is a fee, but ideally one that is fixed and completely separate from the common transaction fee.

You're conflating two things: there's an account reserve--the minimum balance that one needs to maintain while the account exists--and then there's a fee to delete an account.

When I created my wallets the account reserve was much higher than it is today, and an amount of XRP equal to the reserve was treated as "unspendable" (pedantry: it's not technically unspendable; you can "spend" it in some contexts). As the reserve dropped, the amount of XRP available to me increased. If the reserve had increased, more of my XRP would be treated as "unspendable".

Before the network activated support for account deletion that was the end of it: the reserve functioned effectively as an spam-protection mechanism (which is the reason behind having an account reserve), since to create an account meant committing some amount of XRP that you could not recover.

But account deletion made it possible to delete accounts, something that Arthur Britto and David Schwartz didn't implement because they hadn't come up with a zero cost mechanism to allow that. In other words, they hand't worked out how to prevent account deletion from being used as an attack vector.

Once that was sorted, the problem became that the account reserve was no longer an effective anti-spam mechanism. Without deletable accounts, the attacker could still create 50,000,000 accounts but would have to commit 1,000,000,000 XRP to do so. But with a fully recoverable reserve, coupled with a cost of 12 drops per tx, would mean that creating and destroying 50,000,000 accounts would cost the attacker around 1,200 XRP.

So deleting an account needed to impose a cost; not large enough to make deletion meaningless, but large enough to discourage abuse.

The easiest way to do that was to make the AccountDelete account expensive: the most reasonable approach, at the time, seemed to be to simply make the transaction cost some "fixed" network-controlled value; I picked one incremental reserve.

If we want to reframe this as a fixed "up-front" cost, then that's one thing, but then you're just shifting it away from the AccountDelete transaction to the Payment transaction. And how would you implement it there? Would you make a payment for 100 XRP but only 98 would be delivered? That's a support nightmare. Or would you charge it as a fee? If so, what's the difference in charging it for the Payment instead of the AccountDelete?

Also, note that using the fee logic is convenient because it already has the "burn" logic built into it. Any changes will require updating invariant checkers, and transaction analysis tools and everything else.

Lastly, the dynamic reserve logic means that the cost of an account can vary with the network's state. If you impose an "up-front, fixed fee" all you do is encourage people to hoard accounts, because if I expect that the upfront fee will increase I'll register as many accounts as I can in the hopes of selling them for a profit (i.e. more than they cost me) which I will be able to do the moment the upfront fee goes up. Conversely, people who created an account when the upfront fee was high have no incentive to reduce the fee, so why would it ever be lowered?

I think that talking about this is great and maybe we can come up with something better than what I originally came up with--God knows I don't have a monopoly on good, or for that matter, bad ideas--but I do think that the existing system is elegant. Not without it's flaws, to be sure. But elegant nonetheless.

[Mwni]

@nbougalis Thank you for shining light on the history of the matter. This is very valuable information. I want to clarify, by it I meant the irrecoverable portion of the reserve. And the "up front" statement was about how it is being perceived, not how it should be implemented. I actually think it's excellent the way it is, aside from the fact that the scaling factor applies to it aswell.

[wojake]

this has been "marketed" as a reserve, maybe it makes sense to adjust the ledger behavior to be in line with the marketed expectations.
~ crypticrabitt

I agree on this part of the argument, the problem is, it's a normal transaction just like any other transaction on a full queue.
I also see the reserve as a fee, from my understanding, the xrpl treats it as a fee but since it is being marketed as a reserve, what if we just ignore transactions with elevated fees (like AccountDelete) in the Fee Elevation mechanism, so that other queued transactions are not effected by transactions with elevated fees (2 XRP as of now).