Suggested Technique to Mitigate Spam

[OriginalTaco]

Hello.

I am a Nano enthusiast, and enjoy game theory and strategy.

I am not a programmer. I have written "Hello World", and that's about it. This is important, because from time to time, I may use incorrect terminology. If something doesn't make sense here, please reach out to me on the discord as "Isophix", and I will attempt to clarify.

I have been intrigued by the spam mitigation issue of Nano for some time, and I think it comes down to opportunity cost - the goal is to make spam attempts pointless by allowing legitimate transactions to dynamically gain priority over pre-computed PoW spam transactions.

I think this can be accomplished by: a) nodes actively assigning transactions a priority value b) and doing so only under spam conditions.

First, priority value is determined by the nodes using variables contained within each transaction.

Each of these variables should be based on a factor that has an inherent cost, whether monetary, time, energy. I currently have identified three candidates for these variables:

1. Dynamic PoW - this variable should be adjustable by the party creating the block. This variable has a cost of time and energy. The default PoW variable value is 1, with no PoW generated. When PoW is elected to be attached to a transaction, the difficulty of the PoW determines the PoW value. (Yes, this means that under normal conditions, transactions require no PoW!)
2. Transaction Value - this variable is self-explanatory. Much like the dPoS system that drives consensus within the Nano network, sending a larger transaction means you have more financial investment in the transaction, and therefore less likely to be spam.
3. Account Balance - this variable is self-explanatory. This variable again touches on the theory behind dPoS consensus, in that the more Nano currency you currently own, the less likely you are to be motivated to spam the network.

With regard to priority value, the calculation is simple - *(PoW difficulty) (transaction value + account balance)**. Transactions with a higher priority value are sorted to the front of the queue.

Secondly, there should be an implementation of a conditions check in the node software. Under normal conditions, nodes operate on the current FIFO model. During spam conditions, nodes sort and prioritize transactions based on the priority value. Each node does a status check on a predetermined regularity, to see if spam conditions are met. (Initial concept of this condition would be that if the number of txs in the buffer exceeds X, spam conditions exist. A different condition may be a better trigger - this would be where programming knowledge comes into play.)

I understand that the following are potential issues with this concept:

1. Implementation of dynamic PoW: Nodes would have to be able to assess the PoW difficulty value assigned to each block. I have no idea if they are capable of doing so already, and if not, how difficult of an implementation that would be.
2. Increased load on node hardware with the status check, and increased processing time per transaction under spam conditions: If the priority value sorting were to be an "always-on" part of the node, adding that check would always increase the load on the node, and decrease overall efficiency. That is why assert that an adjustment is necessary wherein the nodes become more "self-aware", and priority value sorting only activates under spam conditions.
3. Orphaned transactions: If a node is in normal conditions, operating on FIFO, and a legitimate transaction enters the buffer shortly after a large number of spam transactions with PoW attached enter, that legitimate transaction could become orphaned. This can be prevented by having the node first clear all transactions in the buffer that entered under FIFO, and use priority sorting only for transactions entering the buffer after spam conditions were activated.

Game Theory

The core of this spam mitigation technique is highly aligned with the Nano consensus model: The more value invested into each transaction, the less likely that transaction is to be spam.

A malicious actor has the goal of decreasing the cost of each transaction, allowing a greater number of transactions to be conducted within a given time frame. The greater the number of transactions this entity can generate, the greater the likelihood of creating a negative impact on the network. However, if the transactions generated have no effective impact on the network, then the malicious actor has no incentive to continue to generate them.

By allowing the PoW to be variable in each transaction, entities looking to generate legitimate low monetary value transactions during spam network conditions can still do so, either by having a larger balance, taking more time to generate PoW, or some combination of the two.

Additional tools can be created by the community to monitor the current priority values being processed by nodes, much like how https://ethgasstation.info/ monitors the current "gas" values of transactions being processed by the ETH network.

Wallets can be modified to query these tools, and generate sufficient PoW for a timely transaction, based on the transaction value and the sending account balance.

This mitigation technique is effective against pre-computed PoW attacks, because such attacks have two inherent qualities - their values are already determined at the time they are generated (static), and they are limited by the variables of time, size, and quantity. The priority values of these static pre-computed transactions quickly become known as the large quantity of transactions enter the network, and other legitimate parties simply update their priority values to gain precedence over the spam transactions. Once the nodes have cleared the spam transactions, the network returns to a normal state, and legitimate parties can then lower their PoW difficulty values back to 1 (no PoW).

[brunoerg]

I really liked your suggestion.

However, I think we can improve your equation:

(PoW difficulty) * (transaction value + account balance)

because, how would the difficulty be calculated? Would it be a value from 1 to how much? The way you formulated this equation I believe that part of it can become insignificant depending on the values.

