The version number was not reset to 0.1. It kept increasing. After 0.9 was 0.10, then 0.11, etc. Notice how there is no dot (.) between the numbers. It is a higher number. It is highly unlikely that there will ever be a 1.0 release because that would indicate some level of finality, and we don't want that nor can we agree at what point should there be a 1.0 release. Right now it seems that we might just keep incrementing that middle number to infinity. I am in favor of just dropping the 0. in front of the version number or changing our version number scheme to the one used by Ubuntu (2-digit year followed by 2-digit month for the year and month that the release was made).

First of all, the blockchain is more than 20 GB, it is around 150 GB now.

Secondly, how software finds data in the blockchain is all up to their implementation. There is no singular standard way to look up blockchain data. Most software use a similar approach though, and what I will be describing is how Bitcoin Core does it.

Bitcoin Core maintains a database separate from the blockchain which contains all of the unspent transaction outputs. This database is updated when blocks are found; outputs that are spent are removed from the database and new outputs that are created are added to it. When a transaction is received, the outputs that it spends from are looked up in that database so that the transaction can be verified. There are no balances, just unspent transaction outputs and a node will look up the outputs that a transaction spends from.

For sending Bitcoin, your wallet maintains its own database of your transactions. It maintains a database separate from the blockchain which contains the transactions and outputs that pertain to you. When you want to spend, that database is read and the outputs that you are spending are chosen from that database.

It sounds like what you want to use is OP_CHECKSEQUENCEVERIFY which is specified in BIPs 68 and 112. Using this requires using P2SH and it allows you to say "this output can only be spent after X amount of time/blocks".

That post is wrong. 0.15.0.1 is signed with a valid certificate.

Do it anyways. You may not think that it is relevant, but it does show us where Bitcoin Core is when it crashes. Same with the debug.log file. Post it anyways. Giving us more information will allow us to diagnose the problem faster, even if you think it is irrelevant.

Post it anyways. Just because you can't see something wrong there does not mean that there is nothing wrong. Often times people will overestimate their ability to understand the log files and miss the actual error. Post the entire thing.

0.1.5 is not the very first release. 0.1.0 is, and 0.1.3 was released shortly after 0.1.0. There is almost no difference between 0.1.0, 0.1.3, and 0.1.5. Why do you want specifically 0.1.5?

If we assume that all of those websites are using the same settings for AES, the reason that the ciphertext will be different is because of the way that the encryption key is derived. For encryption, they don't actually use the string that you give them as the actual key itself. Encryption software will actually take that passphrase and run it through a key derivation function (kdf). Often times they will also combine it with a randomly generated salt. The output produced may also include that randomly generated salt with the actual ciphertext tacked onto it (or vice versa). AES is just an encryption standard, it does not specify what kdf to use, whether to salt it, etc. So all of the sites and software you have been using are likely using different kdfs with randomly generated salts and storing that data differently in the output which means that the output will be different for every single software.

If you want to have something that can be used across multiple software, use PGP. Note that with PGP you still may not get the same encrypted result when you encrypt the same thing multiple times because PGP also introduces randomness when encrypting (IIRC the actual encryption key is random; PGP encrypts a random encryption key which is then actually used to encrypt your data). PGP includes a whole protocol around what kdfs are used, what hashes are used, what encryption algorithms are used, etc. and that is all standardized. This means that you can encrypt with one software and be able to decrypt with another software.

No, that is incorrect. Long does not necessarily mean secure. Password crackers are not stupid, they aren't going to just brute force your password one character at a time; they are going to use dictionaries, lists of previous passwords, sentences and phrases from common books, etc. Humans are predictable and password crackers use that predictability in order to better crack passwords. While your password is probably secure, it can be cracked much much sooner than the majority of password cracking calculation sites tell you.

"Core" is a group of developers. We aren't exactly social people nor are we affiliated with "crypto media". They tend to not write things about what we are doing even though virtually all discussion happens in the open. It is not that "Core" is secretive but rather we produce little content that the media can capitalize on to make stories (i.e. not much interesting stuff comes out that journalists can understand and write stories about; we don't have press releases or anything of the like) as nearly all discussions are technical in nature. Furthermore, "Core" is not an entity; it is not one cohesive thing with an opinion. It is made up of several individual developers who happen to work on the same thing. Very rarely does "Core" produce something unless nearly all of those individuals agree on the same thing and agree that it should be published. However "Core" has made their position very clear on 2x and this blog post: https://bitcoincore.org/en/2017/08/18/btc1-misleading-statements/ details what everyone in "Core" generally agrees with.

