Minimum account balance to prevent ledger size spam

PoW and the likely future implementation of pruning are the main anti-spam measures adopted by the protocol to reduce the amount of network bandwidth and disk space occupied.

However, the most effective spam measure I believe is the one represented by opening accounts with very small amounts, as this practice is totally immune to the two measures mentioned above.

Could minimum account balance (MAB) be a solution to this problem? (Always assuming that it is perceived as such)

Example:

In conjunction with the release of a new epoch version (to mantains the MAB updated with the current protocol status, as for PoW):

  • a send tx for an account that doesn't exist on the blockchain yet need to have a min amount
  • (consequently a new account on the blockchain can't be created if its correlated send tx amount is lower than min amount)
  • an account can send a tx only if its balance - sending amount would be >= than min amount
  • accounts can be "closed" (sweeped) by their owner if balance - sending amount would be 0, accounts with 0 balance are somehow pruned by default

With a MAB of 0.01 NANO the max disk space occupied by a pruned ledger would be:
block size * (133M/0.01) = 266 byte * 13.3G = 3.53 TB
Yes, we are still far away from the current unpruned and unMABbed ledger size, but hey! =)

In a future scenario, where NANO could be worth of 10 USD/EUR, in order to be able to process txs something like 0.1 USD/EUR would be "blocked" until you decide to send everything to someone else or to an exchange.

This proposal would still allow mini/micro/nano txs, just would avoid the opening of accounts with very low and (from a practical point of view to transact) useless balances.

Have a good day

1 Like

Rather than forcing a MAB, what about requiring transactions to unopened accounts to have 10x PoW or something like that? And requiring account opens to have 5x PoW?

The problem I see with MABs is that a reasonable minimum is very hard to set. What's reasonable in one part of the world is completely unreasonable in another part of the world. It also makes micro-tipping (very popular usecase for Nano atm) and faucet services unfeasible

3 Likes

Well, require a PoW multiplier for such special cases seems a simpler solution.
I understand that having a MAB set to 0.1 USD could be unpopular due to some limitations.
I'm just guessing if could exist something different from PoW that could be used as spam limitation too.

1 Like

I didn't get the idea, but since Nano doesn't have a fee (so the "minimum amount" is not burned). You can still open many accounts using the same source. I mean, or can send 1 Nano to "Account A"; Then Account A makes a transaction to Account B; Then Account B to Account C; Then Account C to Account D... You still opening many accounts.

With a MAB of 0.01 NANO the max disk space occupied by a pruned ledger would be:
block size * (133M/0.01) = 266 byte * 13.3G = 3.53 TB

I think you don't need 266 bytes anyway. Far I'm aware of, at least my attempt to create a custom node, you just need to have: all pending information (which is the main problem, since is 64~81 bytes per block!). For each opened-account, you just need:

  • The version.
  • The account-public-key.
  • The balance.
  • The amount (calculated by the node).
  • The hash of the original block.
  • The representative.

So, it's 129 bytes per account, if I don't miss anything. Also, the amount/balance can use variable-length fields, so instead of "1 RAW" be 0x00....0001 (16 bytes), could be just 0x01 (1 byte) or 0x0101 (2 bytes, one is byte-length, the overhead). The second case will save space on account which has less than 1000000 nano, only. However, it might save space in general, at some minimum CPU cost.

accounts can be "closed" (swept) by their owner if balance - sending amount would be 0, accounts with 0 balance are somehow pruned by default

What will happen to the funds sent to that "closed account"? If I get the idea, the closed account can't do any more transaction. Did you need to create another Open (how to handle multiple opens then?)? Did you will lost your money (bad UX?)? Since "account can be closed" but not "must be closed", what I get from close my account?!

Also, you still need the information about the transaction anyway. If Account A sends something to Account B, how you will validate the chain without Account A? If that "closed account" only applies for "pruned nodes", I don't think that makes massive changes.

It's not on protocol-level, but the implementation. You do that already (since balance 0 can also ignore the representative). If you know that balance is 0, you can remove "the balance", "the amount", "the representative". So, it will be 65 bytes per "pseudo-closed-account", without network-changes and new hard forks. You might need another database (just for closed) or a one-byte flag to mark that account as "closed" (to the node perspective only; not the network). In the end is 1 byte vs 64 bytes, without network changes.