OpenVAS - Open Vulnerability Assessment Scanner

Preface:
It has been known for a while that storage solutions for Bitcoin, BSV have been more difficult for mainstream users. Since BSV is the real Bitcoin, it has been feared, hated, attacked, delisted, and has become a pariah in the “crypto” industry. The reason is because the true Bitcoin is light, and crypto is darkness, by definition. And there is nothing more terrifying to vampires than light.
The enemies of Satoshi and Bitcoin have landed heavy blows against us, we have been delisted from exchanges. We have been censored, harassed, slandered, DDOSed, and persecuted for being real Bitcoiners. Hardware wallets have dropped support for BSV, while mocking and attacking us, and playing dirty tricks and supporting thousands of scamcoins and illegal securities instead. Some BSV members still use these hardware wallets with electrumSV as a hack-a-round solution, but it is riddled with bugs and does not work well. Recently people had to downgrade firmware to make it work again. I don’t think it is a wise decision to hold BSV on a device run by a company that wants to sabotage Bitcoin. So my advice is lets de-list them instead.
No weapon forged against us shall prosper. At the end of the day, what does not kill us only makes us stronger. True Bitcoiners need to learn to adapt to the hostile conditions in this space. But I was somewhat horrified recently when I polled some twitter followers to find out that less than 1/3 of BSV investors are using secure storage for their Bitcoins, and over 2/3 of people are primarily storing their coins in exchanges or on phone/desktop wallets. Storing coins in hot wallets and on exchanges leaves them more vulnerable to theft and loss. Its time to take responsibility and get educated on how to store your Bitcoins properly. It will take a small amount of time and effort, but it will be well worth it.
When using cold storage you can achieve a much higher level of security than hardware devices. Also think of the risk to the BSV community and the Bitcoin economic system with so many people using hot wallets and exchanges for their investments. If a popular wallet or service has an exploit and everyone loses their coins it is going to really damage the Bitcoin ecosystem. Old-timers will remember the Mt.Gox hack and what that did to the perception of Bitcoin for years. In fact it was the narrative that “malleability” was the cause of the Mt.Gox hack that directly lead to the implementation of segwit on BTC and the destruction of satoshi’s vision on their system. They said we “needed” segwit to solve malleability. It was Mark Karpeles that shifted blame and said its up to Bitcoin developers to fix malleability, and everyone took the bait. Lets not repeat history. Also do not forget how much BSV is hated. Neck-beards, troll teams, dragon dens, shitcoiners, hackers, and criminals are working over time to attack BSV and they are well funded. Some of us who have been targets of their social attacks know this all too well.
So it is time we get educated and trained in how to be true Bitcoin users and put up our security defenses. Imagine how many investors would choose to invest more in BSV if they had a secure storage solution that they felt confident in. Imagine how many BSVers would sleep better at night if they just took a few hours to educate themselves about how Bitcoin really works and how to secure Bitcoins properly. What you will learn from following this tutorial is far more valuable than your monetary investment. I have always said the real investment is in knowledge and using Bitcoin yourself and understanding how it works and how to take charge by securing your own coins, financial future, and freedom. BTC hoddlers don’t know these things, they hold things on sketchy hardware wallets or exchanges, they trust others. But real Bitcoiners should learn how to trust themselves. What does the whitepaper say throughout, and in section 12? “We have proposed a system for electronic transactions without relying on trust.”. Taking trust out of the equation is part of the essence of being a true Bitcoiner.
Lets Begin:
Now there are many ways to store Bitcoins securely, and no way is necessarily right or wrong. Every method has pros and cons. Remember there is no such thing as 100% security. Encryption and security is probabilistic. Things can be too secure also, like if you make the password too hard and then forget it. When deciding how to secure your Bitcoins, learn to take the details of your own situation into consideration. For example if storing large amounts, you probably should have more precautions and safeguards in place.
One simple way to store coins in cold storage is as Craig Wright has suggested, using an offline phone. This can be a simple, quick and effective solution. There is also an option with simply.cash for example to set the wallet up on two phones, one to store your keys and the other to broadcast transactions. But that is not the tutorial here. We will rely only on open source, time tested tools, and our own knowledge and common sense. The goal is to have a security solution that you feel confident enough in to hold your savings and investment for long term, with easy access when wanted.
Tutorial:
Some of the credit for this tutorial goes to Krisov Atlas, a security and Bitcoin privacy researcher, and his video tutorial from 7 years ago which can be watched here. He has done some good work including exposing how blockchain.info’s mixing service was flawed in terms of privacy. The video is a little outdated and not tailored for BSV, and has some difficult parts, so the goal is to improve upon it and make the chore of learning cold storage much easier.
The goal here is to create Bitcoin private key/public address pairs in a cold storage environment and then be able to optionally store the private keys on a LUKS encrypted USB drive that is password protected. Then the private keys are able to later be “sweeped” or imported at your desire into a BSV hot wallet for use. You will be able to send coins to and from your cold storage whenever you want, using a smaller hot wallet for spending. This way you reduce your risk. If coins are ever lost or stolen from your hot wallet, you only lose a small amount of your total holdings. When coins run out you can top off your balance by sweeping some private keys from cold storage.
Items you will need:
The items you will need for this tutorial are a laptop computer and several USB drives. The more USBs the better so you can back up your keys multiple times in case the drive somehow fails, gets corrupted or gets lost. The USBs don’t have to contain very much space, even a 4MB or 8MB drive can be useful for our purposes. Some of the drives will have to be formatted and wiped during the process so they should be empty. The other items that you will need are the digital files that can be found in links throughout the tutorial.
Creating boot-able USB drive:
The first step is to create a boot-able operating system on one of the USB drives. We are going to use it along with your laptop to create the cold storage environment needed to create secure Bitcoin keys. The reason we use the boot-able device is because this way the keys will never exist on your hard drive. It defeats the purpose of cold storage if you create them on your hard-drive and then later connect to the internet and surf around. Once you connect to the internet there is no way to guarantee the private keys were not somehow broadcast to attackers/hackers/eavesdroppers. If you already know how to create a boot-able drive you can skip ahead.
To create the bootable operating system on the USB drive, I am recommending to use the open source Linux Ubuntu operating system. The latest version of Ubuntu is Ubuntu Desktop 20.04 LTS and can be downloaded here. You can choose other versions if you prefer, this tutorial works well with Ubuntu version 18.04 as well. What you are downloading is called an “iso image” and it is a .iso file with the image of the Ubuntu operating system used for installation or trying out the OS. We aren’t going to install the OS on your hard-drive, we are simply going to “try ubuntu” and test it out from the USB drive. This way nothing goes on the hard-drive, everything exists in memory and when the system is shut down any traces of the keys are basically wiped. This is one of the most secure ways we can create keys.
So there are several ways to create the boot-able USB drive. Here is a tutorial for MacOS. Here is a tutorial for ubuntu. I will provide an easier way to do it on linux below. Here is a tutorial for Windows using a tool called “rufus”. I have not used this tool before, but I am sure it works fine for Windows users if you prefer to follow that tutorial. Otherwise I suggestt the tutorial below for windows users.
For Windows Users:
I suggest windows users create the boot-able Ubuntu USB drive using the Universal USB installer found here. Also you are going to need the Ubuntu .iso file also linked here and above (Click the download tab and then its 20.04 LTS, the green button). It may be helpful to keep all of these files on one of your USB sticks for future use, be aware the .iso files are pretty big files, over 2GB. It may also take some time to download.
Once you download these two files, first plug one of your empty USB drives into your computer. This is the USB we are going tot make into a boot-able Ubuntu drive. A 4MB drive will probably work, but an 8MB drive may be needed in the future as the .iso files are getting bigger. Then go ahead and launch the universal usb installer. Click “I agree”, then you can fill in the form with details. From the first drop down select “Ubuntu” in Step 1. Then click the “browse” button in step 2 in order to locate and select the Ubuntu .iso file you downloaded. It should be titled “ubuntu-20.04.1-desktop-amd64.iso”. Double click to select it. If you use other flavors or older versions of Ubuntu this tutorial should work fine also. In step 3 select the empty USB drive you just plugged in. You may have to click the box to show all drives. Make sure you select the proper drive so you won’t erase the wrong drive by accident. Click the box that says “Will Fat32 Format Drive”, then also click the box that says “Will wipe”. For step 4 leave the persistence at 0 MB, we don’t want that feature since it could be bad for security. You should see the options as labeled in this image. Then you can click “create” and wait for the Ubuntu operating system .iso image to be imprinted onto the USB drive, it should take several minutes, do not unplug the drive or power off your machine. An 8MB drive is probably sufficient for this purpose, but it will probably work with a 4MB drive also, anything bigger is extra.
For Linux users: Now if you were using linux or ubuntu already and want to create boot-able drives you can just use the disk utility option. Click on the bottom left start menu, and then type in “disk” until you see the disk utility icon show up and click it, you will see a screen like this. Now plug in your blank USB drive and it will appear in the disk utility list. Find it in the list and make sure you select the proper drive and then click the button with 3 dots on the top right and then click “restore disk image”. Then it asks you to select the image to restore, you want to select the Ubuntu or other .iso image of your choosing then click “start restoring”. It will take many minutes, once complete, the USB should be ready for booting.
Booting into the USB ububtu OS:
Once finished we are ready to go on to the next step which is booting the laptop into the USB Ubuntu operating system. This part is probably the trickiest part of the tutorial because everyone’s system is different. The first thing you can do is power off your machine. Then plug the Ubuntu USB drive into the computer. Then press the power button to boot the system and see if the system will automatically boot into ubuntu. There is a good chance it will, but also a good chance it won’t work and you will boot into your main hard-drive or operating system as usual.
So if Ubuntu succeeded in booting you can skip ahead. Otherwise we will try again, so go ahead and power off the computer again and plug in the boot-able USB. But this time when we reboot we will try to enter the BIOS menu on boot. Every computer has a BIOS menu where you can select boot settings. On most computers you press and hold the F12 key while booting, sometimes it is a different F key, or on some sony laptops it is the “assist” key that allows you to get into the BIOS menu. With a little research you can probably figure it out for whatever model laptop you are using. Once you get into the BIOS menu, you will most likely see a blue screen like this.
Use the tab button/arrows, or mouse and the space bar to navigate to the “boot” tab. Then you want to make sure boot options will enable you to boot into USB. So check to see if “external boot device” is enabled. If it is “disabled”, navigate to it and change it to “enabled”. Also look at the “boot priority”. You want to make sure “external device” is the number one priority, otherwise it will prioritize booting from your hard-drive. So use the tab key and space bar to rearrange the order of the boot priority list so external boot is on top. The other option you may have to switch is “boot mode”, you may have to change this from “UEFI” to “legacy” mode to get the USB to boot on some systems. You can experiment with both UEFI and legacy mode, restart and see if it will boot into the Ubuntu USB drive. Don’t worry about screwing your system up with the BIOS settings, it won’t harm anything. You can always boot back into BIOS and change the settings back when you are finished if you have trouble booting into your regular operating system later. A trick is to snap a photo with your phone so you can remember what settings to put them back to. If you want to boot back into your hard drive just make sure the Ubuntu USB media is removed first.
So once you successfully get Ubuntu to boot, you will encounter a screen like this. You don’t want to install ubuntu on your main hard-drive, so press the “try ubuntu” button instead, this will allow you to try the Ubuntu OS on the USB device without installing it on your hard drive. After pressing the button the operating system will boot and you will see a desktop like this. If you wanted to connect Ubuntu to the internet on the top right you could then start surfing around the internet using firefox browser from the sidebar. But we won’t do that because we want to keep the environment cold and never connect the internet. Make sure your computer is not plugged into any ethernet cables. Also if you have an external switch for wifi or bluetooth make sure to turn it off manually.
We have now for the most part created the cold environment. As an added precaution go to the top right and click the little downward white triangle. You will see it say “wifi-not connected” which is good for our purposes. But for added safety go ahead and select the option to “Turn off” wifi. Then underneath this it shows blue tooth connections and says “on”. Now select the option to turn blue tooth off as well. Now it will show you that airplane mode is on. Once you see that airplane icon in the top right you know you are good and a cold environment has been created. Now it is safe to begin the process of generating your Bitcoin cold storage keys, although first we will set up a few things.
Creating a LUKS encrypted USB drive on linux/Ubuntu:
You have the option in Ubuntu to create a LUKS encrypted device that is protected with a password. LUKS stands for “Linux Unified Key Setup” and is the standard for disk encryption on linux. To do this is pretty simple, first you need an empty dedicated USB drive. We will use Ubuntu to encrypt the entire drive. You will need the password to unlock the drive or write to/access files on the encrypted USB drive. If you are not interested in storing your coins on an encrypted drive you can skip ahead.
The first step is to plug in the empty USB drive into Ubuntu, it will be formatted and wiped in the process. Then open the disk utility feature in Ubuntu, by clicking the start menu on the bottom left of the desktop](https://i.imgur.com/gCfHKcZ.png). Type in “disk” and you should see the “disks” option pop up. Now click it and you will see the disk utility screen. Make sure to select the correct drive that you plan to encrypt with LUKS, otherwise you might erase the wrong drive by accident. If you have trouble figuring out which drive it is, eject and then re-plug the empty USB into your computer and you will see it disappear and reappear from the menu.
The next step is to click the button with the 3 dots on the top right of the Disks window. You are given the option to format disk, create disk image, or restore disk image.. Choose the “format disk” option. You have the option to overwrite the USB with 0s to wipe it, but it will take longer, maybe many minutes or even hours depending on the size of your drive and your system. Otherwise it will still erase the contents during formatting, but the contents may still be easily recoverable forensically. But this option is much quicker to setup. Security wise, it probably makes sense to be more paranoid and wipe the drive. So choose the options in the dropdown. In the other dropdown you can choose “no partitioning (empty)” Then click the “format” button. It will ask you if you are sure you want to format the disk, then click “format” again.
Once finished with the initial format, we are going to set up the LUKS encrypted volume with password. Click on the button with the two small gears for additional partition options. Then click “Format Partition” and you will see this screen. Now you can put in a name for your encrypted volume, here I chose the name EncryptedBitcoinStorage. Again you have the choice to erase/wipe the drive with 0s, but be aware this will take longer. Then under “Type”, select “Internal disk for use with Linux systems only (Ext4)”. Also check the box that says “Password protect volume (LUKS)”. The encrypted disk will be compatible with other linux systems, but probably not with windows. So to access the drive later you will need to boot back into linux/Ubuntu. Click “next” and you will see this screen where you will put in the password used to unlock the encrypted volume.
Side note: If you forget the password, the coins may be lost. So it is up to you if you want to choose a very easy password, or you can put a hard password that makes it more secure against theft. A password that uses many random characters including capital letters, small letters, numbers and symbols makes it more secure. Real words make it more guessable but easier to remember. If hackers get the drive they will be able to use software to try and brute force the password, so keep that in mind. You can decide to write the password on paper, which protects against forgetting it, but opens up a new avenue for theft. You can try to remember the password and not write it down, but there is a chance you will forget it later. It might be worth to share the password with someone you trust. Those decisions are something everyone has to make for their own unique situation.
After you put in the password, select “Next”. It will ask you to confirm details, and then you can press the red “Format” button. After many minutes or hours depending on your system and size of the drive (more if you chose the “erase” option during setup), it will encrypt the device with some open source encryption algorithms. Be patient for it to finish. Is it perfect encryption? No, there is no 100% secure encryption, but to learn more about LUKS and some of its strengths and weaknesses this blog is an interesting read.
Now your drive should be encrypted and setup and ready to go. To test it click on the folder icon seen on the left sidebar of ubuntu, find the drive, it should be named by the title you gave the drive, right click to eject or safely remove drive. Then wait a few seconds and plug in the drive again and Ubuntu should automatically ask you for your password, type in your password and click “ok” to open the drive. If all went well it should work successfully and you can now load private files into the USB drive. Another thing you might want to do is right click on the drive and click “properties” and then click the permissions tab so “others” will be able to read and write to the file and access files. Next to “Owner” “Group” and “Others” make sure the drop down says “create and delete” files if possible. Don’t change anything else. Then click the button to “change permissions for enclosed files”, and you will see this screen. Select “Read and write” and “create and delete files” from each of the dropdown menus. Then click the “change” button. This way if you unlock the USB on a different linux system it won’t tell you that you’re not the owner and block you from reading or writing files which can sometimes happen on other linux distributions like TAILS for example.
Generating Bitcoin Keys With Core software:
Now we get towards the part where we are able to confidently generate secure Bitcoin private keys and public addresses in the cold environment. To generate keys there are many different options. There are some hardware wallets like Ellipal wallet for example that work for BSV but only allow you to have one key and one address. This is not ideal. Satoshi in the whitepaper tells us in section 10 titled Privacy: “a new key pair should be used for each transaction to keep them from being linked to a common owner.”. Other wallets are called “HD” wallets or hierarchical deterministic wallets because they derive keys from one master key or seed. Wallets that you see with seed phrase backups are HD, for example electrumSV and many phone wallets.
These are probably safe for the most part, but HD wallets do have some unique vulnerabilities by linking all addresses and keys in such a way. If an attacker gets ahold of even one of your private keys along with your master public key which helps wallets derive your addresses, then the hacker could use a math equation to steal all of the rest of your keys in that HD wallet. Something called “hardened” HD keys are supposed to help prevent this, but I rather avoid HD wallets altogether if possible. For that reason I am not recommending HD wallets as the #1 recommended method here, although if you use them and understand the risks it may not be a bad option. One benefit to using an HD set up is you can write your seed words on paper, with our method you can’t do that, although you could print paper wallet QR codes.
Now we have a few good options for when it comes to using non-HD and generating Bitcoin keys. It is important to use time-tested open source generation methods. There have been instances where wallets had a poor implementation and flaw when generating addresses. This resulted in keys that were not secure due to bugs in the entropy/randomness needed for good cryptographic security, so hackers could easily guess the keys or generate them themselves, or users would accidentally generate the same addresses.
For this reason the first program I would recommend for generating keys is the Bitcoin Core software. The SV client team has moved away from supporting the QT wallet for regular users and they are more focused on providing software for miners and enterprise businesses. So using Core to generate keys is probably the best option for regular people. The Core client is the oldest software with the most eyes on it. If there were bugs in key generation they probably would have been found by now. To use Core, it is best to go back in time to before Bitcoin Core implemented segwit as well as HD wallets. Bitcoin Core Version 0.13.0 introduced mandatory HD wallets, and version 0.16.0 introduced "full support" for segwit. Now in the newest Core versions, segwit is default and you can't even create a legacy address without altering the bitcoin.conf config file using the “addresstype=legacy” argument, or by using the debug console and command “getnewaddress legacy”. If you send your BSV real Bitcoins to segwit addresses they could be lost, so always make sure your addresses begin with a “1” and you will know you are for sure not using segwit.
You can find some of the old and new core versions here. To avoid HD wallets and segwit altogether, I recommend going back in time and using version 0.12.0 of the Core software which can be downloaded here. Download and save the “bitcoin-0.12.0-linux64.tar.gz” file to one of your USB drives for future use. This version of the software was before HD wallets were introduced in Core and before segwit was default in Core software. Don’t think of it as using Core software, think of it as going back to dig up and salvage a piece of software designed by Satoshi and those helping him before Core destroyed Satoshi’s Vision on their client.
Verifying/Installing/Running Core:
If you want some extra reading you can check out the /bitcoin tutorial for verifying Core here. This won't exactly work for us, since we are verifying the old Core software version 0.12.0, not the new Core version.
So we just downloaded Core software 0.12.0, but how do you know the file is the real file and not a fake one interjected by a hacker in some type of man in the middle attack? This is very unlikely, but the only way to know for sure is to verify the hash of the software. To do this you are going to boot back into Ubuntu with the Core .tar.gz file ready to be grabbed from one of your empty USBs. Once booted into Ubuntu, follow the procedure from above to turn off the internet/bluetooth and put ubuntu into airplane mode. Then plug in the USB with the Core software file, and copy paste the.tar.gz file to the Downloads folder directory. You can navigate there by clicking the folder on the left side bar. The file is already zipped so leave it that way until we extract it with a special command.
The next step is to open the terminal command line interface for Ubuntu. To do this click the start menu on the bottom left and search for “terminal”. Then click the terminal icon to launch the terminal. The terminal should then popup like this. Since we pasted the .tar.gz file into the Download directory earlier, type in the command “cd Downloads” into the command interface and press enter to switch to the “Downloads” directory like this.
In the next step we are going to start to verify that the software we are using to generate keys is legit. If you don’t want to do this step now, you can skip ahead to the “launch Core” section and just run Bitcoin Core now.
Otherwise we will begin to verify the software by first doing the following command in the terminal while still in the Downloads directory:
sha256sum bitcoin-0.12.0-linux64.tar.gz
Then press enter, and you should see this output. What Ubuntu has done is take the data in the Core file and hashed it using sha256 and it has returned the sum: ad97b28524d4f64f06549fb7d0ca45cfaa0f35090cf230cd80f3ad8cb8eaf9bd
Every valid Core software for linux64bit should have the same hash sum result. What I mean is the linux 32bit version has a certain hash, the linux64bit version has a different hash, the windows version has a certain hash. But no matter where you download each specific version, when you hash it you will always get the same number output. If the file was altered in any way it would not hash to the same number. The way we can tell the software is legit is by comparing this hash to known signatures from the Core developers, in this case Wladimir Van der Laan, BlockStream’s patsy and the Core gatekeeper of the github repo. Here is a copy of the signature for the hashes for the Core 0.12.0 software for a variety of systems. The signature can be downloaded from bitcoincore.org here. Just click and download the “SHA256SUMS.asc” file, which contains the following signature:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
42cee702ece98d5bd488c6f231a07dfa0299f3e4010d6f76f021a8a432a48ed7 bitcoin-0.12.0-linux32.tar.gz ad97b28524d4f64f06549fb7d0ca45cfaa0f35090cf230cd80f3ad8cb8eaf9bd bitcoin-0.12.0-linux64.tar.gz 27bc1876de6fbfc635bf0908d8fb038fe61be7188b067786b7d41f4802a20f6c bitcoin-0.12.0-osx64.tar.gz 0c7e0791934800c7f8e218e29b4fe53a9356a23996dd5dcdf4c64f8e61e45015 bitcoin-0.12.0-osx.dmg 0f1cda66c841a548a07cc37e80b0727354b1236d9f374c7d44362acdb85eb3e1 bitcoin-0.12.0.tar.gz 939a7bde3f2583e2357e417d12af3193cda7cc2bb094c8f6278959a117726ccd bitcoin-0.12.0-win32-setup.exe ff74a60ae29c94fdbb11189a81191ca3b28534589e7febff3a9d45a2f9d5bed1 bitcoin-0.12.0-win32.zip fab68debc8c615ef23c4d9abec02882bf1f901faea5db4bca054d4f6323b3cc4 bitcoin-0.12.0-win64-setup.exe f0fb4b74adbeeb1f6da570cede9949b53092e0df00e4628c47661ef9edd1aced bitcoin-0.12.0-win64.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJWzDasAAoJEJDIAZ42wulkjX4P/0RSVxLoUEPCjXMbBVNJhyME oLczF3kjrYxyJKpiImeTDFEVt0QzLi30gzbUBjfcS4sk5KY/GEa8fmZgz9wPsRnw SZGZqgZ0+ZB3aIQd4WLRzAPizxCADgCcIef8qXItl0XxqkFIR4iesIrxque3j0qm /VDi67JLdZdKHbxBCuE2I7f2fIpCOVn3WnU2OjAWSUeQGxWYCb8yalO3K4H3LP/0 Y/aRH6J8/eYk1UeENBOcC/vqga6pe0KgJlCZjRJXq6ASsukXLTX/43mz0hSGvq/N C3y9AqJkcwGI3VmOpVMq1J+supHn1YsDMba79AIlNqvpuDSyeKr3gq8m0efZklOu dCAUenTu0tqzFDZbEbLRh/P0woijnGJ5Ajh5MAJ343C3rtS72MJTwoD3sI9JpVO/ xX4l/JDYs1lujfSz4RLzH+s13zaKsPYbVkhlPZnCmyyxTPhcw+c9xPs9xTH7Dwfi NlTBm0hWbXXedHdkvR2LVLzeFytrAWBbsaAMb94KfmiwwGoJ3o1Sjt/AzIAPe4C+ CZH+nfUEnREIpYRFCkhiQyk6zsOsi6Il9UyHtb+XOsP7yna0r09ZpEV0XPGzMlo/ EjevjsXZTFexjzeFTEqkQ5KdrVos94Z50uZ8Lm+yhX6VIcxSrNofmMLvOePeq6DU fH3xoer3Ia9BcvVkC915 =CKUR -----END PGP SIGNATURE-----
It can also be downloaded from bitcoin.org here. I have also loaded the signature to the Bitcoin (SV) ledger here, where it can be downloaded, and is immutably time stamped so that it cannot be altered. It is good to verify the signature and hash from multiple sources. As you can see, the hash we saw in our command interface matches the one in the signature for bitcoin-0.12.0-linux64.tar.gz, you will see the hash “ad97b28524d4f64f06549fb7d0ca45cfaa0f35090cf230cd80f3ad8cb8eaf9bd” included in the signature. Now that is pretty good proof already that the file is legit, but to be 100% sure we would then verify the authenticity of the signature using Wladimir Van der Laan’s public key seen on reddit here. Also you can download his same public signing keys from bitcoin.org, direct link here. You can also find Wladmir’s same public signing key on GitHub. I have also etched some websites forever onto the Bitcoin blockchain where they are immutably time stamped. Here the reddit page with Wlad’s key is etched onto BSV. Here is Wlad’s key on github etched onto the Bitcoin ledger. It is good to verify it from multiple sources to know it is legit. I will try to paste it in the comments below for redundancy (it is a ridiculously long key).
Now we have Wladimir’s signing key and the signed message that includes our matched hash “ad97b28524d4f64f06549fb7d0ca45cfaa0f35090cf230cd80f3ad8cb8eaf9bd“.We can use PGP/GPG software to verify the signature is good. To do this I would recommend using gpg4usb. Another option you can try is pgp4win, or other PGP software of your choice.
Simply download the gpg4usb file, then locate the file on your computer, most likely in your download folder. Then right click the file and choose to extract the contents. The software is also designed to be used on USB with a variety of different systems if you prefer. After extracting contents you will see these files. If on windows click the key icon to “start windows”. Click “run” and then you will see this launch screen. Now simply import Wladimir’s key by first copying Wlad’s public key block to the clipboard and then clicking the “Import Key” button and selecting “clipboard” from the dropdown. This should import Wlad’s key as seen here. Now copy the signed message we intend to verify, and paste it into the text document within the gpg4usb software like seen here. Then simply click the button that says “verify” at the top with the green check and it will tell you if the signed message is legit or not. Here it verifies the signature and says “Text was completely signed by: Wladimir J. van der Laan”. So at this point we have completely verified the signature and the hash of our Core software and we can trust that it is legit.
Running/Launching Core:
Now that we have verified the software we can launch Core by going back to the terminal command line interface. You should still be in the “Downloads” directory. If not then go there by typing “cd Downloads” and press enter. The next command is to type/paste the following:
tar xzf bitcoin-0.12.0-linux64.tar.gz
Then press enter. The above command will extract the files from the .tar.gz file. Make sure to do this from the command line as it uses the “xzf” argument which is important.
Next type the following command also in the downloads directory:
sudo install -m 0755 -o root -g root -t /uslocal/bin bitcoin-0.12.0/bin/*
The above command installs the Bitcoin Core software, getting it ready for use.
Now while still in the download directory, to run/launch Bitcoin Core simply type the command:
/uslocal/bin/bitcoin-qt
And press enter, and you should see Bitcoin Core QT client pop up like seen here. We won’t be worrying about downloading any blockchain so just press “ok” to continue and Core will launch as seen here. If you see a message about an expired alert key just ignore it. Now that Core is fully installed, any time you want to run Core again just open the terminal and type “cd Downloads” to change to the Downloads directory, and then type: /uslocal/bin/bitcoin-qt and Core should launch.

It's important to understand sexual consent because sexual activity without consent is sexual assault. Before you flip out about how "everyone knows what consent is," that is absolutely not correct! Some (in fact, many) people are legit confused about what constitutes consent, such as this teenager who admitted he would ass-rape a girl because he learned from porn that girls like anal sex (overwhelmingly not true, in addition to being irrelevant), or this ostensibly well-meaning college kid who put his friend at STI risk after assuming she was just vying for a relationship when she said no, or this guy from the "ask a rapist thread" who couldn't understand why a sex-positive girl would not have sex with him, or this guy who seemed to think that because a woman was a submissive that meant he could dominate her, or this 'comedian' who haplessly made a public rape confession in the form of a comedy monologue, or this 'well-liked kid' who thought good girls always had to fight a little the first time. In fact, researchers have found that in acquaintance rape--one of the most common types of rape--perpetrators tend to see their behavior as seduction, not rape, or they somehow believe the rape justified.
Yet sexual assault is a tractable problem. Offenders often rationalize their behavior by whether society will let them get away with it, and the more the rest us confidently understand consent the better advocates we can be for what's right. And yes, a little knowledge can actually reduce the incidence of sexual violence.
So, without further ado, the following are common misconceptions about sexual consent:

• An overwhelming majority of people require explicit (i.e. unambiguous) consent for any sexual activity beyond kissing in a new relationship. However, even an unwanted kiss can be fatal if the person being advanced upon feels unsafe due to a large discrepancy in size/strength.
  
• "Token resistance" to sex is virtually nonexistent, particularly for first encounters. The overwhelming majority of men and women who say no to sexual advances really do mean no. It's never reasonable to assume that when someone says no, they don't really mean it (unless you have previously mutually agreed to role-play and have decided on an alternative safe word, in which case it's not an assumption) even if the person has sent extremely "mixed signals," or even engaged in some sexual contact (as many sexual offenses often entail).
  
• As in other social interactions, sexual rejections typically are communicated with softened language ("Next time," "Let's just chill," "I really like you, but...") and often don't even include the word "no." These rejections are still rejections, and any subsequent sexual activity is still sexual assault. Both men and women are capable of understanding these types of refusals, and to pretend otherwise is disengenuous. Perpetrators often misrepresent their own actions to garnish support, avoid responsibility, blame the victim, and conceal their activities, and re-labeling sexual assault or rape as a "miscommunication" accomplishes those goals. It may not be a good idea to recommend to someone that they try to communicate more forcefully, because like domestic abusers, rapists often feel provoked by blows to their self-esteem, so encouraging someone to communicate in ways that are considered rude could actually lead them to danger. Sex offenders are more likely to be physically violent, and 1 in 4 women and 1 in 7 men has experienced severe physical violence by an intimate partner, so it is far from outrageous to take precautions against physical violence by being polite.
  
• Most young women expect words to be involved when their partner seeks their consent. 43% of young men actually ask for verbal confirmation of consent. Overall, verbal indicators of consent or nonconsent are more common than nonverbal indicators. More open communication also increases the likelihood of orgasm for women.
  
• Consent is not synonymous with arousal. For one, there are common misconceptions that an erect penis or erect nipples necessarily signify sexual arousal. It's also possible for someone to be aroused and still not want to have sex. Women often have a physiological sexual response to sexual stimuli that is independent of desire, and that may serve a protective effect against injury from unwanted sex. Misperception of sexual interest may increase risk of sexually coercive or aggressive behavior, and studies consistently show men perceive women's actions to be more sexual than the woman intends (93% have misperceived sexual interest on at least one occassion, though most correct their understanding before engaging in nonconsensual sexual contact). Men who date women are less likely to accurately label sexual assault when the victim's interest is even a little ambiguous. If the victim has an orgasm, that does not retroactively mean the sex was agreed to. Relatedly, one of the most common reasons women fake orgasms is to end unwanted sexual encounters. Sex with an aroused person who hasn't consented is still sexual assault.
  
• Consenting to engage in some sexual activity does not imply consent for further sexual activity. The kinds of sexual behaviors one finds appealing is highly individualistic. The law is clear that one may consent to one form of sexual contact without providing blanket future consent to all sexual contact, yet most sexual assaults happen during a hookup when a man forces a higher level of sexual intimacy than the woman consented to. Most women do not achieve orgasm during one-night stands, and are less likely to want to engage in intercourse as part of a hookup.
  
• Physical resistance is not required on the part of the victim to demonstrate lack of consent, nor does the law require evidence of injury in order for consent to be deemed absent. Women who try to physically resist rapes are more likely to end up physically injured, while those who try to argue or reason with the offender are less likely to be injured. The increased probability of injury may be small, but the consequences serious.
  
• Consent can be legally communicated verbally or nonverbally, and must be specific to engage in the sexual activity in question. Behaviors which don't meet the bar for communicating explicit consent for a particular sexual behavior (like accepting an alcoholic beverage, going to a date's room, kissing, or getting undressed) are at best indicators of likelihood for future consent.
  
• Nonconsent can legally be communicated verbally or by pulling away or other nonverbal conduct.
  
• Submitting to sex is not legally the same as consenting to sex. Some sex offenders kill their victims to avoid getting caught; victims often become compliant during an assault as a protective measure.
  
• It's possible for someone to be too intoxicated to give valid consent. Contrary to popular belief, alcohol is not an aphrodisiac. (in fact, sober sex tends to be more wanted and enjoyable). Most college sexual assaults occur when the victim is incapacitated due to intoxication or sleep. Deliberately getting a victim too drunk to resist is a tactic used by some perpetrators to commit sexual assault or rape. If someone is blackout drunk, it's a good idea to assume they cannot consent to sex. Here are some easy ways to tell if a person is blackout drunk.
  
• Intoxication is not a legally defensible excuse for failure to get consent. Heavy alcohol consumption increases the risk of sexual offending in certain high-risk men. Intoxicated men who are attracted to a woman are particularly likely to focus their attention on signs of sexual interest and miss or discount signs of disinterest. Intoxicated predators will also often pick out victims they know to be impaired by drugs or (usually) alcohol and make them have sex even when they know them to be unwilling. If intoxication were a legally defensible excuse, rapists would just have to drink heavily (or claim they were drinking heavily) to get away with rape.
  
• Wearing someone down by repeatedly asking for sex until they "consent" to sex is a form of coercion. Some forms of coercion are also illegal in some jurisdictions. Genuine consent must be freely given, or a human rights violation has occurred.
  
• Silence is not consent. Fighting, fleeing, and freezing are common fear responses, and thus not signs of consent. In fact, most rape victims freeze in fear in response to unwanted sexual contact, even though most rapes are committed by someone known to the victim.
  
• It is necessary to obtain consent from men, too, as men are not in a constant state of agreement to sex.
  
• Consent must happen before sexual contact is made, or a violation has already occurred. Legally, sexual contact that takes a person by surprise deprives them of the opportunity to communicate nonconsent. There is often a long period of uncertainty described in victim's rape accounts where she felt shocked by the rapist’s behavior and unsure of what was transpiring. In fact, most unwanted fondling, and many rapes, occur because the victim didn't have time to stop it before it happened. Most victims also become compliant during an assault, which is a protective behavior that does not signify consent.
  
• Consent is ethically and legally required before removing a condom. STIs are on the rise, many people are unaware they have an STI they can transmit to a partner, there is an antibiotic-resistant strain of gonorrhea on the rise that could literally be fatal, there is no reliable HPV test for men, and herpes might cause Alzheimer's. It's simply intolerable in a civilized society to knowingly expose someone to those risks without their knowledge or consent.
  
• The NISVS includes using lies or false promises to obtain sex in their definition of sexual coercion. For example, pretending to be someone's S.O., pretending to be a celebrity, lying about relationship status or relationship potential are all forms of sexual coercion that cross the line.
  
• Marriage is not an automatic form of consent. While couples who have been together for awhile often develop their own idiosyncratic ways of communicating consent, laws of consent are just as applicable within a marriage. Marital rape is one of the more common forms of sexual assault, and may more often be about maintaining power and control in a relationship, rather than sexual gratification like other forms of acquaintance rape. The physical and psychological harm from marital rape may be even worse than stranger rape, for a variety of reasons.
  
• Consent is at least as important (and just as required) in BDSM relationships. It's true that sexual fantasies involving dominance and/or submissions are somewhat common; however, even 'rape fantasies' (which would more accurately be called "ravishment play," snce no one actually wants to get raped) must be carried out within the context of mutually agreed-upon terms. It's never reasonable to assume that a particular person A) wants to be dominated B) by a particular person C) at a particular time. Sexually dominating a kinky person who hasn't consented is still sexual assault.
  
• Most rape victims are in denial, sometimes for years, after an assault. Finally acknowledging there was never consent is not "regretting" consensual sex. Regret is a virtually non-existent reason for false accusations.
  
• Affirmative consent is generally required on college campuses, (and a growing number of legal jurisdictions). For examples, have a look at Yale's sexual misconduct examples, Purdue's consent policy, Illinois', Michigan's, Harvard's, Stanford's, Wisconsin's, Minnesota's, Wyoming's, Indiana's, or Arkansas' university policies on sexual consent (or California's, Canada's, Spain's, Sweden's, etc.). A requirement for affirmative permission reflects the contract-like nature of the sexual agreement; the partners must actively negotiate to change the conditions of a joint enterprise, rather than proceed unilaterally until they meet resistance. Logically, it makes much more sense for a person who wishes to initiate sexual activity to get explicit permission for the particular sexual activity they would like to engage in, rather than the receiving party having to preemptively say "no" to the endless list of possible sexual acts.
  

If all of this seems obvious, ask yourself how many of these key points were missed in popular analyses of this viral news article.
​
^{EDIT: typo}