Suggestion: Technique to Mitigate Malicious Actor Ledger Bloat

[OriginalTaco]

My suggestion is focused around mitigation or prevention of a malicious actor using micro-transactions to create massive ledger bloat that can not be pruned.

The attack is simple: An entity generates millions/billions/trillions of send transactions, each containing 1 raw, and each directed to a different randomly generated address. This results in an equal number of unpocketed micro-transactions, eternally waiting in the ledger.

My solution is two-part:

1. Significantly increase the amount of PoW required to generate an Open block.
2. Implement a check for address validity, with transactions sent to addresses not having an open block published being rejected.

This solution effectively eliminates the aforementioned attack. By requiring all transactions to only be sent to previously opened addresses, it prevents the "quick and dirty" method of sending to rapidly generated random addresses.

There is a second benefit to this solution as well - it helps prevent misdirected funds. It acts as a check against mistype addresses, etc.

I don't know how computationally expensive it would be to have a node check that the destination address is valid for each transaction. I understand this may add processing time for each tx. The cost/benefit analysis will have to be performed by someone more capable than myself.

Thank you.

[renesq]

Side note: Even without an open block, attacks might be possible if epoch blocks will need the be used again in the future. Epoch blocks put 10830 unopened accounts (half of them being burn accounts) into the ledger.

[OriginalTaco]

Side note: Even without an open block, attacks might be possible if epoch blocks will need the be used again in the future. Epoch blocks put 10830 unopened accounts (half of them being burn accounts) into the ledger.

The down side of my proposal is it would kill the creation of new "air-gapped" cold wallets. Which potentially could be some of the unopened accounts you mentioned above.

[Javdu10]

Why can’t we have a limit for unpocketted transactions aswell ? Passed this limit all blocks towards this particular account are discarded

[Jamsie100]

What about increasing the pow required if sending to addresses with no open block instead of rejecting?

[OriginalTaco]

Because if there's no cost to opening accounts, you could simply publish a cheap opening block, quickly followed by a microtransaction to that address. Now you have millions/billions of accounts with microbalances that can't be pruned. Same problem, different path.

[IvanAnishchuk]

Sorry, I'm probably missing something here, but how would we open new accounts without sending funds to them? Possibly I didn't follow latest protocol changes or something but I was under the impression the opening block has to be a receive transaction which implies sending something to be received...

[Javdu10]

@IvanAnishchuk it’s the way it work as of now but it can be changed, if you authorize for the first block of an account chain previous as null and the resulting balance is set to 0, you’re good to go, no more dust to random account but only to account that have been opened and can be pruned, I don’t really do math, but if your rep can after a period of time sign all the pending in one pending, it would be really efficient

[IvanAnishchuk]

So, in addition to forbidding sends to unopened accounts you also want to start opening account with empty receive blocks (null link, zero balance). Wouldn't a spammer just as easily open a bunch of empty accounts? It seems to me it would be even easier to perform: no need to spend any funds whatsoever. Even hardened PoW for a bunch of empty accounts would be trivial to pre-calculate. Also, unlike penny-spend attack this kind of spam would be harder to detect (no central source of funds required).

Of course, we can start pruning empty accounts, but ideally we at least want to remember the last block which in this case would be the only block. And if we prune just-opened accounts completely it would harm usability (user opened an account and clicked some buttons, user comes back in a week and suddenly he has to reopen -- if I were the user I'd be annoyed). There might be other options, of course, but it definitely needs some thinking over.

Like, some other half-measure might be easier and better e.g. pruning unpocketed transactions beyond some value after some time. There will be a bunch of unpocketed sends after the networks runs a while for many reasons, dealing with it is a big separate issue but I think solving it a cost of allowing empty account opening blocks is not the most balanced approach. Don't quote me on this though, I'm fairly new to Nano and might not understand some finer details.

[IvanAnishchuk]

A random idea just popped to my head: what if instead we required an empty send AND an empty receive to open an account, with receive requiring extra PoW? Effectively, every account will need to be "vouched for" by another non-empty account. Doesn't really solve the problem of account opening spam and also would affect privacy significantly, not sure if I'd want it for Nano, but it sounded like a nicer version of OP proposal.

[qwahzi]

What does the empty receive buy us? As is, open blocks already require a receive, no?

To me, the best option sounds like requiring all new accounts to publish an open block (with significant PoW requirements) before receives are allowed. That would force ledger-bloat spammers to compute PoW for their sends AND the new accounts they want to use to bloat the ledger.

I'm not sure what kind of side effects the above suggestion could have though. The only thing I can think of right now is that it would effectively make burning Nano impossible, which actually might be a good idea for the average user (no more accidentally sending Nano into the ether).

EDIT:

Another potential downside would be new account generation for light wallets (and possibly exchanges). They'd probably have to outsource the PoW and/or create account limits per user.

[OriginalTaco]

What does the empty receive buy us? As is, open blocks already require a receive, no?

To me, the best option sounds like requiring all new accounts to publish an open block (with significant PoW requirements) before receives are allowed. That would force ledger-bloat spammers to compute PoW for their sends AND the new accounts they want to use to bloat the ledger.

I'm not sure what kind of side effects the above suggestion could have though. The only thing I can think of right now is that it would effectively make burning Nano impossible, which actually might be a good idea for the average user (no more accidentally sending Nano into the ether).

EDIT:

Another potential downside would be new account generation for light wallets (and possibly exchanges). They'd probably have to outsource the PoW and/or create account limits per user.

Rejecting transactions sent to unopened addresses has two significant downsides I can think of -
a) the death of true cold wallets, where someone sends funds to an account they have generated the private keys for offline.
b) as you mentioned above, businesses that require a large number of unique account numbers would have an increased cost. However, nothing would stop them from "stockpiling" accounts, for future use. (Keep 100, or whatever, in reserve for spikes in demand)

[qwahzi]

I'm less concerned with issue b since businesses can offload PoW to users (or to PoW services) and/or charge for costs as necessary, but the loss of true cold wallets is a good point that I don't fully understand the implications of. My one thought on why it might not matter is because the primary goal of Nano is to facilitate secure value transfer in the most efficient way possible. The lack of cold storage doesn't meaningfully impact that afaik.

Another issue would be handling all of the current pending transactions to unopened accounts.

That being said, it might still be worth the tradeoff if it fits Nano's "peer-to-peer first" ethos, drastically reduces ledger bloat potential, and improves UX (can't accidentally burn coins anymore).

[OriginalTaco]

My thoughts for pruning get a bit more complex and "less viable" on the topic of pending transactions and empty accounts.

Essentially, I think the network should actively look to make itself more compact and efficient.

In my perfect world, Nano would do this:

On a regular basis, take a snapshot of the network, go in and create new frontier blocks for all accounts, including pending transactions. So, if there is 15 pending transactions to an account with a cumulative value of 1.4 Nano, those 15 blocks become consolidated to one pending block on the network. Alternatively, make it so that receive blocks can be generated by the network without the private key, and funds are automatically allocated to accounts so that pruning can occur.

Transactions would not be permitted to unopened accounts, and it would take substantial effort to open an account.

When an account removes all funds, it would become pruneable. In effect, a "close" block, allowing empty accounts to be removed from the ledger. (I understand this could potentially create issues with the idea of no transactions to unopened accounts.)