0076 XLS-76d: Min Incoming Amount

[xrpl365]

XLS-76d - Min Incoming Amount

Title:       Min Incoming Amount
Revision:    3
Author:      Chris Dangerfield @xrpl365
Affiliation: XRPL 365 Ltd

Attribution: Khaled Elawadi @khaledelawadi

Abstract

Based on an original idea by Khaled Elawadi @KhaledElawadi, this proposal introduces a new feature to the XRP Ledger that allows an account holder to specify a minimum amount of XRP that can be received.

This feature is designed to prevent what is commonly referred to as "dusting," where small amounts of XRP are sent to an account, potentially cluttering an account with unwanted transactions.

Rationale

Dusting attacks involve sending tiny amounts of value to a large number of wallets. Currently, XRP Ledger accounts can receive any amount of XRP, regardless of how small. While this might seem harmless, dusting can lead to cluttered transaction histories, potential privacy risks, and significant ledger memo spam.

The Min Incoming Amount feature aims to mitigate these issues by allowing account owners to set a threshold for incoming transactions. Any transaction below the specified minimum amount will be automatically rejected, ensuring that the account only receives transactions of value that meet or exceed the defined threshold.

Amendment

The proposed change introduces a new field on the AccountRoot ledger object called sfIncomingMin, which is of type SF_AMOUNT.

This field allows users to define the minimum amount of XRP that their account is willing to accept.

New Field on AccountRoot

Field	Type	Required	Description
sfIncomingMin	Amount		Specifies the minimum amount of XRP (in drops) that the account will accept.

Updating the AccountSet Transaction

To set, update or remove the sfIncomingMin field, users would use the existing AccountSet transaction, so it would be updated to store the new field.

Omitting the optional field would do nothing, it would not change any setting that currently exists.

Setting sfIncomingMin to zero would remove it from the object, essentially disabling the feature.

Failure Conditions

• If amount != XRP amount
• ⁠If amount < 0
• ⁠If incoming min is NOT set and amount is 0

State Changes

• Updates the Field sfIncomingMin on AccountRoot Ledger Entry.

Examples

Setting a Minimum Incoming Amount:

{
  "TransactionType": "AccountSet",
  "Account": "rExampleAccountID",
  "IncomingMin": "5000000" // 5 XRP in drops
}

Removing the Minimum Incoming Amount:

{
  "TransactionType": "AccountSet",
  "Account": "rExampleAccountID",
  "IncomingMin": "0" // Removes field from the object and disables the feature
}

Implementation

IF Transaction IS Payment
   AND Amount IS "XRP"
   AND DestinationAccount HAS IncomingMin
   AND IncomingMin GREATER THAN Amount
   THEN
   REJECT TRANSACTION
ELSE
   // NORMAL FLOW
END IF

Flows

Flow 1: Setting a Minimum Incoming Amount

Scenario: Sarah wants to prevent her account from receiving small, insignificant XRP transactions (commonly known as dusting).

1. Sarah performs an AccountSet transaction and sets an IncomingMin of "500000" drops.
2. Sarah's account now has protection against receiving a Payment less than 0.5 XRP.

Flow 2: Receiving a Transaction Greater than the Minimum Incoming Amount

Scenario: John, unaware of Sarah’s new setting, tries to send her 100 XRP as a token of appreciation.

1. John initiates a payment transaction of 100 XRP from his XRP wallet.
2. The Payment is unaffected by the change Sarah made and the payment is received gratefully.

Flow 3: Receiving a Transaction Less than the Minimum Incoming Amount

Scenario: "Nasty Nick", a known duster, unaware of Sarah’s new setting, tries to send her 0.00001 XRP, along with a tricky memo.

1. Nick initiates a payment transaction of 0.00001 XRP from his XRP wallet.
2. The Payment is rejected by the ledger when evaluating the incoming Amount vs Sarah's IncomingMin.
3. Sarah's transaction history is unaffected and she never even knew what Nasty Nick tried to do.

Flow 4: Removing the Minimum Incoming Amount

