If abuse is an issue, why not hash the IP with a nonce?
Only benefit I can think of is you can forget the nonce and now the data is securely useless, if the nonce was secure, but that doesn't seem that useful really.
Or for audit purposes (e.g. you might need to prove to some regulator no outside access was made, which is stupid but ...)
If you don't know the nonce, you can't match against other users-- so not useful for abuse.
But I'm skeptical re: abuse uses. For commenters, sure-- you may need to store IPs to combat abuse. But for readers? At most you would need sampled data or in-memory counters (e.g. to catch high volume bots).
Unfortunately, there really isn't any penalty for failing to minimize private data collection.
Also, by removing unlikely candidates (IPs owned by irrelevant entities or that are not US based) you could get the search range much much smaller, and with the FBIs budget you could probably compute it all in a few days even with a 1-second hash time.
Its imperfect, but you'd expect definitely good folks to look a certain way
You d have a triple virtuous effect: people would stop being such insuferable asses once they understand basically their name is on the comment, readers would be completely safe because why not and abusers would be logged still.
It's even probably what most websites do: it news to me to keep the IP of every visitor, I'd have pruned them.
Plus the FBI could probably narrow their search to a few hundred thousand addresses (relevant ISPs, no unroutable/multicast/etc), then only use the list to confirm.
Finally, if it takes 120 years on one core, it'll take 1.4 months on 1000 cores. I'm willing to be the FBI has access to more computing power than I do. ~100 CPU years isn't a particularly daunting amount of computing work, even for fairly low stakes research.
That search would also decode all addresses in the logs, not just one targeted one...
Assuming you do that, you are looking at about 1193046 hours to hash the entire address space. More specifically, you are looking at 1193046 CPU hours.
You can rent a 96 vCPU c5.24xlarge instance from AWS for a rate of $4.08/hour; or $0.0425/CPU-Hour. Assuming this offers the same per-cpu hashrate as the general purpose web-server, you are looking at a cost of $50,704 to construct a rainbow table. That is no where near a prohibitive sum of money.
You can probably reduce the cost by shopping around for compute or using bare metal. You could see significant cost reductions by using hashing optimized ASICs.
Combine this with the fact that no website is going to spend 1000ms just computing the hash for every request (even if you allow for caching). And the fact that they can probably narrow down the address space they are interested in considerably if they wanted to save money.
2^32 is just too small of an asymmetry between legitimate use and an attack to be a viable defense.
But yeah, everything else you said makes sense.
For example, if you are talking with Alice and she says that she heard from Bob chat Charlie was in the office at a weird hour on the day in question investigators have gains nothing that they can admit as evidence [0]. However, there is nothing that anyone (defense or a third party) can do challenge this portion of the investigation other then keep it out of evidence, and the investigators are free to follow up with either Bob or Charlie to get something that would be admissible.
They said: "personal computer", which could easily have 2x GPUs and 16+ cores. Heck, laptops nowadays can have a pretty good discrete GPU.
Using password grade hash with a =nonce= is absolutely no way to be accomplished per each request. The nonce would have to be the same for multiple uses - hence NOT a 'nonce'. The sharing of the said non-nonce would require a form a replicated Map (or IP-sticky processing with a local map). It's rather convoluted solution for absolutely no benefit as it's still not hard to brute force.
Storing it in such a way - slow hash + salt yields no benefits for debugging either, so I wonder why would you do so? Password hashes are useful for proving a match with an unknown plain text (while making it expensive to brute force) - so what would be the exact purpose of having non-nonce+IP?
b/scrypt and all other password grade hashes are slow on purpose but they are slow per each use. Imagine the processing takes 0.1s (which is on the low side of hardness) per each request - you just killed all your servers w/o any designated DoS. If you abandon the nonce and use the same salt multiple times (so the computation is amortized), it'd take a replicated cache of IP->hash and even then it still doesn't accomplish much...
A site I was repairing after a hack fortunately had server logs which included IP data. That IP allowed me to identify the specific exploit used.
So, there are definitely uses for IP data in security terms.