How to verify the client when Bitcoin’s new technology is updated? Bitcoin has been updated with new technology. Many people don’t know how to verify the client. Let’s take a look with the editor. I hope this article can be helpful to you. .
There are three important steps to ensure that the Bitcoin client you install is secure:
Verify OpenPGP key;
Verify signature;
Verify the document itself;
Please note that, for example, I will be verifying my own signature on the Bitcoin Knots v0.19.0.1.knots20200104 client for ppc64le Linux, whereas to verify someone else's signature or other files you will need to change the command line to Use that fingerprint or file name.
Step 0: Install encryption software GNU Privacy Guard (GPG)
Before you begin, you need to make sure you have the GNU Privacy Guard (GPG) tool installed, which is required for encryption verification of files.
If you're running a Linux-based system, which is usually installed through the operating system vendor (recently, this is usually installed by default), you can check this by running gpg –version. If not, try installing it using one of the following commands (if that fails, go to the next one):
apt-get install gnupg
dnf install gnupg2
yum install gnupg2
emerge app-crypt/gnupg
pacman -S gnupg
apk add gnupg
If you're unfortunate enough to be using a Windows or macOS operating system, you can download GnuPG from the official website, but I'm not aware of any secure way to verify such a download, and of course they do provide a signature, but here's the rub. The egg problem: you can't verify these signatures until you install a good copy!
Step 1: Verify OpenPGP key
This step is arguably the most difficult part of the verification process: you need to confirm that the key you are actually using is the correct one issued by someone you trust. If you're not careful, you could get a fake "Luke Dashjr" key!
Each OpenPGP key has a "fingerprint", which is 40 hexadecimal characters (the digits 0-9 and aF), with spaces sometimes shown for easier reading. You know you have the correct key if you make sure that the key fingerprint you use matches the fingerprint of a trusted signer.
Get a key or fingerprint
The most secure way to verify a key is to meet in person and confirm the key's "fingerprint." Almost no one remembers their key fingerprint, so we may have to look it up on our own laptop or phone, and occasionally (usually at a conference) there may be a "key signer", a group of people at the conference confirming others of fingerprints, each participant would either have their own fingerprint read aloud or manually confirm that what everyone saw or heard was correct. If you ever get involved in a meeting like this, this is a good way to verify many keys at once.
If you're not interested or don't have the opportunity to meet in person, you should ideally verify the key from multiple sources. Occasionally, conferences post presentation videos in which the key fingerprint may appear in the slides. Of course, due to the existence of new technologies such as "deep fakes", be aware that the slides in the video can be easily manipulated.
Developers usually publish their keys or fingerprints on their website, and maybe some other way (for example, my key or fingerprint is on my personal website, bitcoinknots.org, bitcoin.org, and GitHub) .
If you have installed a copy of the software that you trust, sometimes it will contain the keys needed to verify updates (currently Bitcoin Core only contains the source code).
Check fingerprint of key file
To view the fingerprint of a key file, you can use the following command:
gpg –import-options show-only –import –with-fingerprint luke-jr.asc
This will output a lot of information about the key file, with the relevant information at the top:
pub rsa8192 2012-03-23 [SC] [expires: 2020-06-09]
E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
In this example, E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F is my key fingerprint.
NOTE: If GPG says the key has expired, that's probably okay! In step 2, you'll update to the latest version of the same key, which usually extends the expiration date.
Import verified keys
No matter how you verify the key, you should make sure to remember which key you used so that future updates can verify that the same key was used. Even if you skip the verify key step (which is insecure), at least this will ensure your updates have the same signer.
When you are confident that you have the correct key, you can import it like this (replace luke-jr.asc with the name of the file containing the desired key):
gpg –import < luke-jr.asc
Or if you only have fingerprints, like this (put in the fingerprint of the key you want to use!):
gpg –keyserver hkp://keyserver.ubuntu.com –recv-key E463A93F5F3117EEDE6C7316BD02942421F4889F
Step 2: Verify signature
Now that you know what key to use for verification, the next step is to check that the signature is valid.
Before proceeding with this step, you must ensure that your copy of the signer key is up to date. If you don't do this, you may get a message that the key has expired. Run (using your desired fingerprint):
gpg –keyserver hkp://keyserver.ubuntu.com –refresh-key E463A93F5F3117EEDE6C7316BD02942421F4889F
Next, (in addition to the program file you are checking) you will need two files: the ".assert" file containing the list of file fingerprints and the ".assert.sig" file containing the signatures of that list. This is because what we are doing is not signing the program files themselves, but fingerprinting all the files and then signing that list. Therefore, you need both files.
Bitcoin Core's "assert" file pair is posted here: https://github.com/Bitcoin-Core/gitian.sigs/find/master;
The "assert" file pairs for Bitcoin Knots are posted here: https://github.com/bitconinkots/gitian.sigs/find/Knots
Note that there is a separate file pair for each signer. If you are verifying whether multiple people signed your file (which you should), you need to check each file pair. Additionally, you need to make sure you are getting the version of the file you want to verify!
Once you find the file you want in the list, click the link to open the file in your browser, then right-click the "Raw" or "Download" button and select "Save Link As."
Once you have these two "assert" files, you can check the signature by running (adjust the filename to the specific .assert.sig)
gpg –verify bitcoin-core-linux-0.19-build.assert.sig
If this step is successful, you will get the next result:
gpg: Signature made Sun 19 Jan 2020 03:47:15 AM UTC
gpg: using RSA key E463A93F5F3117EEDE6C7316BD02942421F4889F
gpg: Good signature from “Luke Dashjr ” [ultimate]
Note that the key's fingerprint is shown in bold. The fingerprint must match the key you verified in step 1, otherwise it could be signed by someone else! The part about a "good signature" is also important, whereas the name and email address are not, both of which could be fake if the fingerprint is wrong.
Assuming all went well, you now know that the ".assert" file is guaranteed by the controller of said key, and can proceed to verify that your actual program file is the one listed in that ".assert" file.
Step 3: Verify the file itself
To authenticate a program file, it must first be cryptographically hashed (basically extract its fingerprint).
This is done with a simple command (be careful to replace the actual filename you are validating!):
Linux: sha256sum bitcoin-0.19.0.1.knots20200104-powerpc64le-linux-gnu.tar.gz
Windows: certUtil -hashfile bitcoin-0.19.0.1.knots20200104-win64.zip SHA256
macOS: shasum -a 256 bitcoin-0.19.0.1.knots20200104-osx-unsigned.dmg
This will output something like this:
d370692590c4546ac0de250da91c6c288d9ee5252f1a4b857a5b80c4e3d81149 bitcoin-0.19.0.1.knots20200104-powerpc64le-linux-gnu.tar.gz
This is the fingerprint of the file's contents, followed by the specified file name.
Now, open the ".assert" file in any plain text editor/viewer and look for the fingerprint. It should be in the "out_manifest" section at the top, if you reach "in_manifest" or "base_manifests" then you have gone too far.
If you find it in the ".assert" file, then you have verified that the file you have is the same file that the signer vouched for (you will see it in the ".assert" file to the right of the fingerprint their filename, which may be the same as yours).
And if it is missing from the ".assert" file, it may mean that you are using the wrong ".assert" file, or that your file is a mismatch (in which case you will see next to the expected file name to another fingerprint). If a file is listed but has a different fingerprint, please do not open the file, but save it (we may ask you to provide a copy) and contact the affected project's security team.