I uploaded the file directly on my fork of your project. I don't know why I didn't think of that earlier. Feel free to try.

You can use a Github Action for this. You could trigger a script to run every time events.db is updated. The script could handle all the formatting, changing the dates (if that is still the best option), adding the recurring rule, and then generate the .ics file, and commit it back to the repo automatically.

Cool! For future reference, here is how to title the headings in a .csv to import it into Google Calendar, then export it out into an .ics file. Since the start year is in the description, I made the start year for each 2025...I wasn't sure if it would make the calendar file large when importing if it showed events yearly for 100 years in the past.

Darn. Yea the file worked for me, but I didn't try to redownload it from Github and open it. Your repo didn't allow file uploads (I understand that), so I opened it in a text editor and copied and pasted the contents. It must have been wrapping issues or formatting. It is working on mine.

I created a pull request in one of your Bitcoin Calendar repos with the .ics file.

Cool! I have it exported in the correct format now, just fixing the headers before converting it to an .ics file. I'll share when complete.

That's cool. Maybe I'll make an Android and iOS calendar import file for this also.

And with 4K and drones, I can see much better from my humble abode.

There is

I also analyzed the blockchain and found all Bitcoin addresses from Gavin's faucet that still has exactly 5 BTC left in it. Here they are in case anyone is interested:

12pcpC4NG6PHifMREyNjnR41PFuudKRM7f 12rQnKpEVv7prwpBucoFVrXDyshpe9sYZy 13toU2eP1aCdnmhjcLWbd8wJgP6D8MVHB7 13xpydFpNmf2ByyjjmcGF1zXdnPs2zQDY1 14F9j4e4WZroFNNVgdCLUaiGTdy1J9BrFQ 167efihXWqHsfussQcj711bXZGQPiePXq8 18piBJepQAmi33zHqDdgWRUvDgYaCgTch4 1Axjj8761sjBQM4Jt2Fq12KwyQA2Z4D2jE 1C4ScBCmcFSz4mmZ6a9nmGq6zkRfUzJAr7 1CtwTtk4DnvNfxQ9Qd1GAgrH7EzbqX9GrJ 1CWqFwfmxEVeHFf1RmuJwUPDLmN6pBHBW5 1DEUUd6Fue8pVvxkT6uRPk9APnnmjxecgY 1DnYvSf65MwEbtW9C5FhbYrqRE3AYg7j4x 1DYFqhdKDkHYytVn66QWKGY4PUebNYH9j9 1G1jAXvQopW3Cris9fxscn9pVWzy9KmdR2 1GqyMrauH8Ws7vWQ3HfB7eeQGR35tThCAT 1GZnkxbjWwQqX8vVXE52ZeZ7P5HHsmBh83 1H26F45ywpZJvGE2f1bWraDmH7E2FnKn5P 1H2vJJ2t6cC2TVw5oqJAPmTt6gs1wizmUu 1HoVneq7AK2x5F5BuivamTsZchVkAxPkCK 1J2aamKZe9pRxGUy6Kfc22hXUKLrxAY4bb 1K1p9F4vWqHP825pYSB9S2MEB3eTUBw32t 1K9156Feso5aVTuoQBa28cpnNwp4agBnG4 1Kog7hAjgVTJQtEGsxsikNU7fV13pamzTP 1NA7gCCfS9Ye5gdpWkmSBJrvhjQByE4VLf 1PF7C5376DXmuE4yWYffujSzCrvEM9HR7D 1PF7UANHt5f7VGsD8f5MAhWsJzsiWv8rRr 1PNZCfCHQo7N42AsdCBfeZP9XGMUYgJZAc 1PvHppN9n5zobsX1ZAr1bE81huUhqjeErn 1rD82Qit1uFVaXZ6YXjm9Ecfmed9eobrr

Quick update on my effort to recover a corrupted 66-character private key from 2010. Thanks again for all the helpful input.

Plan A assumed the key had two extraneous hex characters. I ran btcrecover across all 2,145 two-character deletions with no luck.

I’m now shifting to a more advanced typo-correction pass (Plan B). The goal is to fully exhaust the “it’s just hex typos” hypothesis using btcrecover’s richer error models: mixed errors (one deletion plus one substitution), adjacent swaps, and systematically increasing the allowed typo count to 3–4 while managing runtime.

In parallel, I’m lining up Plan C. FinderOuter is on the table, though its Mono dependency is a downside for a clean offline setup. I also considered a custom Python script, but for multi-typo searches btcrecover’s C/Cython backend is likely the better bet.

There’s also a more complex angle: the mangled WIF hypothesis. If this isn’t a raw hex key, it could be a fragment of a hex-decoded WIF. A decoded WIF is 74 (uncompressed) or 76 (compressed) characters, including version, key, optional compression flag, and a 4-byte checksum. That would imply my 66-char string is missing 8–10 characters rather than having 2 extra. Recovery here would mean inserting the right characters to satisfy both the derived address and the WIF checksum—brute-force is likely infeasible without stronger constraints.

I’d appreciate any tips on btcrecover flag combos or optimizations for mixed typo models, thoughts on the plausibility of the mangled WIF scenario (especially with 8–10 missing decoded chars), and any other corruption models I should be considering.

Quick update on my effort to recover a corrupted 66-character private key from 2010. Thanks again for all the helpful input.

Plan A assumed the key had two extraneous hex characters. I ran btcrecover across all 2,145 two-character deletions with no luck.

I’m now shifting to a more advanced typo-correction pass (Plan B). The goal is to fully exhaust the “it’s just hex typos” hypothesis using btcrecover’s richer error models: mixed errors (one deletion plus one substitution), adjacent swaps, and systematically increasing the allowed typo count to 3–4 while managing runtime.

In parallel, I’m lining up Plan C. FinderOuter is on the table, though its Mono dependency is a downside for a clean offline setup. I also considered a custom Python script, but for multi-typo searches btcrecover’s C/Cython backend is likely the better bet.

There’s also a more complex angle: the mangled WIF hypothesis. If this isn’t a raw hex key, it could be a fragment of a hex-decoded WIF. A decoded WIF is 74 (uncompressed) or 76 (compressed) characters, including version, key, optional compression flag, and a 4-byte checksum. That would imply my 66-char string is missing 8–10 characters rather than having 2 extra. Recovery here would mean inserting the right characters to satisfy both the derived address and the WIF checksum—brute-force is likely infeasible without stronger constraints.

I’d appreciate any tips on btcrecover flag combos or optimizations for mixed typo models, thoughts on the plausibility of the mangled WIF scenario (especially with 8–10 missing decoded chars), and any other corruption models I should be considering.

Hi folks, I'm still working on this. I have an address.db to check against and several different btcrecover commands I've tried, but without success so far. I'm sure I"m missing some things with the setup. I also create a btcrecover_gui frontend to help me. "https://github.com/gurnec/btcrecover/pull/565" I don't know if btcrecover is the best tool for me to use?

I'm still working on this.

How do you do that?

Thanks me too!