Remove proof of work difficulty/requirement check

[SparK-Cruz]

Clients don't use work difficulty to prioritize transactions anymore and they fight spam by using bounded distributed balance buckets of blocks prioritized by least recent use, bounded block backlogs, and checks for prev block to be at least queued in a bucket.
Those techniques can delay a spammer way more than the PoW difficulty check which is mostly calculated by a third party volunteer network (DPoW).

Having the PoW requirement adds complexity to integrations but doesn't make spamming the network any harder as spammers calculate work and hold to publish all blocks at once, and that our bounded lists, prev check, and prioritization can take care of much better than a PoW difficulty check can.

Without PoW could have the users that keep the DPoW network today allocate their resources for personal projects to further develop the ecosystem.
We could have lightnodes powering mobile wallets without the need for a centralized back-end server because of app stores' restrictions on hash rate.
We could have easier integrations on client-side software with less potent hardware.

The sky is the limit.

We could get offline signed blocks and publish them directly without modifying the payload to include a work we should have pre-calculated but don't so it takes 30 seconds to send instead of 0.3.
We could embed a lightnode in tamagotchy-like stand-alone hardware wallets so even people without a phone could use Nano.

[kopeboy]

I imagine there are drawbacks too? For example, I had this doubt, that I'm not sure was addressed (about what ghostbanned calls the "casual spammer", that is still deterred by PoW). If my understanding is right, PoW is not used to prioritize transactions but to validate them, and so requiring its calculation basically spreads what would otherwise be bursts of transactions by custodians (a common example of a potential casual spammer that is not impacted by the new buckets system) such that the delay for any particular user trying to transact at the same time is minimized.

This may not be a concrete benefit now that the network has spare capacity, but may severely impact the "instant transactions" brand & user experience exactly when adoption surges. It would be nice to test how the network can evolve without PoW, if we can keep it compatible with its quick re-introduction if/when needed.

I haven't operated a nano node, business or app yet, so you could be right that the costs (direct & indirect) outweigh the benefits at this point, or that my example is not found in practice, but I would like to see some numbers to justify the removal of a feature that seems at the core of Nano: to protect all normal users from unfair usage by bigger, profit-driven ones (even if not malicious). What do you think? Are my numbers and considerations in the following Discord message too, reasonable?

You may want to use this tool to calculate how little/much would cost to delay regular users' transactions: https://github.com/dylan1951/nano-spam-calculator

[SparK-Cruz]

I do not have the exact numbers to say the pre-validation on prev block being in a bucket slows down the spammer more than PoW. But one thing is for sure: with PoW being fixed and not dynamic, or being dynamic but only if the block belongs to an account you're already creating blocks for, it does an awful job at stopping spammers as we observed in 2021.
If we want to add a fixed minimum interval of time between blocks of the same account we could do that comparing local times and disabling the check on bootstrap mode (for obvious reasons) and that would be more effective than PoW is as of now.