docker-bitcoin-core
docker-bitcoin-core copied to clipboard
Add v25.1, update minor releases, use bitcoincore.org, verify using bitcoin core verify script, fixup alpine builds
This pull includes a number of changes:
- fix broken older builds, and update some minor point releases
- add v25.1
- switch default binary repository to bitcoincore.org for better reliability
- use the bitcoin core
verify-binaries/verify.py
script to simplify downloading and verifying versions >= v22.0 which are now signed by keys found in the guix.sigs repository - lock builds to debian:bookworm-slim
Each commit message contains additional detail on the rationale and implementation.
If I got this right, this should also:
close #140 close #139 close #138 close #137 close #136
I'd like to see this, or something like this, merged and have updated images available from this repo, so let me know if you'd like any changes from me to move this forward.
Re the commit message in "Use bitcoin-core verify.py script": I opened a pull https://github.com/bitcoin/bitcoin/pull/28418 to permit exact architecture-platform specifiers and reduce the amount downloaded by the verify.py script.
IMO even if it's unsuccessful there, it doesn't matter much here, as these images are not updated frequently. So an extra few MB downloaded once or twice a year is OK.
@willcl-ark In my fork ( https://github.com/dobtc/docker-bitcoin/blob/master/Dockerfile ) I do the verification directly from the Dockerfile without the need for any Python runtime. Since it is only during the build-stage it does not matter much, but it seems a bit simpler.
Other differences that might be worth copying:
- I updated it from Debian Buster to Debian Bookworm
- I remove the test_bitcoin binary. This is 12 MB of space savings as it is not used at all.
@kroese updating to bookworm and removing test_bitcoin
are good ideas, I missed those and will take them here.
Re the verify script, I was split trying to decide which was the better approach; do people prefer to "see" the bash script in the dockerfile (and do I want to reimplement the functionality in bash, which I now see you've done!) I opted to use the core script as it does a few useful things in one:
- fetches the file, from multiple sources if possible
- (hopefully) will change in a backwards-compatible way if the binary verification process changes in the future (lower maintenance)
- allows specification of
--min-good-sigs
if that was wanted here
Would be happy to revert that commit and take your changes if that was preferable to this repo though? cc @ruimarinho
I fully agree that your solution is better. The only reason I did it in bash is that in the original Dockerfile it was also done that way so I wanted to minimize the amount of changes.
I fully agree that your solution is better. The only reason I did it in bash is that in the original Dockerfile it was also done that way so I wanted to minimize the amount of changes.
Actually, I'm not 100% convinved on it mysel; I'm happy to go either way on it still. I was just detailing my thought process :)
As the tests are passing on my fork, I added a commit to lock builds to bookworm.
Should this be updated to v25.1 now?
@ruimarinho is there anything blocking this? Would be good to at least get approval for the CI to run.
I'm running the CI against my own dockerhub repo over here: https://github.com/willcl-ark/docker-bitcoin-core/actions/runs/6769216413
@ruimarinho Any attention this PR can get would be greatly appreciated. You're likely busy, but it seems like this would be an easy layup and having 25.1 available would help the Bitcoin community.
@CharlieC3 Just 25.1? By now 26.0 is already available.
I forked this project a few months ago as it seems pretty abandoned. So if you are looking for an alternative, Im providing automated builds of every possible version (even release candidates) at: https://github.com/dobtc/bitcoin and https://hub.docker.com/r/dobtc/bitcoin/
@kroese I wanted to keep the ask small :) And thanks! I'll check it out.
https://github.com/ruimarinho/docker-bitcoin-core/pull/145 i added v26.0 based on this pull, does it makes sense?
26.1 is also now available.
26.1 is also now available.
Commit added to this branch with 26.1
Do we have an ETA for these changes?