Possible Idea for Addressing the SPAM Problem

A question/idea about protocol / addressing spam: Would it be feasible to limit the amount of wallet transactions in a unit of time to a multiplier that reflects the amount of nanos held in the wallet?

E.g.:
Example 1:
Time window: 24 hours.
Multiplier: 1.
=>
A wallet with 1 nano can perform 1 transaction every 24 hours.

Example 2:
Time window: 24 hours.
Multiplier: 100.
=>
A wallet with 1 nano can perform 100 transactions every 24 hours.

Example 3:
Time window: 20 seconds.
Multiplier: 1000.
=>
A wallet with 1 nano can perform 1000 transactions every 20 seconds.

The network could vote on the Time window / Multiplier parameters according to difficulty and other criteria.

Any answer is really appreciated.

Hi mcas,

Limiting the throughput per time interval of individual wallets does not limit spam.
Most spammers use thousands of wallets and send a tiny amount from each of them. The network just sees thousands of individual accounts sending a tiny amount. All the blocks are valid, and they could be from legit users or spammers.

You can use the transacted amount to limit spam somewhat though. If pow requirement for smaller amounts were higher that would make it harder for the spammer. The spammer would either need to create higher pow, or buy more Nano to transact. If he chooses the last option he would also be incentivized to receive the transaction and that would make the block prunable.

Thank you @Ricki for your answer. You mention that "Most spammers use thousands of wallets and send a tiny amount from each of them". With a "Multiplier" of 1, and a "Time Window" of 24 hours this would not be possible, since only wallets with at least 1 Nano would be able to perform 1 transaction every 24 hours. By modulating "Multiplier" and "Time Window" parameters dynamically, the network could reach homeostasis, progressively barring wallets with lower balances from transacting in situations of high load/spam. The result would be that under attack, the network would be progressively made non accessible to low balance wallets, only for inclusivity to be extended then again to lower balance wallets in situation of lower load.

This sounds very similar to the ideas being discussed here.