"What is the difference between public keys and addresses?"
Addresses are produced by hashing the public key twice.
You start with a private key, multiply it by the generator points, and produce a public key.
You can't go back from the public key to the private key, but you can produce the public key from the private key.
From the public key, you hash it twice and produce the address.
You cannot calculate the public key from the address, but you can calculate the address from the public key.
Private keys produce public keys. Public keys produce addresses. Addresses can't be reversed to public keys.
Public keys can't be reversed to private keys.
"If my wallet automatically generates a new address for each transaction, will [bitcoin]...
previously sent to me on a different address be transferred to the new address just generated?"
"If someone is going to send me funds to a previously-used address, will I still receive them?"
"[Where] will they end up?"
Johannes, this is a great question which is commonly a cause of confusion for many people.
What happens to old addresses if your wallet generates a new one?
The important thing to understand here is, almost all of the wallets which operate like that
have a seed that is used to generate all of the addresses your wallet will use.
As your wallet is generating new addresses, it is not forgetting the old ones;
it is remembering them and still tracking them on the blockchain, to see if they receive money.
If someone sends money to one of your old addresses, then that [address] is where the money will arrive.
[The bitcoin] will be recorded on the blockchain as spendable by the private key of that older address.
As a result, you have to sign [a transaction] with the private key of that address, if you want to spend it.
Your wallet [will] find all of the fractions of bitcoin (i.e. unspent outputs) that [are held by that address],
and use them to produce a transaction.
Let's say you have a tenth of a bitcoin, a hundredth of a bitcoin, a twentieth of a bitcoin,
and you need all three [of those fractional amounts] to make a payment.
Your wallet [will make] a transaction where all of those [outputs], from three different addresses, are inputs.
The output of your transaction will be the [aggregate] payment to whoever you want to pay,
and maybe some change that goes into a fourth, new address.
For every one of those inputs, your wallet [will] find the original private key corresponding to each one...
of those three addresses, sign the inputs with that private key, and producing a signature.
When the rest of the blockchain looks at that transaction, they will look at the first input...
and see it is spending coins that were locked to a specific address.
They will validate the signature, and that signature will correspond to that address.
They will do the same for the second and third inputs. Therefore, all three inputs are validated.
When your wallet is spending money, it is not [necessarily] spending from one address.
It could be spending from a hundred different addresses, with a hundred inputs, each signed with different keys.
the keys that correspond to those addresses.
Your wallet keeps track of all of the addresses and all of the private keys.
"How can we generate a new address to receive change?"
Susanna, your wallet does that for you. Your wallet will generate new addresses as needed.
When it receives change on one of these new addresses, it can use that in the future as an input to a transaction,
so it can spend [the change] later.
"Why not have a single output with the exact amount of BTC, instead of [two outputs], one of which is change?"
Leonard, the reason is that you cannot spend part of an output.
If I have a wallet that has an output of one bitcoin, I cannot spend just one third of that.
I have to "spend" all of it, as an input. If the payment I want to make is only one third [of a bitcoin],
I have to do something with the rest. I can give it to the miners as a fee, but that's not very smart.
Or I return it back to myself, as change. That is why change is required.
It is because inputs spend previously unspent outputs (UTXOs) in total.
Each fraction of a bitcoin that's stored in an output must be spent, all or nothing.
It is treated as a discrete value coin that cannot be split into smaller values [like that for spending].
"Do transactions with multiple inputs and one output pay a fee, [even if the wallet is just] reorganising funds?
Yes, Miguel. If you do a transaction where you take multiple inputs and send them to your own wallet,
in order to aggregate small unspent outputs into one big output (UTXO)...
-- something that is actually a good idea to do from time to time -- you will still have to pay a fee.
It is a transaction. The miner has no idea whether it is inside your own wallet or between two different wallets.
There is no [visible] difference in the transaction. It will look like any other transaction.
It has to be done on the blockchain, because everybody needs to see it,
which means using up some resources on the network and paying a [transaction] fee.
Yes, you do pay a fee, which is why this type of activity -- aggregating or cleaning up [unspent] "dust" [outputs]...
that are too small to be spent [individually] for a reasonable fee -- often happens when fees go down.
As soon as mempools are nearly empty and the fees have dropped significantly,
I'm going to clean up my wallets and use that opportunity to aggregate UTXO if I can,
[after] considering the privacy implications.
I will use a period when fees are low to take advantage of that.
That is the same thing I did when I moved [bitcoin] from non-SegWit to SegWit addresses;
I waited for a time when transaction fees were really low.
"Can you explain the VanityGen command? What is a vanity address?"
A vanity address is an address with [a sequence of] characters in it that spell something interesting.
For example, I have a vanity address which starts with '1andreas.' I have another one that starts with '1love,'
which is a Bob Marley reference.
VanityGen is a command that allows you to generate these [special] addresses.
You [might ask], how can you generate an address like that, with [a special sequence of] characters?
If private keys are generated randomly, how can you end up with an address that has [this special sequence]?
Well, the simple answer is that you keep trying.
Let's take a vanity address with just one character. What does it take to find an address starting with '1a'?
The '1' is already part of the bitcoin address format, so what does it take to find [one starting] with an 'A'?
There are 58 characters in a bitcoin address; on average, if I generate fifty-eight different [addresses],
one of those is likely to start with an 'A.'
Simple, right? If I want to get an 'A,' I have to generate fifty-eight [addresses] on average.
Maybe it's not going to be fifty-eight. [It could take me through] sixty, seventy, or eighty [addresses].
But within a small deviation, I am going to find a private key that, when converted to a public key...
and then an address, starts with an 'A.'
Great. Now, what if I want it to start with 'AN,' from Andreas?
How difficult is that [to find]?
Well, 1 out of 58 [addresses] is going to start with an 'A.'
With 1 / 58 squared, I need to generate 58 x 58 [addresses on average]; if I do that, eventually...
I will generate one private key that, when converted to a public key and then an address, starts with 'AN.'
All I need to do is keep that private key and I have a vanity address that starts with 'AN.'
If I wanted to do this with 'Andreas' (I'm counting with my fingers under the table),
that is seven characters, [which would be] is 58 ^ 7.
Oh boy, that is a lot of addresses I need to generate, which means it is a lot of private keys I need to try.
On average, if I generate 58 ^ 7 distinct [addresses from private keys], one of them will start with '1andreas.'
That requires a very large amount of compute power. VanityGen will do that, [if you] set it up with a GPU.
Generating '1andreas' took about a week and twenty GPUs running in parallel, twenty-four hours per day.
So that is how vanity addresses work.
"SIGHASH_ALL is [for signing] all inputs and outputs. How can all inputs be signed with one signature,
when each of the inputs have a different private key?"
That's a great question. It's also often a point of confusion.
Each of the inputs will be signed by the private key that corresponds to that address,
so it can be verified by [the rest of the network].
However, what is being signed [gets] determined by the SIGHASH flag.
The private key applies a signature to a hash, and the SIGHASH_ALL flag tells the system...
that the hash being calculated is a hash of all inputs and outputs.
That hash is signed by the private key that corresponds to that input, and the signature is stored in that input.
The next input -- maybe the same hash or a different hash -- is signed by the next private key...
and stored as another signature in the next input.
So each input has its own signature; each signature in each input is made by the private key corresponding...
to that input's address.
What they sign, what is put into the hashing algorithm to sign, is what changes by the SIGHASH flag.