Suggestion: Transaction Fee Tracking

[yxxyun]

ouch

[tulo]

On 10/25/2019 at 11:09 AM, yxxyun said:

ouch

Well it was not bad. 100 tps on 50943666. Any idea how much was the open ledger fee after that?

BTW it seems that the fees escaleted after 4-5 ledgers. Is that expected behavior?

[Guest]

1 hour ago, tulo said:

BTW it seems that the fees escaleted after 4-5 ledgers. Is that expected behavior?

I’m not au fait with the settings of the XRPL but I must admit I have a sneaking suspicion that the escalating fee could really bring someone using the ledger real problems.

I have no idea how it affects Ripplenet and ODL,  but for a wallet software user who is unlucky enough to be sending a large amount of XRP during the same ledger(s) as some bad actor spam (which causes a fee escalation..).  it is possible (I think,) that they pay a potentially crippling fee because the software did not set a max fee.

The publicity surrounding that type of event could be bad for XRP.  Is it possible to set some XRPL wide threshold fee rate that triggers a confirmation request?   Is my suspicion wrong?

[Guest]

On reflection that trigger confirmation request could mean the spammer is able to DOS the ledger at no cost.  I don’t see a solution but I do see a potential publicity and real world problem if a spammer is able to target times for attacks to coincide with some high value transfers.

Perhaps the max fee just needs to be widely understood and implemented.

[mDuo13]

On 10/26/2019 at 3:07 PM, Tinyaccount said:

On reflection that trigger confirmation request could mean the spammer is able to DOS the ledger at no cost.  I don’t see a solution but I do see a potential publicity and real world problem if a spammer is able to target times for attacks to coincide with some high value transfers.

Perhaps the max fee just needs to be widely understood and implemented.

The server should not enforce maximum transaction costs because then normal people can't do business at all when the ledger is being DoS'd. People need the choice of either doing their business now at higher cost, or deferring business until costs decrease.

I believe the correct way to handle this stuff is to set a maximum transaction cost on the client side, preferably during/before signing, so you can't get a signed transaction that would burn a high transaction cost by accident. Then, add a setting to bypass this limit for a specific transaction. Basically, an "in case of emergency, break glass" kind of setting to make through a transaction with a big cost

ripple-lib has had such a setting since version 1.0.0. I recommend those who write client libraries in other languages add a similar rule.

[Sukrim]

Stellar seems to have a transaction type suggested that can add an additional fee to be paid to a transaction in flight. Might be worth considering, but isn't related to this proposal...

[nikb]

On 10/29/2019 at 5:01 PM, Sukrim said:

Stellar seems to have a transaction type suggested that can add an additional fee to be paid to a transaction in flight. Might be worth considering, but isn't related to this proposal...

Naively, it seems that we could just make the Fee field be a maximum. So you can set it to the maximum you want to pay, but you’re charged less (e.g. the median fee of txs in the ledger).

But that’s not as easy as it sounds and there’s a ton of game-theoretic concerns.

[Sukrim]

Yes, I prefer things to be explicit, not "up to...". A method to add fees to existing transactions (maybe even ones with 0 fees, so I can pay for transactions signed by my customers or get my transactions unstuck in high-fee times) might be a good middle ground.