Scenario: After some time, Sarah decides she no longer needs the minimum incoming amount restriction on her account.

1. Sarah performs an AccountSet transaction and sets an IncomingMin of "0" drops.
2. The IncomingMin field is removed from her Account Root.
3. Sarah's account is no longer protected.

Flow 5: Transaction Handling with Min Incoming Amount Set

Scenario: "Nasty Nick", is back, and once again he tries to send her 0.00001 XRP, along with a tricky memo.

1. Nick initiates a payment transaction of 0.00001 XRP from his XRP wallet.
2. The Payment is accepted by the ledger because the protection Sarah once had has been removed.
3. Sarah's transaction history now contains a new transaction from Nick, and a bunch of other dusters.

Flow 6: Setting a Minimum Incoming Amount with Incorrect Values

Scenario: Sarah wants to re-enable the protection on her account, after the nasty surprise from Nick.

1. Sarah performs an AccountSet transaction and sets an IncomingMin of "-500000" drops, an invalid value.
2. The transaction is rejected with an error, and Sarah is informed that the value must be positive.
3. Sarah decides to try again with a correct value - GO TO Flow 1.

Considerations

Backward Compatibility
The addition of the sfIncomingMin field will be optional. Accounts that do not set this field will continue to accept all incoming amounts as usual.

Usability
The Min Incoming Amount feature is simple to configure and will be integrated seamlessly into existing wallet interfaces using the familiar AccountSet transaction type.

Potential Misuse
While this feature prevents dusting, users should be cautious about setting the threshold too high, as it might prevent legitimate small transactions from being accepted.

Partial Payments
Partial payments allow a sender to specify a maximum amount they are willing to spend, and the transaction delivers as much as possible of the destination amount, potentially less than the full amount specified by the sender. If a partial payment is made and the amount delivered is less than the specified sfIncomingMin threshold, this creates an edge-case where the tiny amount may be legitimate, yet be rejected. It makes sense for the sfIncomingMin to apply to the actual amount received, as this aligns with the goal of preventing dusting, but means the code will need to use the delivered_amount to prevent partial payments from being used as a work-around to this amendment.

Effect on Reserves
If an account's balance marginally drops below the account reserve, this creates an edge-case where the user will not be able to receive a tiny amount as it is blocked by sfIncomingMin and being below the account reserve would mean they cannot perform an AccountSet to temporarily remove the limit. The only option would be to receive an amount greater than sfIncomingMin which in 99.9% of cases should not be problematic given the it would ideally be set at 1 XRP or less, however in a scenario where the limit was set artificially high...

Maximum limit
This spec does not allow for a maximum value on the sfIncomingMin field. Adding such a limit may be seen as protecting a user from setting an overly high value, however on balance given the ease at which a limit can be reduced or even removed, it is felt that the arbitrary limit removes user choice.

Account Locking - Reserve & No Maximum Limit.
There is an edge case where a user is not prevented from setting a very high limit and the account balance drops below the reserve creating a situation where the account would essentially be rendered unusable. If this edge-case were considered serious enough to require a solution, either a sensible maximum limit could be introduced OR an additional step on transaction rejection to check the account balance is not below the reserve. A maximum amount limit adds very minimal overhead to the amendment but does remove user choice. Testing for account balance would introduce a more intensive test that needs to be applied to every rejected transaction. On balance the arbitrary minimum does offer protection against the ege-case and does not conflict with fundamental principle of the proposal.

Conclusion

The Min Incoming Amount feature provides a straightforward solution to the problem of dusting on the XRP Ledger.

By introducing the sfIncomingMin field on the AccountRoot ledger object and utilizing the existing AccountSet transaction for configuration, account holders gain the ability to reject small, potentially unwanted transactions.

This enhances account security and reduces clutter, making the XRP Ledger more user-friendly and secure.

[tequdev]

When doing a token swap, meaning Account=Destination Payment, there would be no need to check using the new field.

[xrpl365]

You mean where you are sending to yourself, you don't apply the limit?
If so, yes, this would be an easy check to add.
As for its value I would be interested to hear other perspectives.
My own view is that if the overhead of the check is minimal, then it doesn't hurt, it merely adds flexibility.