Maybe we could add constants to balance the parts of equation.

(Kp * PoW difficulty) * [(Kt * transaction value) + (Kb * account balance)]

Where, Kp, Kt and Kb are constants.

[OriginalTaco]

I really liked your suggestion.

However, I think we can improve your equation:

(PoW difficulty) * (transaction value + account balance)

because, how would the difficulty be calculated? Would it be a value from 1 to how much? The way you formulated this equation I believe that part of it can become insignificant depending on the values.

Maybe we could add constants to balance the parts of equation.

(Kp * PoW difficulty) * [(Kt * transaction value) + (Kb * account balance)]

Where, Kp, Kt and Kb are constants.

There's an old saying: "If it looks like a duck, if it quacks like a duck - it's most likely a duck."

I think we have to acknowledge the reality that, in unusual circumstances, not all transactions are created equal.

One of the key tenants of Nano is that we want micro-transactions to be processed quickly, with no monetary costs. And in most circumstances, we do just that - we process transactions on a first come, first serve basis, regardless of the size of the account sending or receiving the transaction, or the size of the transaction itself.

However, those who send micro-transactions from small balance accounts have to accept that during the unusual circumstance of a spam attack, they "look like a duck". Because we choose to not differentiate between transactions at all other times, we must take extraordinary steps during extraordinary events.

If you want to send micro-transactions from small balance accounts during a spam attack, you must prove that your specific transaction isn't a duck. You can do this by generating a unusually large PoW and attach it to your transaction. You are stating: "Look, I am not a duck. I am willing to do this to prove I am not part of the problem you are facing right now. Please allow me to pass with priority, over all the other similar transactions that are part of the problem."

As to your comment: The formula is design to do specifically that - make small transactions from small balance accounts insignificant, since that is the cheapest way to spam the network. The 10,000 transactions per second with the value of .00001 sent from accounts with .001 Nano with a PoW value of 10? We want those transactions to fall to the lower priority.

If you need to send a legitimate .00001 Nano transaction from an account with .001, then you just attach a PoW with a value of 12. You make your transaction stand taller than the 10,000 ducks, so we know it's a goose. And your goose then moves to the front of the line, completes, and renders the goal of the 10,000 ducks pointless.

Nano's entire consensus method is based on the premise that the more invested you are in Nano, the less incentive you have to damage the value of Nano. I think that can be applied to use of the network, as well - the more you own and transact of Nano, the less likely your transaction is to be spam. Hence, larger balances and larger transactions need less PoW, since they are less likely to be a duck.

I don't think that adding a constant really changes the weight of those factors. A balance of 100 Nano is literally 10x more invested in the network than a balance of 10. A spammer with a balance of 10 Nano literally takes 10x the loss in value as someone holding 1 Nano. Are you willing to lose 50% of 10 Nano to cause a loss of 50% of 1 Nano? Why? Why not simply sell your 10 Nano at full price?

Secondly, your spam of .00001 Nano from your 10 Nano account is easily overridden by 100 Nano account sending 1 Nano, since my PoW is multiplied by 101, where your PoW is multiplied by 10.00001 - every one of my transactions are already 10x more priority than your. If you apply a difficulty value of 100 to your transactions, I can just apply a 10 value PoW to mine, and still take priority from you.

[brunoerg]

My fear was that this equation would not be effective against large-balance accounts. A spammer could hoard Nano in 2 accounts to have a better attack. Making transactions between these 2 accounts. Like a "ping-pong".

For example, if someone is sending 0.0001 Nano from an 10000 Nano account without PoW (PoW=1), this person would have a huge advantage than someone that is sending 10 Nano from an 100 Nano account using a high PoW (5).

[skynxt]

Spam and Centralization of PoW can be avoided when client wallets pre-compute PoW in system idle time to enhance network security:

Node alone cannot mitigate spam transactions. When spam/transactions increases/decreases in network, dynamically adjust difficulty of PoW by all nodes, only transactions with PoW that hold higher threshold of difficulty should be included in blocks when spam/transactions increases. Client wallets [eg Android, iOS, Linux, Windows etc] should use system idle time to pre-compute PoW to send/receive Nano based on the difficulty of network. For example in case of mobile client, Hypothetically assuming 30-50% time system is idle, upto an hour of system idle time in the mobile client wallet can be used to pre-compute Pow for single transaction, this way upto 24 transactions can be sent in a day by an mobile client. For usability sake clients can show how many transactions can be made with-in next hour based on ready pre-computed PoW, clients may buy pre-computed PoW from distributed PoW service provider for a small fee in Nano. Since, PoW requires mainly CPU processing power in mobile platform battery drain should not be a major concern. Related issues #196 #1336