Ledger Spam Prevention. CPS POW multiplier on new and zero balance accounts

Hello all,

Currently a spammer adds ledger bloat by opening many new accounts.
More POW difficulty should be required on sending to a zero balance or new account.

Most users will be understanding of an activation wait time for opening an inactive zero balance or new account.

Assuming its possible, the POW required to open an account should take into account the current estimated CPS: (Current network POW difficulty) + (Estimated current CPS ^ 2)
Nodes will check its current CPS to verify it falls within an acceptable range of the POW difficulty.
These transactions will then be placed at the bottom of the queue as regular transactions have priority over newly opened accounts.


  1. Still instant transactions for people with an existing balance, as network prioritizes existing accounts
  2. As CPS of the network increases, it exponentially gets harder and costlier for the spammer to open hundreds of accounts.
  3. Ledger spam is reduced as the spammer is incentivized to spam using accounts with an existing balance (As existing accounts would be able to be pruned in comparison to new account)

Criticism or suggestions welcome as always.

The first thing that comes to mind is this can cause a priority inversion where some validators see transactions as high priority and others see it as low and if the transaction processing queue is sufficiently large it would deadlock.

I don't think the spammer cares for where that 1 raw ends up, so he can just pick any existing open account and spam this one. That would be very annoying for the account holder. If the account holder receives the funds, the blocks will be prunable, but that's very unlikely since the spam value is so low.

You are correct. Spammers always have the option to spam existing accounts.

I would agree in regards to the blocks being prunable should a spammer add transactions to an existing balance. Although that is the end goal of this post, is it not? (To stop ledger bloat. Not stop CPS spam).

The blocks will only be prunable when they are received not when they are pending.

@clemahieu I can only see a deadlock occurring if the spammer overloads the nodes with a CPS spam attack (Which is a separate problem NANO still needs to resolve?). Although this post is about stopping ledger spam. The amount of confirmations should be the same, as the end goal is to make ledger bloat exponentially cost prohibitive as opposed to CPS preventive.

@Ricki You make a good point that I was not aware of. Would an idea be to increase the sender's POW exponentially for each transaction that's unreceived on the receiver's end? The receiver would be able to do normal POW difficulties to outweigh the incoming difficulty. Eventually dormant accounts which never do the POW to receive would build up a natural defense against spammers over time?

It's not about the CPS it's about TPS, the transactions that don't fit in the current CPS window. When modeling these things you need to assume an infinite number of transactions are being proposed and the network hardware limits it to some actual CPS number. If all the items in the CPS window suffer from a priority inversion, it would deadlock. Regardless of what the actual CPS number is, it's a finite number.

These things can't be considered in isolation, if the proposal has a possibility of deadlock, it's not a viable solution.

If you can improve the idea so it doesn't deadlock then it would be a possibility.

Thank you for clarifying. I guess we'll let this forum post serve as a way for other's to build onto the suggestion, should they find a method that would prevent the deadlock.

1 Like

Incidentally, this is also why fees wouldn't solve the issue because that same priority inversion would exist. PoW difficulty is malleable so it's possible a 3rd party could bump the priority to resolve the deadlock but fees are signed in to the block and can't be changed.

It never crossed my mind that 3rd parties could bump anybody's transaction PoW difficulty, I thought only the originator could. But that totally makes sense as that's how distributed DPoW basically works.

Has this ever happened in practice (either by 1st party or 3rd party) or has the network never been saturated enough for the need to attach higher difficulty PoW?