[mvadari]

What about other transactions with a destination that also send funds, like EscrowCreate, PaymentChannelCreate, and CheckCreate?

[xrpl365]

I suppose we would have to evaluate the need to support other tx types.
If we were to remove the check for transaction type and simply test any incoming tx with an amount in "xrp" then it would quite possibly reduce the overhead as its one less test, and protect them all. However, that might add complications down the line. If this proposal were to gain traction though, this question would certainly need to be considered more thoroughly. Thanks for the input.

[KhaledElawadi]

For sure we should anticipate a need to add other wallet filters and features as different types of tokenised assets are processed on chain.

An interesting idea of yours Chris to expand the remit to allow the user to apply the same set XRP value globally to other tokens.
That could eliminate spam/dusting from all token issuers and users at the same time. 👍

[xrpl365]

I don't think we would apply the min amount to all currencies, just XRP.
I would prefer to find a solution that allowed the user to set this on a token basis, so it makes sense to consider adding to the trust line, but... I've really not given it that much thought cuz I decided it's best to keep it simple and just support XRP first.

Somewhere on the doc I do say that if support for other currencies is deemed worthwhile the spec could be expanded or a second amendment created.

[KhaledElawadi]

Agreed, I think it's very wise to apply the minimum threshold filter to XRP first.

However, we should anticipate that spammers might choose to create their own tokens and/or switch to other tokenised assets in the future.

Flexibility could be key in those scenarios.

[KhaledElawadi]

Ok, so quick update from some X conversations..
@TheShillVerse loves this idea and has also requested an additional filter which he refers to as "Max Memo Size".

He would like the option of a low pass filter based upon a user adjustable maximum threshold size, so I will make a note of that and add it to my list XRPL Wallet Filters.

[xVet]

Congrats on the first spec 🤗

Would this be easier done on the wallet UI/UX level?

It's a cool spec!

[KhaledElawadi]

They are unsolicited ultra low payments.

Who on the XRPL is legitimately making those types of unwanted payments?

We're talking about many fractions of a penny.

[xrpl365]

They are unsolicited ultra low payments.

Who on the XRPL is legitimately making those types of unwanted payments?

We're talking about many fractions of a penny.

Someone who is using the memo for a real use case and is doing a low value payment to achieve it. Or it could be some king of future micro transaction. You can't paint with a broad brush.

[ximinez]

Who on the XRPL is legitimately making those types of unwanted payments?

Scenario 1

1. Scammer sets up an account with a limit of 10,000 XRP.
2. Scammer runs their scam.
3. Victims sending more than the limit get ripped off.
4. Victims sending less than the limit now have their account fees permanently(?) messed up with no way to fix them.

Scenario 2

1. Attacker sets up an account with a limit of 100 XRP.
2. Attacker has funds on an exchange. Exchange has not updated their software to check for minimum limits.
3. Attacker tries to send 50 XRP from their exchange account to their account.
4. Repeat 1000 times.
5. Exchange burns their entire operating account's XRP balance on fees. (10*2^1000 is greater than 10^16, which is about 1/10 of all the XRP in existence.)
6. If exchange manages to make itself whole, it's still stuck paying exorbitant fees to use it's operating account.

Evil people are creative. You've gotta stay one step ahead of them.

[ximinez]

It helps on a per-user basis, but it doesn't help with the full-history/infra storage problem - these transactions will still have to be stored, since they'll require a tec error.

@mvadari The error doesn't necessarily have to be a tec, at least when applying against an open ledger. This would prevent the transaction from being written to the ledger, and would prevent it from propagating. If a clever attacker orders transactions such that their transaction does propagate, then they'd pay a fee.

[KhaledElawadi]

Who on the XRPL is legitimately making those types of unwanted payments?

Scenario 1

1. Scammer sets up an account with a limit of 10,000 XRP.
2. Scammer runs their scam.
3. Victims sending more than the limit get ripped off.
4. Victims sending less than the limit now have their account fees permanently(?) messed up with no way to fix them.

