Another solution for spam prevention

The idea in short:
Allow principal representatives (or maybe all nodes) to become active participants in spam prevention.

There are numerous ways to achieve this; In this post, I will talk about one, but I might make another post with another solution.

Introduce a new balance called transaction balance

When your account does a transaction => transaction balance -= 1; To do a transaction, you need at least 1 in the transaction balance.

Creating a new account requires a transaction. The newly created account starts with a transaction balance of 0.

For an account to get a transaction balance, it needs to requests transactions from someone else. So it simply requests a node "Can I please have five transactions please?". The node could then freely decide if it wants to send a transaction balance or not. This decision could be based upon many different criteria; it is up to the node itself to determine its criteria.
The node could decide based on many variables like current transaction balance, current nano, spam history, trust, etc.
The node could also potentially whitelist accounts, like accounts created from a trusted wallet like Natrium or Nault.

If the node agrees, it can send some of its transaction balance to the account through a regular transaction (The same way nano is sent, -5 here +5 there)

How does the node get transactions on their transaction balance?

There are many different solutions here.

#1 What goes in goes out
When someone does a transaction, the account loses one transaction balance. The lost balance goes back to the node based on their voting weight. An additional number n might need to to deal with stale transaction balances. If n is high, the nodes could potentially burn some transaction balance (send it to a burn account) to keep is scarce

Example: a node holds 20% of the voting weight. The node confirms one transaction. The node transaction balance increases with 1 * 20% = 0.2. This number could then be timed with n = 1.01. giving us the final number 0.2*1.01 = 0.202.

Example:
Account loses 1 transaction balance, the sum of transaction balances of node increases by >= 1.

Problem:
It still requires a way to give out transactions initially

This is probably my favorite solution

#2 node gains transaction balance based on time
So a node might get a certain tps into their transaction balance based upon how much voting weight the node has. For example, Natriums transaction balance might increase with 1000 transactions per second.
This might require a transaction within a transaction balance to need an expiration date. This requires the network to know about time.

#3 NF controls transactions.
Since transaction balance does not have anything with consensus for nano, it could be centralized and given out to node in a centralized fashion.
This is probably the least attractive solution.

Node incentive
This could even be a way for nodes to earn money, as they could trade away transactions for a cost!

Spam policy
Essentially the node can make their own spam policy. If someone disagrees with their spam policy, they can change their vote weight to someone with an acceptable spam policy.

The Advantages:

  • A seamless experience for the end-user:
    If the wallet is low in transaction balance, it could seamlessly request, for example, its current node for more transaction balance. The wallet will always have some transaction balance when it needs to do a transaction (except if it spams)
  • Effective spam prevention
  • Potential money earning method for nodes, though most likely they will be competing with other nodes that are giving them out for free
  • Somewhat easy to implement? (dunno really)
  • Compared to DPoW it could drastically lower the amount of total spam transactions compared to prioritizing the transactions under saturation.

The Disadvantages:

  • It gives more responsibility to the nodes and their operators

Please note: I'm dumb

How would the nodes distinguish between honest use cases and spammers?

This is just me, but I think any new proposal on new spam mitigation should include why DPoW isn't sufficient and/or why the proposed solution is better.

2 Likes

The spam policy is up to the node. For example it could limit the amount of transactions, if any, it will give to an account if it has low amouts of nano.
Example:
Ok this account only has 0.00002 NANO, i will not give it transaction balance, please ask another node.
Ok this account has spammed a lot recently, you are not going to get more transaction balance from me right now.
Ok this account has spam created a lot of other accounts, i will not give you transaction balance.
Ok this account already has a lot of transaction balance, i will not give it more.
Ok this account has had low account volume but many transactions, i will not give transaction balance
If an account has a lot of nano, like an exchange, then the node could potentially give it more transaction balance. The node could also whitelist legitimate usage such as an exchange account address. But also most exchanges could run their own node and gain transaction balance from their node.
The node could also look at the current saturation of the network as a factor.

Normal usage is probably less than 10 transactions a day per account with the exception of exchanges and services, the nodes can easily allow this.

Maybe account creation could require a higher amount of transaction balance too? It could cost 100 transaction balance to create an account.

There is nothing wrong with DPoW and it could also be included here. Compared to DPoW it could drastically lower the amount of total spam transactions compared to just prioritizing the transactions under saturation.

You're making some assumptions on what scenarios are spam. I don't agree that you can correlate frequency, account balance, or new account creation with enough certainty to risk blocking honest users.

The more you limit odd but valid use cases the more you limit adoption. This would be a major risk and a problem with lots of other centrally planned spam mitigation ideas.

I do think you can be fairly certain that if someone produced a difficult PoW for a transaction then it is likely not spam.

It doesn't sound like you see a big problem with DPoW, so what is the advantage here? Just less ledger bloat?

3 Likes

You're making some assumptions on what scenarios are spam. I don't agree that you can correlate frequency, account balance, or new account creation with enough certainty to risk blocking honest users.

Dunno what else I can say other than that i disagree. If you're rejected from one node you could ask another node with less restrictions in their spam policy. However if they have a loose spam policy then they may run out of transaction balance, which will most likely happen if someone tries to spam. So spam-like transactions will have a hard time getting transaction balance (under saturation).

Then either the nodes have to do a lot of work to distinguish spammers from non-spammers, or sell transaction balance. That’s just a roundabout transaction fee.

1 Like

Then either the nodes have to do a lot of work to distinguish spammers from non-spammers

A potential solution to that is that someone could create a account/node with the sole purpose of handing out transaction balances (it does not confirm transactions). This way network resources is not used to deal with spam prevention. This node could then have its own spam policy.

PRs would then give out transaction balances to these accounts that hands out transaction balances. If that account becomes malicious then the PR could stop sending them transaction balances.

But yeah they could potentially take a fee for it. Thought in practice I don't think they will, and they will always be in competition with other nodes. Also you could change your vote weight away from nodes which sell of their transaction balance, if you want to.

Also welcome!