Okay... in a sense, yes, in hindsight, I should have planned for this. But there are a number of reasons I think this kind of response is too dismissive.

First of all, no matter how well you prepare, there is always going to be one level higher of system failure that you "should have planned for". In the npm-Linux-box-borking debacle, there were people insisting you should never have run npm except on fully disposable hardware with an instantly replaceable dev environment (which is the only thing that would have let you shrug it off).[B]

Got mugged walking home? Should have taken a safer route. Took a safe route? Should have walked with a friend. Still got mugged? Should have walked with two friends. For all n, should have walked with n+1 friends.

Second, it's painting with a tad broad of a brush to call me complacent on crypto. I've filed crypto taxes since 2017 and kept cost basis records from years before. I'm aware systems fail and (outside of this) have set appropriate backups and cached critical transactions to spreadhseets. Even here, even with nothing done by the Optimism team to correct their mistake, I'm not actually doomed, as I can file taxes based on an input-output analysis of my Optimism transactions as a good enough first pass, and correct later. The issue is unnecessary convenience.

In fact, as things stand today, I'm in exactly the "safe" position you thought I was -- "oh, it's there, you just have to query right". Indeed I do! Now that I've pulled the tx data from the alternate sources, I "just" have to yak-shave out a meaningful read of all the transactions. (Update: per sibling, you can download the transactions from a different tab but you still have to do some transformation.) But none of that takes away from the point that this is huge, avoidable inconvenience and flaky community relations.

Remember, even if I had cached them, I'd still be stuck having to manually import them into my crypto tax software, which is a failure from usability.

Third, there are reasons to expect optimistic.etherscan.io as a reliable source to point to.

1) When you set up e.g. Metamask, the Optimism site gives you exactly one URL to point to, with no alternatives or warning that one day it might be missing history. [A] The very fact that Metamask equates "nothing from that url" with "no transactions" means they were treating it as mission-critical.

2) The entire ETH community outside of Optimism relies upon etherscan.io for most of their own tooling ethereum projects. All sources for ETH projects say to connect there, as if it's inconceivable that there could be an outage or need for some fallback.

3) It would have been trivial to keep the transaction history up. There was already a server somewhere (etherscan-owned or otherwise) serving transaction history. All they had to do was configure it to be able to check transactions for being from before that switchover, and ping that (static) DB for a subset of them.

(Remember, this isn't, at least so far, an issue of cost: they do plan to get optimistic.etherscan.io back up as a reliable endpoint for the pre-upgrade txns, they just didn't think to upgrade a way that would facilitate such queries of already-existing immutable data.)

And, for the final kicker.

4) Optimism maintainers themselves didn't even think to locally cache all the transactions they'd need! (As in the one mentioned who only logged a proper subset of taxable events.) If the very people who live and breathe this stuff overlooked it, I think I can be forgiven for overlooking it, as they expect even casual users to join.

[A] https://metamask.zendesk.com/hc/en-us/articles/4403700785691...

[B] https://news.ycombinator.com/item?id=16438630