jmmcgee
commented
5 years ago [II.D]
What'd really be useful is a way to unscrew the ledger once it's already been screwed. The idea that pruning allows the network to "forget" spam attacks, by making their effects transient is really nice. It'd be good to find a way to extend that to pending blocks.
pending blocks timeout
- One simple way to deal with unchecked growth of pending blocks is to set a timeout after which unreceived pending blocks are dropped.
- Watchtowers could be employed to store pending blocks and their confirming votes such that when a node comes online to receive unpocketed sends, the watchtower rebroadcasts the dropped pending block and its vote-stapled votes followed by the signatory broadcasting receives. These could be either payed or not, with possibly configured max storage size, storage feerate, account-based filters.
- Watchtowers might be feasible without adding any sort of fee if people are willing to trust best-effort honesty/storage rather than explicit guarantees.
combine pending blocks
- Another idea is to combine pending blocks to compress the burden. I think ideally there would still be a way to phase them out of the ledger to lock down bloat. But maybe the problem becomes tractable if they can be somehow compressed so that the storage reqs grow with log(unpocketed blocks).
- Maybe pending blocks are grouped into an intermediate block, according to sending or receiving account, which somehow behaves as a certificate of the actual blocks compressing the storage. I haven't figured out a way to do this but could imagine the sort of direction to think in. Inspiration would be merkele-trees, schnorr signatures, and something like MAST. Though afaik Schnorr only really works for signatures.
- @pedfx seems to have some sort of scheme in mind for compressing blocks here but I don't really understand the dynamics of what he has in mind.
Discussions on the Nano #protocol discord (which I don't know how to link to) have led me to believe that it would be useful to have a way to deal with ledger bloat attacks. (This post is an overview. Next comment contains ideas.)
It seems like pruning should decisively mitigate the potential for ledger bloat. But it's not ovious that this is the case. All blocks that can be referenced can't be pruned -> ~2 blocks/account and all pending blocks must be kept.
Ideas for mitigation:
This issue is focused on ways to deal with ledger bloat once it has occurs, taking for granted that whatever scheme that is deployed may inadequate to entirely prevent it. Before I read (#1064, #1150) I wasn't particularly confident in the ability of PoW to ultimately protect from this type of attack. But if mitigations which take sending account size and money velocity are added, it might begin to be feasible. But I still think over time it's inevitable that parties dedicated to undermine the network will find ways to slip by whatever filters are introduced since it is the purpose of Nano to facilitate frictionless transfers of value.
[I.A] PoW rate-limiting
I don't really see how any form of rate-limiting through PoW really deals with network bloat. Maybe the marginal increase in network bloat is increased, possibly also increasing the cost efficiency of the attack but not nearly enough to be a sufficient deterrence of malevolent parties.
[I.B.], [II.B.] Value Thresholds
Value thresholds don't really seem to help. It doesn't seem difficult that a person running a node can classify accounts as spam and prune them as they like--if they hold dust or satsify other heuristics. Most wallets seem to not pocket txs < 10^24 raw. But there is no protocol level restriction on sending those txs. This is useful as far as protecting individual wallets from spam. But it doesn't seem to help with bloat that any value txs can be approved. Once dust is added to the ledger as an unreceived send (esp if its malicious) it seems impossible to ever remove--currently.
[I.C] non-PoW spam filters
I can't comment on the technical details of #1064 but it seems to be focused on spam mitigation rather than ledger bloat.
[II.A] ledger pruning
Ledger pruning is good. But doesn't help with either preventing or undoing pending send spam-bloat since unreceived sends can't be pruned. What'd really be useful is a way to unscrew the ledger once it's already been screwed. The idea that pruning allows the network to "forget" spam attacks, by making their effects transient is really nice. It'd be good to find a way to extend that to pending blocks.
[II.B] value-based account pruning/forgetting
It seems like this might be possible, but it might also lead to undesirable outcomes in terms of nodes having divergent views of the network unless they use the same heuristics. Either way this is dealing with accounts and not pending txs.
[II.C] receive confirmed pending sends
A scheme for this is proposed in #1150. I'm mulling over a scheme myself. But I do like the simple proposal of allowing a rep to add blocks to the account of its delegators. One could have a single bit signaling auto-recv vs manual-recv to allow users to opt-out of this behavior. I think allowing auto-recv would be a safe default.
If this is implemented with auto-recv as a default it doesn't seem too bad. Maybe ledger bloat is sufficiently mitigated since pending blocks can then be rather aggressively confirmed in general, allowing the vast majority of the steady state to be prunable. But if accounts default to non-auto-recv then the problem is open since a spam-bloat attack would focus on sending to un-opened accounts which would presumably never open their accounts even to opt-in because nobody owns the private key.