Binary Log:
Submit repro build proof here.
FAQ
- But it doesn't match! Yes, you don't have factory keys. All but 64 bytes of the signature itself will be exactly same. Mask out those bytes to do diff.
- Who can submit? Anyone. Ideally not the project maintainer, but even that might help others see the process on video to repro themselves.
- Can I submit the same version already proved? Yes. A few proofs of the same are welcomed!
- What are the specs for the video?No audio, smallets resolution where the text still legible, terminal only.
- What profile should I link to?Any profile where you have reputation.
- What's SHASUM? TL;DR a summary digest that you can use to compare the bytes to make sure they match. More info here.
- Who maintains this site?At the moment @nvk who hopes to have more maintainers.__looking at you__ come help!
- Why should people care?Most users are not capable of building from source code themselves, but we can at least get them able enough to check signatures and shasums. When reputable people who can tell everyone they were able to reproduce the project's build, others at least have a secondary source of validation.
- What is the build bot? This is a GitHub automation create to automaticaly try to build a few of the projects. It is not as trustworthy as a reputable community member, but it is at least one more source of evidence. If click on the "Build Bot" tag, it will take you to the build script used.
Other Resources
- WalletsRecovery - Wallets Derivation Paths and other recovery information.
- "Bitcoin Extended Public Key Converter" by Jameson Lopp ↗︎
- "Mnemonic Code Converter" by Ian Coleman ↗︎
- "HD-Wallet Scanner" by Alex Kaul ↗︎
- "PSBT Toolkit" by Ben Carman ↗︎
- [Released] Automated Scanner & BIP39 Recovery Feature for Electrum by Luke Childs ↗︎
Definitions from reproducible-builds.org
When is a build reproducible?
A build is reproducible if given the same source code, build environment
and build instructions, any party can recreate bit-by-bit identical copies of
all specified artifacts.
The relevant attributes of the build environment, the build instructions and
the source code as well as the expected reproducible artifacts are defined by
the authors or distributors. The artifacts of a build are the parts of the
build results that are the desired primary output.
Explanations
Source code is usually a checkout from version control at a specific
revision or a source code archive.
Relevant attributes of the build environment would usually include
dependencies and their versions, build configuration flags and environment
variables as far as they are used by the build system (eg. the locale). It is
preferable to reduce this set of attributes.
Artifacts would include executables, distribution packages or filesystem
images. They would not usually include build logs or similar ancillary outputs.
The reproducibility of artifacts is verified by bit-by-bit comparison. This
is usually performed using cryptographically secure hash functions.
Authors or distributors means parties that claim reproducibility of a set
of artifacts. These may be upstream authors, distribution maintainers or any
other distributor.