Running every Bitcoin Core release ever made inside Docker, all the way back to 2009

19 replies 180 views
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#1Sep 6, 2024, 08:44 AM
So it started with me putting together a docker image for bitcoin core v27.1 with the testnet4 patch (which has since landed in v28.0). Just for kicks I also compiled a few older releases alongside it. Then something clicked and I just couldn't stop... went backwards through v26.x, v25.x, kept going, and a few days later I was buried in v0.9.x territory. Turns out a lot of people actually have legit reasons to run old versions. Old wallet files they need to poke at, pure curiosity, learning how the software evolved, or just wanting to see how bloated (or lean) different releases were. That was enough motivation for me to keep digging.
2 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#2Sep 6, 2024, 09:49 AM
Right now the furthest back I've gotten in a reasonably clean way is v0.3.4 (or v0.3.5, honestly versioning back then was a mess and not consistent at all). v0.3.4 is basically the cutoff point where you can still compile bitcoind without needing wxbase and wxwidgets present on your system. Anything older than that had a weird quirk where even compiling the daemon without a GUI still required wx libraries to be installed, which makes zero sense since the daemon has no use for them. I did look at the diff between the v0.3.4 release commit and the one right before it, and I put together a patch that strips out that wx dependency so earlier versions can actually build without it.
2 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#3Sep 6, 2024, 10:11 AM
saving this spot for future collabs
3 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#4Sep 6, 2024, 10:24 AM
reserved for common use case docs, will fill in later
2 Reply Quote Share
Posts: 16 · Reputation: 12
#5Sep 7, 2024, 11:38 AM
Worth flagging: v0.7 and anything older can't get through IBD past a certain block height. So you literally cannot fully sync. There's a blog post by Lopp that covers this in detail. For people who still wanna play with those versions, running them on an old Debian or Ubuntu base is probably the way to go. Though tracking down the actual legacy packages from ancient repos is its own headache.
5 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#6Sep 9, 2024, 07:41 AM
Yeah good heads up, I should've mentioned that more clearly. Honestly though, with the really old pre-0.5.x stuff I didn't even wait for IBD to complete because those versions don't seem to start syncing at all. They just sit there. Could be that they relied on IRC for peer discovery and that server is long gone, not 100% sure. On the old Ubuntu/Debian base image thing... yeah that works in theory but those ancient base images are absolutely riddled with known vulnerabilities. My whole obsession became building these old versions into lean, up-to-date containers instead of just slapping them onto a crusty old OS image.
3 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#7Sep 9, 2024, 08:18 AM
I did already spell this out in the original post but I'll say it again for clarity: these images are NOT for running a full node in production. They exist for things like recovering or inspecting old wallet files, learning, figuring out when specific features appeared or got dropped, or just satisfying curiosity. Running v0.19.0 as an actual full node is a terrible idea unless it's fully airgapped and you're not touching the wallet. Even then the only real reason to do that would be something like studying soft fork behavior. Hopefully that's obvious.
4 Reply Quote Share
Posts: 9 · Reputation: 0
#8Sep 12, 2024, 01:02 PM
Another solid use case would be regression testing for devs. Instead of compiling old bitcoind from scratch every time you want to check if a bug existed in some older version, you just pull the image. Though I guess for that to be really useful you'd need images for every single dev commit, not just releases. And yeah, storage alone makes that basically impossible.
0 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#9Sep 27, 2024, 10:31 AM
v0.2.7 just built successfully. This one was released somewhere around late 2009. For anyone curious how painful the build process actually is, the Dockerfile tells the whole story. Here's roughly what it took: Had to set up a semi-functional gcc 4.8 environment, then compile openssl 0.9.8k from source, Berkeley DB 4.7.25.NC from source, boost 1.57.0 from source, xorg util macros from source, xorg xtrans from source, had to manually drag in freetype1 headers, compile pango 1.24.5 from source, and wxwidgets 2.9.0 from source. Yeah. It's a lot.
1 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#10Oct 3, 2024, 02:04 PM
Update: v0.2.1 is done and I've filled in a bunch of gaps in the lineup. Some v0.3.x releases weren't on GitHub at all, so I tracked down the source from SourceForge and mirrored it on my own GitHub. SourceForge was rough to work with because it only had raw commits, no proper release archives, and pulling code up to a specific commit in a repeatable way from there is a nightmare. Also added v28.0 and cleaned out most remnants of the release candidate. Reworked the docs too, still a lot missing but it's getting there. The only version I'm still missing...
1 Reply Quote Share
degenx380Hero Member
Posts: 4 · Reputation: 296
#11Oct 3, 2024, 02:43 PM
Honestly never had a reason to mess with old bitcoin core versions before seeing this. Now I'm genuinely curious and I'm gonna give it a shot. Plan is to start small: first PR will just be adding release dates and a quick changelog summary to the README of each branch. Second contribution... check your tip address lol. EDIT: currently just tinkering to understand how it's set up. I'm hitting a boost library issue that needs some debugging before I can move forward.
1 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#12Oct 7, 2024, 08:35 AM
Thanks for the tip, really appreciate it, doesn't happen often! Looking forward to any PRs you send, code or docs, both are equally needed. If I'm being honest the documentation needs just as much love as the code but I've been way too focused on the code side. For the boost issue, try running the steps from one of my Dockerfiles directly inside a fresh container and see how far you get. And fair warning on compile times: I was running a 16 core VPS for this and some of the older versions still took several minutes to build, so don't be surprised.
4 Reply Quote Share
degenx380Hero Member
Posts: 4 · Reputation: 296
#13Oct 7, 2024, 08:16 PM
The tip was just to say keep going, your work here is solid. I've seen your posts around and the effort you put in is clear. I'll get back to it over the weekend. I'm a developer myself so I know how open source projects like this can feel super compelling one day and then just... stall. Don't let that happen with this one.
3 Reply Quote Share
degenx380Hero Member
Posts: 4 · Reputation: 296
#14Oct 12, 2024, 09:01 PM
Back with an update! Got v2.10, v18.0, and v27.0 all running successfully. This project is honestly like a museum of Bitcoin Core history, it's wild to see how much has changed. Tried v2.10 specifically. The Dockerfiles are incredibly well put together so setup wasn't the problem. But I'm running into network errors with that version. Nothing connecting. My reason for trying the old stuff is purely academic, no real use case, I just want to see how different things were back then compared to now.
4 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#15Oct 14, 2024, 11:17 AM
Just tested v2.10 myself. My VPS already had port 8333 occupied so I mapped it to 8133 instead. Grabbed the container ID and checked the debug.log. After running for over an hour the connection count was still sitting at 0. My guess is these old versions used IRC to find peers and that infrastructure is just gone now. That's just a hunch though.
2 Reply Quote Share
degenx380Hero Member
Posts: 4 · Reputation: 296
#16Oct 14, 2024, 02:18 PM
Same error on my end too. The image itself runs fine, container spins up no problem, so it's definitely not a setup issue. It's just Core from that era not being able to talk to anyone on the modern network. Would be interesting to hear from someone closer to Core development about what exactly breaks. Purely out of curiosity.
1 Reply Quote Share
Posts: 1 · Reputation: 1
#17Oct 14, 2024, 02:59 PM
Two things that are probably causing this: 1. Really old versions used IRC for bootstrapping peer connections. That doesn't exist anymore so they have no way to find nodes. 2. The P2P message format changed at some point to include checksums. Ancient nodes and modern nodes literally can't communicate with each other without some kind of workaround in between. You could try messing with your hosts file to redirect traffic somewhere that returns your external IP cleanly, something minimal with no extra browser junk in the response, but honestly I'm not sure how far that gets you.
1 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#18Oct 31, 2024, 12:33 PM
Huge milestone: v0.2.0 compiled and running. The collection is complete. v0.2.0 through v0.2.6 are GUI only, no daemon mode, so you need a special setup to get the GUI out of a container. Instructions for that are on the docs site. v0.1.x is out of scope permanently. Those were Windows only and the whole point of this project is Linux containers, so that's never going to happen. And yes, I know, the really old versions are insecure, can't sync, can't connect to real peers. That's all fine. These exist for learning and historical purposes only.
5 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#19Nov 1, 2024, 11:17 AM
Fixed a font rendering issue affecting v0.2.0 all the way through v0.6.0. Turned out to be a missing package, simple fix once I found it. So now the collection is complete AND actually usable. One tradeoff: for the GUI only versions I had to drop the multistage build approach. The GUI needs a ton of libraries, fonts, configs, binaries... making that work cleanly in a multistage setup was more trouble than it's worth for versions that nobody should be running exposed to the internet anyway. So v0.2.0 through v0.6.0 images are bigger and have a larger attack surface. Don't run these things publicly, seriously.
1 Reply Quote Share
titan_hodlerSenior Member
Posts: 13 · Reputation: 120
#20Nov 1, 2024, 11:37 AM
v28.1 is building right now, should be available within a few hours under the v28.1 tag and also as "latest". I'm rebuilding all images on top of base images that include yesterday's patches. Also had to deal with a repo issue: some older repos that hosted packages for pre-v0.9.0 stuff got removed. Found a solid replacement that has compatible packages so that's sorted now. If you cloned the repo at any point, definitely pull before you try to build anything. EDIT: v28.1 is live on ghcr.io EDIT 2: DockerHub took way longer, got rate limited mid push, will update when that clears.
2 Reply Quote Share
?Reply
Sign in to reply to this topic

Related topics