Bitcoin Forum

A while ago, i built a docker image for those wanting to run bitcoin core v27.1 with the testnet4 patch (which now has been merged into v28.0rc1). For fun, i also compiled the last couple of "actual" releases.
I basically got obsessed with how far back i could go, so i got to the v26.x, then v25.x... And a couple of days later, i was knee-deep into v0.9.x,...

Then, i realised a lot of people actually asked questions about old versions... Either because they had an old wallet they needed to manipulate, because of curiosity, because they wanted to learn, because they wanted to see the size of those binary's, because they wanted to know when a certain feature was implemented (or deprecated).... So i started pushing the docker images to dockerhub.

At this moment, i'm up to version v0.2.1, the oldest version i have was released in November 2009.
For transparency, i added all Dockerfiles, bitcoin.conf's, patches, entrypoint.sh's in a git repo. Each branch is a version... So if you checkout the v26.0 branch, you'll see the dockerfile to build bitcoin core v26.0. If you pull the docker image with tag v26.0 from either dockerhub or ghcr.io, you'll get the docker image built by using the Dockerfile you can get from my git repo in branch v26.0.
Around v21, the version scheme was altered... Pre v22.x versions, there was an extra "zero"... So instead of v21.0, they version scheme actually indicated this version as being v0.21.0. For simplicity's sake, i have omitted this... v0.21.0 was branched and tagged as v21.0 (same for all earlier versions aswell)


Now, for the url's:

Dockerfiles
You can get the actual Dockerfiles (so you can build the images yourself) from my git repo:
https://github.com/mocacinno/bitcoin_core_docker/
the repo has loads of branches, each branch contains the Dockerfiles for one specific version...
You can visit the branches directly like this: https://github.com/mocacinno/bitcoin_core_docker/tree/v3.6  => for example, the Dockerfile to build v3.6 (v0.3.6 if you want to be completely correct).

Docker images
https://hub.docker.com/r/mocacinno/btc_core/tags
or
https://github.com/mocacinno/bitcoin_core_docker/pkgs/container/mocacinno%2Fbitcoin_core_docker/versions?filters%5Bversion_type%5D=tagged

the images hosted on github are built using a github action (which is also described right into the branches!!!), each time i push changes, a new image gets built and uploaded. You should be able to verify the process yourself if you want to... Just fork my repo and push any change, and the image should build in your very own namespace!!!

Documentation
https://mocacinno.github.io/bitcoin_core_docker/

Help me
for now, a lot of work is quick and dirty... Basically, i was working backwards from the most recent version (which is very easy to compile) all the way back to 2011 (and digging deeper as we speak). Each time a new problem popped up, i tought about the quickest way to fix the problem at hand... Sometimes it was by actually pulling the "good" dependency into my build process, or by downgrading gcc, but sometimes it was faster just to write a little patch, or quickly modify some lines in the sourcecode with sed... This way, i postponed "problems" untill later on. In time, i might go trough all the dockerfiles again, and try to fix the problems in the "right" way instead of using sed and patches... If you want to help in this process, just fork my repo, fix a certain branch and create a pull request :).

In time, i might seek some volunteers that i trust and give them access to my github project, or maybe even my dockerhub project, so they can help clean things up (or help with the documentation). For now, pull requests will do tough...

Help you + disclaimer
More recent versions should be OK to run (even in production), i compiled the actual sourcecode from bitcoin's github repo and put it in a very minimal container, so there should be hardly any vulnerability's. If you're not that technically inclined, it might even be safer to run the image i made vs trying to compile core yourself and run it on a full OS. This being said: if you're actually going to use this node for production (or to actually use the wallet functionality), i implore you to read the Dockerfile, sign off on what i did and build the image yourself. I'm a strong believer in the "don't trust, verify" motto!
If you run the image in production, don't forget to actually map the /root/.bitcoin container folder to a physical folder on your filesystem so you get a persistent setup!!!

Don't run older versions in production tough... I've actually played around with this stuff, and since v0.5.0, it looks like bitcoind actually starts syncing (early) blocks... However, it's a very, very, very bad idear to actually run these old versions!!! if you want to play around with them, i suggest you start the docker container with a "--network none" flag, so they are isolated. Old versions have vulnerability's... Using them, especially in production or by actually funding the wallet will probably end up with loss of your funds!!!

I will not take any responsability for loss of funds, even with new versions!!! Also, i do not commit myself to giving support... I compiled these versions, i did not write the sourcecode... I'm not a specialist on the features included (or removed from) these versions.... If you have a question, feel free to ask. If i know the answer, i'll answer you (but if i don't know the answer, you're on your own)