Scenario 2

1. Attacker sets up an account with a limit of 100 XRP.
2. Attacker has funds on an exchange. Exchange has not updated their software to check for minimum limits.
3. Attacker tries to send 50 XRP from their exchange account to their account.
4. Repeat 1000 times.
5. Exchange burns their entire operating account's XRP balance on fees. (10*2^1000 is greater than 10^16, which is about 1/10 of all the XRP in existence.)
6. If exchange manages to make itself whole, it's still stuck paying exorbitant fees to use it's operating account.

Evil people are creative. You've gotta stay one step ahead of them.

In scenario 1 doesn't make much sense.

If scammers are wanting muliple payments from their victims then why would they set their min threshold so high?

Anyone that sends payments that are lower than the threshold to an account they are unaware of the threshold gets their asset back and the network fee for their next payment has been ratcheted up one notch on their account and their account only.
Could have a 24 hour reset on that as I don't see why genuine mistakes should be punished I definitely.

In scenario 2 you're simply talking about high frequency payments between two accounts and a reason why the general fee escalation protocol should only apply to individual accounts sending payments and not the entire network as a whole.

[LadyK-0]

I've actually talked to some people about the xrp dusting attacks and they literally thought it carried the same security risks that it would on the Ethereum network, but we don't have smart contracts, so on the xrpl you just received an asset(unwanted.) I do wonder the percentage of people who think that. However I think this amendment would have a positive affect on the perception of preventing dusting attacks. But also create other negative feedback. In an environment where there is open permissionless participation you just can't stop people from doing negative things. So everyone sets a minimum xrp acceptance, what if they start sending dusting attacks on other token trustlines, not as many holders but still possible even with this amendment. This is what the fee escalation is suppose to prevent right, the spamming of the ledger. Overall I don't think this amendment would hurt anything. Unless creating an extra check on accounts and transactions would slow it. Just some thoughts.

[KhaledElawadi]

Thanks Lady K.

You're right there isn't currently anything preventing dusters/spammers from using other low value tokens to mess up people's accounts with unsolicited payments. We can modify this proposal to include all assets and all transfer/payment methods.

The fee escalation protocol is slightly different thing that we can also upgrade namely because it's a global punishment that hits everyone.
For an attacker/saboteur that's classed as a win. I've made a separate proposal on X on how we can put a stop to that too.
You can find it at this address:

https://x.com/KhaledElawadi/status/1827294767413149932?t=RIh-e4WWiI-zKzmG0vqAxg&s=19

[xrpl365]

I've actually talked to some people about the xrp dusting attacks and they literally thought it carried the same security risks that it would on the Ethereum network, but we don't have smart contracts, so on the xrpl you just received an asset(unwanted.) I do wonder the percentage of people who think that. However I think this amendment would have a positive affect on the perception of preventing dusting attacks. But also create other negative feedback. In an environment where there is open permissionless participation you just can't stop people from doing negative things. So everyone sets a minimum xrp acceptance, what if they start sending dusting attacks on other token trustlines, not as many holders but still possible even with this amendment. This is what the fee escalation is suppose to prevent right, the spamming of the ledger. Overall I don't think this amendment would hurt anything. Unless creating an extra check on accounts and transactions would slow it. Just some thoughts.

Protecting other currencies or even or types of tx is likely possible too but I'd like to see the kind of take up a small amendment like this had before adding more functionality. You're right about the effect on performance, and this would certainly need to be considered, benchmarked and tested but on first review I doubt the overhead would be significant.

Thanks for contributing your feedback.

[Mwni]

If the big wallets like Xaman backed this and encouraged their users to set such a minimum amount, it could effectively eliminate the spam problem.

[KhaledElawadi]

Agreed.

In a way we would all be securing the network against targeted attacks by using the filter to block them.

I like the fact the threshold can also be varied by the user should a well funded attack come in.

[shortthefomo]

Wonderful idea LGTM

+1 for "no limit" on Maximum limit as this also opens up other use cases for businesses.