Burst Control, SPAM Filter & POW as Defence for Dust SPAM

To add to the conversation of Election scheduler and prioritization revamp I feel a separate topic on what can be done to avoid keeping the network at saturation at negligible costs would be good to have.

Some sort of account-level burst control is required or the network will be at saturation at all times, which is what Colin said, and it doesn't sound bad when the majority of network capacity will be real transactions, but right now, with 2-3 CPS being real, even with bandwidth limits, the remaining 80% will be dust, deprioritized, but still here.

Maybe we can use POW as a defense mechanism than a priority mechanism.

If (balance * time_since_use) < (Mean SPAM Number)

The difference with every moving decimal needs an exponentially scaling POW to validate the transaction or it is dropped immediately.

Spam Number could be a parameter each node operator can declare, It is manual, but a decentralized way to defend from dust txns.

Also, time_since_use minimum is declared as 5 seconds for further burst control. This cooldown to validate a send will not affect any human user or large-scale services imo.

There should be an upper limit to how much the PRs can set the spam number to so that the bad actor cannot disguise as PR and raise the network minimum acceptable transaction. For simplicity let us assume this number comes to 0.0001 (b= 0.00002, t= 5) as the max setting allowed.

Example: The mean spam number of PRs is 0.00001, with every moving decimal to this, the dust spam needs POW^(10)^X+1, with X=0, 1, 2 ...

Since (balance * time_since_use) adjusts in value and combined with burst control in place the hopping attack vector where dust is left behind can also be mitigated, but finding this number can get complex for a manual slider. If burst cooldown for 5 is approved, t= 5 will be constant and that would make it easy for a consensus.

With Equihash in place, we don't have to worry about POW being easy as well.

2 Likes

I really think that the most elegant solution removes proof of work entirely. A Minimum Account Balance of (say) 0.0001 Nano (changeable in the future with a protocol version increment) would put a real financial cost on holding 1000's of accounts and combined with POS4QOS with LRU ordering (or TaaC) completely solves both spam and ledger bloat.

I'm not sure I fully understand the arguments against a Minimum Account Balance. I don't want the limited resources of the network used for micro-transactions and if wallets just round what they show to humans to 2 decimal places then I think that solves any UX concerns. Are there any good arguments against a semi-flexible MAB?

2 Likes

Price being highly volatile, this is a very difficult decision to make and goes against the philosophy/principles of NANO.

A simple spam filter that nodes can agree on is a solution that no one should have a problem with imo and such changes should be dynamic as one cannot wait for software updates to enforce changes.

Price being highly volatile, this is a very difficult decision to make and goes against the philosophy/principles of NANO.

Price isn't volatile by multiple orders of magnitude every month/year though. And if/when Nano goes mainstream and jumps (say) 30x in price then it would be easy to rev the protocol and reduce the MAB limit accordingly.

A simple spam filter that nodes can agree on is a solution that no one should have a problem with imo and such changes should be dynamic as one cannot wait for software updates to enforce changes.

Not sure there is a simpler solution to spam than MAB and the various ideas in the POS Tiers thread etc don't seem simple to me.

Does MAB go against the philosophy of Nano? How so? I thought Nano's vision was to be the best value transfer system possible?

MAB seems like great idea for right now and I agree its an elegant solution. My main worry is down the road it will become a huge point of contention when it needs to be updated. Rich accounts will want a higher MAB for security and poor accounts will want a low MAB for better utility. Decentralized decision making is not a fast/easy process in a big network with lots of vested interest (ex Bitcoin block size).

Its why I like the idea of POW for opening accounts. Its an indirect cost that can be abstracted away from the end user. Because of that abstraction I think it will be easier to update in the future.

I know an open POW will require some service changes for tip bots and maybe exchanges but I think the long term benefit is worth it.

1 Like

I agree with PoW to open wallets, but I think they payment-id problem is worked around by services using random wallet addresses to track orders. I think a pragmatic solution is to allow the payment-id in the payload and add PoW to opening wallets as you suggested, but the payment-id problem is a pre-requisite to this regardless (unless I've misunderstood something).

Yea the payment-id problem is related but not a deal breaker IMO. Currently every service is already providing a small POW for each transaction. It can't be that bad to ask them to provide a higher POW for open blocks only moving forward.

Plus services could further avoid the open POW cost by:

A.) Not using new accounts for payment-ids. Colin/NF have already solved this by suggesting new api wallet protocols that don't require state block changes. At first I wanted a payment-id field in the state block as well but now I agree the temptation for abuse is too great. One of Nanos greatest strengths is doing one thing well - using all its resources/bandwidth/TPS purely for value transfer.

B.) Letting users do the POW client side. Once POW is no longer needed for prioritization an entirely new hash function could be used -one that runs easily on a phone or browser.