Some brainstorming below to generate discussion:
Goals
- Minimize hard-coded limits that require node/protocol updates over time
- Incentivize receives to make pruning easier
- Prioritize human-to-human transactions (occasional + real world value)
- Discourage "bad" behavior (hard to prune, ledger bloating, network saturation)
Ideas
Significantly increase PoW for open transactions
- Rationale: Typically happens infrequently; reduces ledger bloating; people understand opening accounts before using them (+harder to burn transactions on accident?)
- Risks: Exchanges/light wallets (but they could charge users for more accounts); Can still send to unopened accounts (see next idea)
Significantly increase PoW for sending to unopened accounts
- Rationale: Reduces bloating; Incentive to open accounts (easier to prune)
- Risks: Uneducated users vs exchanges/lightwallets? Less "privacy" due to incentivizing address reuse; people can still not receive transactions after the initial open
Significantly increase PoW for every order of magnitude less than "unano" (10^18)
- Rationale: Lowest GNI in the world is ~1/1000 of the US
- Humans don't transact in 1000ths of a cent; at 10 cents/Nano, .001 cents == .0001 nano; add another 3 orders of magnitude for lowest GNI country == .0000001 is lowest currently reasonable, add 4 more orders of magnitude for if Nano ever goes 10000x (10x current world GDP), aka .00000000001 becomes a good soft floor
- Risks: "True" microtransactions/message encoding
Increase send PoW based on number of unreceived transactions CREATED BY the sending address:
- Example: nano_a has sent 100 unreceived transactions == 2xPoW for next 100
- Rationale: Encourage receiving transactions for pruning; harder to spam
- Risks: Light wallets & exchanges that open accounts and send transactions for other people, BUT exchanges could check withdrawal addresses for pending receives first (and notify users to pocket their funds before they'll allow withdrawal); Light wallets have different sending addresses; Could also do a rolling window to account for light wallets/exchanges/sending to people that never receive?
- Requiring extra DB reads/calculations to determine PoW validity?
Increase send PoW based on number of pending receives TO destination address:
- Rationale: Encourage receives for pruning
- Risk: Spam DoSing legitimate users
Increase PoW costs for each order of magnitudes increase in sending volume vs a rolling window:
- Example: 100 vs 1000 vs 10000 transactions in an hour (increase PoW cost for each)
- Rationale: Really high orders of magnitudes almost always come from spammers
- Risks: Lightwallets and exchanges
Per-node whitelisting of known-good services for lower PoW/prioritization under load:
- Rationale: Differentiating between spam and high volume services; could potentially allow for increasing the base PoW without impacting good services as much (if enough PRs whitelist them)
- Risks: Potentially anti-competitive for new Nano businesses;
Limit pre-computing PoW (time-based nonce?):
- Rationale: Prevent mass accumulating and dumping blocks
- Risks: The Nano network has no sense of time
Types of spam to consider
- Opening new accounts - Storage risk
- Valid transactions (high or low value) in a loop (Epstein spam) - Network saturation risk + storage risk w/out pruning
- Sending and never receiving - Hard to prune (storage risk)
- Sending to unopened accounts - Hard to prune (storage risk)
Other thoughts
- All of the above increases would be multipliers vs whatever the baseline send PoW is
- There is a constant balance battle between legitimate services and spammers
- Full node operators are almost never affected since they do their own PoW
- If all services could enable client-side PoW, it would be a lot easier to prevent spam without impacting legitimate services
- If receives were auto-received (no signature required), pruning would be a lot easier
- Some of the above ideas are not intuitive; users would have to understand the protocol to understand why some sends/receives are harder than others