Currently, i have worked back in a "clean" way up to v0.3.4 (or v0.3.5, versioning wasn't really consistent in the olden days).
v0.3.4 is the oldest version that can be compiled without wxbase and wxwidgets. Earlyer versions had this nasty quirck: even if you wanted to compile bitcoind without a gui, you still needed to compile wxwidgets on your system, it needed to be availabe or bitcoind wouldn't build (eventough bitcoind without gui has no use for wx)...

I have actually looked at the diff between the commit made to release v0.3.4 and one commit before this commit. I have made a patch including all changes needed to compile bitcoind without wxwidgets. v0.3.3 was patched with said patch, and afterwards it compiled just fine.

Please be advised that v0.3.3 was heavily patched...

If anybody wants to spend a couple of "fun" days, feel free to find out how to get a 14 year old wxwidgets sourcecode compiled on a modern OS... I don't want to invest the time and energy... It needs so many prereqs, many of whom are very hard to come by... They'll need to be compiled manually, and these prereqs potentially have prereqs on their own, so it's well possible you'll end up compiling a complete library of dozens lib's from ~2010 just to get this working... For now, i'll pass :)
I WILL however try how far i can go back using the patch i just made... If the patch no longer works, it might be possible to create a new patch by hand, but as it stands, the current patch is over 50 kb in size, and i really don't want to create one by hand...

EDIT: I continued working on this project, and i'm now all the way back to v0.2.8, released in December 2009!!!

reserved for future collaborators

reserved for the most common usecase scenario's

It's worth to mention that version 0.7 and older cannot process block after certain height[1], which means you can't finish IBD.


It's not my idea of "fun" either, but this is when people should consider using older version Debian or Ubuntu. Although i expect it's still tricky to find repository/website which host legacy package.

[1] https://blog.lopp.net/running-bitcoin-core-v0-7-and-earlier/ (https://blog.lopp.net/running-bitcoin-core-v0-7-and-earlier/)

Thanks for the notice... I honestly did not wait untill IBD finished. versions pre 0.5.x simply don't start syncing (eventough the link you provided talks about v0.3 being able to verify at least ~124.000 blocks) , but it's possible the versions simply don't find any peers or something? I don't really remember :). Version 0.5.x does at least start to sync without having to manually define any nodes to connect to.


True. The problem tough is that such old ubuntu (or debian) base images contain a ton of vulnerability's... I basically got obsessed with building these old versions into a lean, up-to-date basic container, so the user wouldn't have to worry about any potential vulnerability's in system library's or binary's (however, the bitcoind binary will contain vulnerability's itself, and the number of those vulnerability's will rise the older the bitcoin core version)

As you can see in the original post, i did already state this pretty clearly:


These older container images are here for stuff like very old wallet file manipulation, learning, seeing when certain features were implemented or removed, curiosity, settling disucssions,... they're not here for people to run a full node using bitcoin core v0.19.0 (unless it's on an isolated machine and without using the actual wallet functionality... This usecase might be OK... Eventough the actual usecase for this would probably still be learning about stuff like soft forks or something). I hope this was clear to everybody from the get-go (or should i put some more emphasis on this in my opening post?)

It could also be a very good use case for developers to use for triage and bug testing so that they don't have to compile their own Bitcoind every time they want to check for a regression.

But then I guess this is only useful if it also includes builds for each development commit, and obviously you both don't have those and they would be too costly in terms of storage space to keep.

Version v0.2.7 was just successfully built... Released around november 2009...

In case anybody is wondering how "easy" it would be to build this:
https://raw.githubusercontent.com/mocacinno/bitcoin_core_docker/refs/heads/v2.7/Dockerfile

I needed

• A ton of packages to set a more or less working gcc 4.8 env
• compiled openssl 0.9.8k from source
• compiled berkely db 4.7.25.NC from source
• compiled boost 1.57.0 from source
• compiled xorg util macros 1.3.0 from source
• compiled xorg xtrans 1.0.2 from source
• dragged freetype1 headers into my env
• compiled pango 1.24.5 from source
• compiled wxwidgets 2.9.0 from source
• compiled bitcoin core v0.2.7 from source (duh)
• had to repeat the multistage built for a dozen of times to pull in missing library's in the final image

This one was a doozy....

I've just built v0.2.1 and filled in the "gaps"... There are a couple v0.3.x versions that were not available on github... Got the sourcecode from sourceforge and hosted it on my own github repo (because sourceforge did not contain releases, only commits... And it's very hard to download the code up to a certain commit in a sustainable clean way from sourceforge).

I've also added v28.0 and removed most traces of the v28 release candidate.

I've also reworked the documentation quite a bit (eventough a lot is still lacking): https://mocacinno.github.io/bitcoin_core_docker/