The quadratic sighashing issue, although limited by a 1 MB tx limit, can still cause large blocks to take even longer to validate (on the order of several seconds, which to computers is ages). The memory blowup attack which, although is an implementation problem, AFAIK the fix is not present in btc1 (the segwit2x implementation). It is also not known whether the network can handle 8 MB blocks (that is what the effective maximum block size would be) and how that would effect block orphan rates and full node count.

Jeff Garzik.

If 2x does somehow succeed, then most Bitcoin Core developers will quit Bitcoin entirely as 2x's success would mean that miners and companies can have absolute control over what Bitcoin does. Bitcoin would no longer be decentralized and be something that miners can change on a whim.

Segwit2x was produced from essentially a backroom deal of only a bunch of companies. The "New York Agreement" was written beforehand and the signers were invited to just sign it. Some Bitcoin Core developers were invited, but only to sign the agreement. They weren't invited to discuss the proposal at all as it was already written, they were invited to stamp their approval on it. Those Bitcoin Core developers who were invited declined to go and sign the agreement. The agreement was written by companies and completely without any input from the technical community.

The block size has already been increased with segwit. We don't know how that exactly is going to effect things and increasing the block size again so soon will probably be detrimental to Bitcoin (note that there are a lot more things to consider than just the capacity of blocks). Changing things now may cause Bitcoin to be worse off in the future.

Clearly you don't understand the code and how forks have been deployed in Bitcoin. Even for "simple" change, a lot still has to be done for it (deployment code, tests, etc). The 2x hard fork is very rushed and done without much or any review (of both code and technical merits). Furthermore, it is well known to the developers that there are many issues with larger block sizes which 2x does not address. Lastly the Bitcoin Core developers consider hard forks something that should rarely happen. Thus if a hard fork does happen, it should be planned out to happen well into the future and include a lot of things that need fixing via hard fork (e.g the things on the hard fork wishlist).

Please post your debug.log file and screenshots of the issue.

During the entire loading phase, Bitcoin Core is doing a lot of computation. It is not surprising that it goes unresponsive and windows things that it has died. Instead of killing the process, let it keep running even when it is unresponsive. Kill it if it doesn't become responsive after a while (a while being several tens of minutes).

Please don't make posts just shouting "Please fix this" because you have failed to provide any relevant information about your problem for anyone to actually diagnose the issue and find either a bug or find what you are doing wrong. You have failed to follow the instructions in the stickied threads at the top of this section.

Yes

The only step for moving your Bitcoin from your paper wallet to the ledger. For Bitcoin Cash, it should be the same process.

Yes. In fact having multiple addresses is recommended. It is better for your privacy and security to use multiple addresses and to not reuse addresses.

Yes. That is the only step.

Set up your Ledger nano S

Download a wallet software, I recommend you use Electrum. Setup Electrum to use the Ledger Nano S. Use the Sweep function (Wallet > Private Keys > Sweep) and sweep the coins from your private keys into an address on your Ledger Nano S. The transaction creation is handled by Electrum for you.

For Bitcoin Cash, I think you can do the same thing with Electron Cash which is just a Bitcoin Cash version of Electrum. Be careful that you are using the correct network (there are some issues with Electron Cash using the wrong network).

You should move your Bitcoin before moving your Bitcoin Cash.

Yes, but you still need wallet software. You will need a computer and have a wallet software on it. Then you have to import your private keys into that wallet software to make your transactions. Note that you should not be reusing addresses and their respective private keys, i.e. you should generate a new private key and move your coins there after every time you spend any of your coins.

You should be using a wallet software. Your wallet software should know your private key, if it does not, you import it into the wallet so that it does know what it is. Then that piece of software handles your private keys and handles the creation of transactions for you.

You should never be handling private keys by yourself or by hand. That is highly not recommended.

What are you using to run this command?

Are you sure that $key refers to the actual private key string? Does the private key begin with a '5', 'K', or 'L'?

Is Bitcoin Core fully synced?

Code and binaries for the first releases are available here: http://satoshi.nakamotoinstitute.org/code/

Install libgmp. Mingw and cygwin both have their own package manager things and you should be able to install it through those.