Penalizing the creation of new "dust" accounts

Hi all, I would like to propose an idea for discussion. What would the pros/cons be to penalizing the creation of new "dust" accounts? If it is desirable to penalize the creation of dust accounts, how could/should we penalize them?

In one respect an open transaction is no different than a receive transaction to the network. But I think there's a hidden cost to every new account added to the ledger because of these factors:

  • Creation of millions of dust accounts is a powerful weapon for spammers
  • Horizontal pruning of the ledger is a much more challenging long-term problem than vertical pruning; it may require eventual creation of specialized "historical" nodes; it may require periodic manually-reviewed/researched purges of dust accounts that can be proven to have been created by spammers (this would need to be done very carefully)
  • There is additional data storage overhead for the node which scales on a per-account basis (e.g. time since use)

I know there are some legitimate uses such as faucets and tip-bots; however there are always opportunities to cleverly redesign such utilities so that they don't automatically generate new accounts (or otherwise minimize the penalty).

Here is a graph that shows penalty as inverse of initial account balance. The penalty would max out as the initial balance approached 1 raw and there would be no penalty above a certain "threshold" balance (e.g. 0.1 NANO). This theoretical penalty would only be applied to open transactions.

penalty-as-inverse-of-initial-balance

Note: the actual formula used for this graph is: penalty = (11 / (balance + 1)) - 1. The curve crosses the y-axis at a value of 10 (max penalty), and it crosses the x-axis at a value of 10 (balance threshold). These numbers were arbitrary: I just picked them to make the graph look curvy. It's a variant of the inverse function x = 1 / y.

In a PoW system I think the penalty would just be more work; but how much?

In the recent election scheduler and prioritization revamp that Colin has proposed, the penalty could be a time delay that pushes the open transaction to the rear of the LRU ordered queue(s). Perhaps max delay = 4 hours or 24 hours. The queues could be ordered by LRU + penalty.

In my most recent load balancer proposal the penalty could be a number added to "tx processed this week" during the sort.

What do you guys think?

I don't think you can just penalize open's as a spammer can just chain billions of accounts together starting with 0.11Nano in the first and opening successive accounts with the previous amount - 1raw leaving each account with only 1 raw in.

I think to avoid ledger bloat it would be best to align the cost of an account in the ledger with a financial cost. I think this means Minimum Account Balance (MAB).

  • MAB is defined in the protocol but can be changed over time with a release of a new version of the protocol
  • MAB should be set as the lower bound of human economic activity (so currently something like 0.0001 Nano)
  • A txn amount cannot be less than MAB (and therefore an open cannot be for less than MAB)
  • A send is not valid if the resulting balance is less than MAB
  • Every account opened, therefore, has a real-world cost that is equal to MAB - this is good as it aligns use of new accounts with the very real cost that is incurred in perpetuity for storing the account in the ledger
  • UX of wallets (e.g. send 1 nano to receive 1 nano) can be resolved by rounding to fewer decimal places than MAB is currently (e.g. wallets round to 2 decimal places)
  • A bonus is you can remove POW entirely from the network (assuming POS4QOS) which simplifies a lot
3 Likes

Thanks for sharing this @TiGz. It's very convincing. I have to agree that imposing a penalty just delays the inevitable: a spammer may have to wait 24 hours (or generate a bunch of PoW) for his or her million dust accounts, but they will eventually get created. The MAB idea prevents them from coming into existence at all.

I suppose the counter argument is that it completely eliminates certain use cases for the nano protocol (e.g. IOT and other micro transactions between accounts with tiny balances).

Question: along with MAB would you propose some sort of account-close transaction, or another mechanism to reclaim or donate the dust (by the holder of the private key)?

This is how XRP is doing it right now, you have to have min of 20 XRP (IIRC) in your address.

I do not like this idea. It prevents a lot of use cases that utilizes microtransactions (now and in the future). It will also lock up some nano that could be otherwise used to transact (no matter how small it is).

1 Like

Question: along with MAB would you propose
somee sort of account-close transaction, or
anotherr mechanism to reclaim or donate the dust
(by the holder of the private key)?

I did think about that but I think it creates more problems than it's worth.. mainly around reopens after closes and out of order processing on the nodes.

I'd argue that Nano should be solely focused on human transfer of value (otherwise it may well fail at that entirely) and should therefore not be targeting micro transactions. Having said that I don't see it being much different.. possibly one or 2 extra decimal places?

2 Likes

This is how I was thinking a time-delay penalty might be effective in combination with other factors:

  • In light of the current scenario, we should expect the pending transaction queue to remain saturated with spam, up to some configurable limit of transactions; if the prioritization logic is calibrated properly, legitimate transactions would get added near the front of the queue; as each new transaction was added, the lowest priority transaction would therefore be dropped off the back of the queue
  • Current thinking/development is that prioritization will be determined by some function of account balance and time since last use
  • Open-transactions would inherit the time since last use from the sending account, and I assume the balance would be based on the initial account balance
  • So if the penalty curve were calibrated properly, it might allow dust/micro accounts to be created, provided the sender was not trying to generate tons of them; for example, a new IOT device comes online and is detected by a control hub, which sends it some initial nano to perform its function; the control hub's time since last use is from 3 hours ago when it detected another new IOT device, etc.
  • However, if the sender was trying to create tons of dust accounts in rapid succession for spam purposes, the penalty would surely push these transactions to the very back of the queue and they would likely get dropped
  • With that said, the prioritization logic might handle this without needing a penalty, since the spammer would have a very small time since last use if attempting to create lots of new accounts; the penalty would however add pressure to drop the open transactions before dropping normal send/receive spam; if we're going to keep one over the other, IMO it would be better to keep the normal sends and receives over the opens, since the opens are harder to prune from the ledger

Another thought (maybe a dumb one): we could have both a penalty curve and a MAB; this might allow us to set the MAB lower than otherwise.