Include torrent in binary download verification

Sjors commented at 11:26 am on May 19, 2023: member

The binary verification script currently covers bitcoin(core).org but not the torrents. We should add an option to download and verify those as well.

fanquake added the label Scripts and tools on May 19, 2023

maflcko commented at 10:50 am on September 15, 2023: member

Closing for now, because the corresponding pull seemed stale and was just closed as well.

Not sure why there needs to be a script in this repo at all to download a file, and why it needs to be combined into the verify-binary.py script. It shouldn’t matter where the file comes from. You could have it shipped to you on a persistent storage medium.

It seems best to keep the download logic in separate scripts for each network (ipv4/6, torrent, tor, ipfs, …). Also, if there is need to have it (in one script or multiple scripts), it could make more sense to have it in a separate repo?

maflcko closed this on Sep 15, 2023

Sjors commented at 4:03 pm on September 15, 2023: member

The problem is that our Guix builds don’t commit to the torrent hash. So the only way to verify if the torrent distribution isn’t tampered with, is to download and verify the binaries inside of it.

We don’t distribute the binaries over IPFS afaik.

It would make sense to at least download from the hidden service and see if the downloads match what we provide over .org. For the .org I suppose it could make sense to download both over IPv4 and IPv6 and check that they match.

maflcko commented at 9:44 am on September 17, 2023: member

download both over IPv4 and IPv6 and check that they match.

I don’t understand the logic where the source (or transport protocol) of a file is used to verify the file. My understanding is that there is a checksum file included, which can help to catch non-malicious file corruption. Also, the checksum file can be signed by people you trust (or by yourself if you guix-build yourself), which can help to catch malicious file (and checksum file) corruption.

Sjors commented at 10:33 am on September 19, 2023: member

There’s two forms of checking:

By individual users, they can use the signed checksum file
By people keeping an eye on bitcoincore.org to see if it’s compromised.

I’m talking about (2) here. The easier such a check is, the better.

maflcko commented at 10:57 am on September 19, 2023: member

Ok, I see. Let us know if this issue and/or #27762 should be reopened.

Sjors commented at 11:08 am on September 19, 2023: member

I’ll leave it up to @willcl-ark if he wants to reopen the PR, but let’s re-open this issue.

maflcko reopened this on Sep 19, 2023

maflcko added the label Brainstorming on Sep 19, 2023

willcl-ark commented at 9:29 am on September 26, 2023: member

It would make sense to at least download from the hidden service and see if the downloads match what we provide over .org. For the .org I suppose it could make sense to download both over IPv4 and IPv6 and check that they match. @Sjors sorry but I don’t understand exactly what you mean by this. Are you advocating for including torrent downloading facility inside of this verify script? If so then I still disagree and think this is highly undesirable.

So the only way to verify if the torrent distribution isn’t tampered with, is to download and verify the binaries inside of it.

What else are you suggesting should be done, apart from this?

Sjors commented at 1:32 pm on September 27, 2023: member

Are you advocating for including torrent downloading facility inside of this verify

Depends on what you mean by “facility”. I think we should download them if there’s a torrent download command on the system. Just like we download if wget / curl is on the system. But we should not add a (large) torrent Python dependency.

For that to work, we could either add the magnet link to the script or find it on bitcoincore.org.

What else are you suggesting should be done, apart from this?

I think (some or all of) the following are useful to check:

That bitcoincore.org does not link to a malicious torrent (i.e. check that the torrent hash matches what we expect)
That the binaries inside that torrent are the ones we expect (just based on the file checksums, since we already check them against guix signatures via the regular download part of the script)

willcl-ark commented at 1:37 pm on September 27, 2023: member

Depends on what you mean by “facility”. I think we should download them if there’s a torrent download command on the system. Just like we download if wget / curl is on the system. But we should not add a (large) torrent Python dependency.

I see, so we would do something like check to see if rtorrent or transmission-cli are found on PATH, and only proceed with the download and verification if they are? I think I could get behind that.

Sjors commented at 3:14 pm on September 27, 2023: member

Exactly(and only if the command is run with something like --torrent, which should explain that this will happen, since we don’t want to accidentally trigger some malware)

willcl-ark commented at 2:34 pm on October 16, 2025: member

There doesn’t seem to have been much activity around implementing this feature.

If it’s something you’re still interested in, please feel free to open a pull request or if you think this issue should be re-opened leave a comment in here.

willcl-ark closed this on Oct 16, 2025

Include torrent in binary download verification #27702