The only version i'm still "missing" in the collection is v0.2.0... It has given me quite the headache... v0.2.0 gives errors with wxwidgets 2.9.0, it requires 2.8.9. It also gave me troubles with gcc 4.8, so i had to switch to 4.3. It also gave problems with boost 1.57.0, so i had to switch to 1.40.0... And after all these ancient prereqs were built, i still got tons of errors...  I started patching, patching, patching,... and in the end still could not figure it out... My latest WIP can be found here: https://github.com/mocacinno/bitcoin_core_docker/blob/v2.0/Dockerfile . If somebody smarter, more persistent or luckyer wants to lend me a fresh pair of eyes: be my guest, you'll get credits in the documentation if you succeed in building v0.2.0 (and making this the only complete archive of all linux-buildable bitcoin core versions inside a modern container!!!)

ps: i say "complete archive of all linux-buildable bitcoin core versions" because v0.1.x releases were windows only... They could never be built on linux, so there's no point in trying to compile them... Unless i find a way to cross compile and then use wine... But since i'm not able to get v0.2.0 figured out, there's no use in taking it even further at this point in time.

I never really had the interest to run an older bitcoin core version.

This project made me curious and I will definitely try it.

1. My first contribution will be a very simple PR, to familiarise with the repo. I will just add the release date and perhaps the main changelog of the version in README.md of each branch.
2. My second contribution will be ... _{check your tipping address}

EDIT:
a. For the time being, I am just experimenting to see how it works! Once I have more time available, I will make the PR.
b. Seems like I have an issue with the boost libraries. I will need time to debug, so I 'll be back as soon as possible.

Thank you very much, i don't get many tips, it's always nice to receive one! I'm looking foreward to any PR's :) (i'm equally happy with code and documentation contributions... The documentation actually needs just as much TLC as the code itself, but currently i focussed on the code waaaaay more)

If boost is giving you problems, you can probably try to run the steps from one of the Dockerfiles i wrote inside a fresh suse container... That should probably work... Don't be supprised by the time it takes to compile tough, i rented a 16 core VPS for the task and it still took a couple of minutes, so on a single core it would take more than half an hour.

So, in reality, pick any modern linux desktop, laptop, server or VPS (it has to be linux, suse's base images are not compiled for windows, but they are compiled for linux on the most common hardware platforms, so it doesn't even have to be x86). Make sure docker is installed (usually trough your os's package manager, but a manual install is equally good). If you don't want to use docker, podman should be equally good (eventough it is untested for now).

Then, start an empty container:


Then, open a branch... The v0.2.0 branch (called v2.0) has the build instructions for boost 1.40.0. Branches v2.1 up untill v8.x have boost 1.57.0. Branches v9.x untill  v15.x have boost 1.63.0. Branches v16.x until v22.x have boost 1.66.0. From v23.x on it's boost 1.86.0.

Basically, open the dockerfile of a branch containing the boost version you want to compile... For example v24.1 for boost 1.86.0 : https://github.com/mocacinno/bitcoin_core_docker/blob/v24.1/Dockerfile

This is your cookbook. Basically, either in a text editor or in your head do the following:

• ignore the first line starting with FROM, you basically already did this by executing `docker run -it registry.suse.com/bci/bci-base:15.6` (registry.suse.com/bci/bci-base:15.6 is indicated in the first FROM line)
• run the lines starting with RUN in your container (remove the RUN keyword offcourse)... If the line reads "RUN ./mycommand", you'll have to execute the command `./mycommand`. There is one "caveat" tough: Docker images can only contain a certain number of layers, so in older versions, i developed the habit of running multiple commands under one RUN directive... If you're debugging, it might be a better idear to split them up and run them individually... If a RUN directive line is ended by "&& \", the next line contains a second command that's run directly after the first one... When debugging, it's a good idear to run them seperately
• the lines starting with ENV indicate an environment variable has to be set inside the container... Subsitute ENV by the keyword `export` and execute the line inside the container
• substitute the keyword WORKDIR by `cd` and execute inside the container
• if you reach the second FROM directive, you should ignore this line and all lines under said line... I'm doing a multi stage build (basically, i first create a full compilation environment where i compile everything i need, then i "start over" with a minimal base image and copy the resulting binary's and library's inside this minimal base image... This way the resulting image is smaller and contains waaaaay less attack vectors... But for debugging, this is not interesting

Offcourse, if you're just trying to compile boost, you can skip the build of other prereqs... You don't have to compile openssl 0.9.8k if you're just trying to compile boost...

The point behind tipping you was to give you an extra motivation to continue the good work. I 've seen multiple of your posts and I respect your contributions. So keep it up!


Thanks for your detailed help. Unfortunately I won't be able to try it until the weekend, but I know I 'll make it work somehow!

---

Lastly, I am a developer myself, so I know for a fact that especially with open source, something that is super tempting can be difficult to keep trying for, but keep it up!