Spam Deterrent, PoW w/ Confirmation Height in lieu of Prev. Hash

If I understand the current PoW requirement, it involves hashing (among other things) the previous block hash. Is there a (major) downside to replacing the previous block hash with the previous (or expected) account confirmation height?

This would still make the PoW unique enough that it couldn't be used multiple times.

The potential upside I see is as a spam deterrent. Right now a potential spammer is able to pre-compute blocks (and thus the required PoW) for a near infinite number of future blocks. Their future account actions are intentionally mapped out. A good actor, in almost all situations, does not have this ability. I don't know how many times I'll use my credit card today, twice? 5 times? 3 times real quick then 1 an hour later?

What I do know for certain is I will use my credit card again (Nano already allows for me to preemptively generate my new PoW). What I'm fairly certain of is I'll use my card 2 to 3 times per day and thus likely 15 to 20 times per week. I could never predict the exact details of all these transactions (I.E. in nano speak, I could never predict future block hashes) but I do know they would be the 375th to 395th transactions on my account (I.E. in nano speak I can easily predict my next confirmation heights)

If I could pre-compute the PoW for my next "X" transactions ("X" being of my or my wallet providers choosing") then I could either (without much consequence) choose to compute higher difficulty PoW or utilize slower PoW engines (mobile, CPU, etc), an option I'd never have for back to back transactions during a spam attack/saturated network.

I have to think a spammer would see the challenges of competing against a network full of intermittent users, who by being intermittent users have plenty of time to compute PoW. I made a lengthy Reddit post yesterday about spam mitigation and how IMO PoW calculation time is at the heart of spam prevention. The above seems to me to be a very Tai Chi type defense for most Nano users, utilizing their natural strength, idle TIME.

In the thread on Work Generation changes for consideration there is mention of account height based PoW. As you mentioned it levels the playing field on pre-computing for average users compared to spammers, so could be worth looking into.

You'll notice one comment on that suggestion was around the impact this will have for generating forks. With the current setup a spammer who is attempting to attack with forks can get an unlimited number of forks from the same root with the first PoW generation, but then in order to have valid PoW for the next transaction, they must generate PoW for each of the initial fork blocks they created (since only one of the original ones will be win and be in the ledger). So this leads to an exponential increase in PoW needs for fork attacks.

With account height PoW the attacker can generated just once for each height and get an unlimited number of valid fork blocks from that single work value at each account height - there is no increase in work efforts to pull off this attack.

There may be ways to mitigate this issue by other means, but this is a key issue to consider when thinking about account height based PoW.

I now see the potential pitfall. A spammer creating chaos (network traffic) by instigating votes on multiple conflicting blocks per confirmation height would have an exponentially easier time keeping the attack going. I'll keep thinking on this but it seems the advantage given to the spammer outweighs the disadvantage removed from a good actor. Thanks!

1 Like

The more I think about this, the issue is likely handled best with a good wallet solution. Multiple accounts all computing varying degrees of PoW. Next transaction utilizes the minimum PoW necessary. A few high PoW accounts standing at the ready. Accounts re balance during times of low network traffic.