But just to help me out to get a good start, if I get a BTC from a Bitcoin ATM, I will be given a hash code generated (one of the 7.9 X 1028 from using the SHA256), right?
I haven't used a Bitcoin ATM, so I'm not certain how they operate. I would assume that you would provide the ATM with your bitcoin address, and the ATM would just send a transaction. There shouldn't be any need for you to handle private keys.
That hashcode is the private key of a new address associated to the BTC I purchased?
It might be possible that an ATM would provide you with a private key and that you would then need to import that private key into a wallet, but that would not be a good way for an ATM to operate. I think I would avoid using an ATM that did that.
And if I spent all the BTC in that address, the address will be deleted?
Private keys and addresses are just numbers. You can't delete them any more than you can delete the number 5 from existence.
You can remove them from your wallet, and an ATM could remove a private key or address from its own wallet, but why? There is no benefit to removing a private key or an address from your wallet.
In the receipient's wallet, that BTC is added to the public address of the wallet?
From the user's viewpoint, that's a reasonable way to think of it. At the technical level its a bit more complicated than that, but you seem to already have enough confusion about how bitcoin operates. I don't see a need yet to confuse you more with the details of how transactions actually work.
How does the blockchain know that the public address now own the BTC?
The blockchain has a transaction that indicates that the BTC have been sent to that address.
I watched a video about how transactions are connected through hashing process and how new keys are created, but have never understand how it actually work. Is there any good reference for this kind of info? (I am asking this more technical question because you seems technical enough to answer it.)
Ok, sounds like we're going to get into the technical details after all...
Each transaction consists of 2 lists.
One list is called "outputs". The list of outputs assigns the value that has been provided to the transaction. Each output in the list is encumbered (in the form of a script) with a requirement that must be met in order to be allowed to use that value to fund some other transaction.
The other list is called "inputs". The list of inputs is a list of previously unspent outputs created by earlier transactions. Each input in the list has a script that meets the requirements that previous output was encumbered with. It then supplies the entire value of that previous output to the transaction so that the transaction can assign that value to new outputs. Once an output has been referenced by an input, and that transaction is included in a block in the blockchain, the output is considered to be "spent" and can never be referenced by any other input ever again.
Lets take a look at an actual transaction:
https://blockchain.info/tx/93d4a526737d59ba29aeb450cd66071f07ecf5575dbd7dcdae33f7ddbb2a7d09Here is the transaction in its raw hexadecimal format (I've added line breaks every 32 bytes so that it will hopefully fit better on your computer screen instead of extending off the screen to the right):
0100000002cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59c
b0840e755d040000006b483045022100f57111d73ea20dc7d989bef2d8c4a2fc
2bcf1348b67b633090cc353757017fb502206515c5c3c059bd3dd7d144b8fb48
1dfc25d715b4bab439a7a67b018ab1d1bedf012102759f9014f1179299dc78c1
114f9872492561aa2a6490f330d7c64ab67646cbd6fffffffffa2e7b484496f7
b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896190000006b4830
45022100cce9f1977cbec30a43e7421c88ac6c29b53c0ecb44ac939234f367e9
0885c368022070163871b4913d90cce2789dc68f6d7367ff41f970d2fc945686
aadfe69f434c012102759f9014f1179299dc78c1114f9872492561aa2a6490f3
30d7c64ab67646cbd6ffffffff02cd6f0700000000001976a914f918ffff3451
92ae9f3878d49344a7ad99a543f788ac00e1f505000000001976a9149529f2cc
d600ccb40fee8d56715839b6ff5d0f0888ac00000000
That's what is actually sent over the network and stored in the blockchain.
I'll use some line breaks to break that up into its component pieces for you:
01000000
02
cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d040000006b483045022100f57111d73ea20dc7d989bef2d8c4a2fc2bcf1348b67b633090cc353757017fb502206515c5c3c059bd3dd7d144b8fb481dfc25d715b4bab439a7a67b018ab1d1bedf012102759f9014f1179299dc78c1114f9872492561aa2a6490f330d7c64ab67646cbd6fffffffffa2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896190000006b483045022100cce9f1977cbec30a43e7421c88ac6c29b53c0ecb44ac939234f367e90885c368022070163871b4913d90cce2789dc68f6d7367ff41f970d2fc945686aadfe69f434c012102759f9014f1179299dc78c1114f9872492561aa2a6490f330d7c64ab67646cbd6ffffffff
02
cd6f0700000000001976a914f918ffff345192ae9f3878d49344a7ad99a543f788ac00e1f505000000001976a9149529f2ccd600ccb40fee8d56715839b6ff5d0f0888ac
00000000
Ok lets label those so you know what you're looking at:
First we have a transaction version number. When converted from hexadecimal to base
10 (using little-endian byte order), we see that these 4 bytes of data represent a value of 1. This lets all the nodes know that this transaction is using the rules associated with transaction version 1:
Next we have a number that says how many items are in the input list. Converting from hexadecimal we see that the this byte represents a value of 2. This lets all nodes know that they should look for 2 inputs immediately following this:
After that we have the list of 2 inputs. We'll break this apart later, but for the sake of keeping everything in the same order as the transaction above so you can follow along here's the data representing those inputs:
cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d040000006b483045022100f57111d73ea20dc7d989bef2d8c4a2fc2bcf1348b67b633090cc353757017fb502206515c5c3c059bd3dd7d144b8fb481dfc25d715b4bab439a7a67b018ab1d1bedf012102759f9014f1179299dc78c1114f9872492561aa2a6490f330d7c64ab67646cbd6fffffffffa2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896190000006b483045022100cce9f1977cbec30a43e7421c88ac6c29b53c0ecb44ac939234f367e90885c368022070163871b4913d90cce2789dc68f6d7367ff41f970d2fc945686aadfe69f434c012102759f9014f1179299dc78c1114f9872492561aa2a6490f330d7c64ab67646cbd6ffffffff
Following the list of inputs we next have a number that says how many items are in the output list. Converting from hexadecimal we see that the this byte represents a value of 2. This lets all nodes know that they should look for 2 outputs immediately following this:
After that we have the list of 2 outputs. We'll break this apart later, but for the sake of keeping everything in the same order as the transaction above so you can follow along here's the data representing those outputs:
cd6f0700000000001976a914f918ffff345192ae9f3878d49344a7ad99a543f788ac00e1f505000000001976a9149529f2ccd600ccb40fee8d56715839b6ff5d0f0888ac
Finally, we have 4 bytes that represent a lock time. If these 4 bytes are not zeros, then they are an indication to all nodes that they should not accept the transaction as being valid until after the blockheight or timestamp indicated by their value. In most cases for the typical transactions that the typical bitcoin user would send, these 4 bytes will always be zeros.
That's it. That's the whole transaction. There is nothing else in there, nothing else transmitted as part of the transaction, and nothing else stored in the blockchain as part of the transaction.
To get a better understanding of how the transaction works, lets take a closer look at those two lists (the inputs and the outputs)...
I'll break the list of inputs into it's two inputs.
Here's the first input, I've broken its components apart with line breaks (you can compare to the list of inputs above):
cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d
04000000
6b483045022100f57111d73ea20dc7d989bef2d8c4a2fc2bcf1348b67b633090cc353757017fb502206515c5c3c059bd3dd7d144b8fb481dfc25d715b4bab439a7a67b018ab1d1bedf012102759f9014f1179299dc78c1114f9872492561aa2a6490f330d7c64ab67646cbd6fffffffff
That first piece, "cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d", is the transaction ID of an earlier transaction. It tells the system, "I'm spending the value that was previously assigned in one of the outputs of transaction ID cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d."
That next piece, "04000000", is commonly called the index or the offset. It tells the system, "I'm spending output number 4 in the list of outputs from that transaction that I just listed."
(note that outputs are numbered starting at 0, so the first output is output number 0, the second output is output number 1, the third output is output number 2, and so on. Therefore, this input spends the fifth output (output number 4) from transaction cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d.
Every node on the network knows now to go look at the fifth output of transaction cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d when validating this transaction.
Here's a link to that transaction with the fifth output highlighted in yellow:
https://blockchain.info/tx-index/273813243/4You can see there that that output provides a total of 0.00674373 BTC (674373 satoshis) in value that this transaction now has available to it to be reassigned.
We'll see later when we look at outputs that they also include a script that must be satisfied with some data in order to be allowed to use them in a list of inputs. This input satisfies that requirement with the ECDSA digital signature and the ECDSA public key which is that final string of data above.
Here's the second input, I've broken its components apart with line breaks (you can compare to the list of inputs above):
a2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896
19000000
6b483045022100cce9f1977cbec30a43e7421c88ac6c29b53c0ecb44ac939234f367e90885c368022070163871b4913d90cce2789dc68f6d7367ff41f970d2fc945686aadfe69f434c012102759f9014f1179299dc78c1114f9872492561aa2a6490f330d7c64ab67646cbd6ffffffff
That first piece, "a2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896", is the transaction ID of an earlier transaction. It tells the system, "I'm spending the value that was previously assigned in one of the outputs of transaction ID a2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896."
That next piece, "19000000", is commonly called the index or the offset. When converted from hexadecimal to base
10 (using little-endian byte order) we see that it represents a value of 25. It tells the system, "I'm spending output number 25 (the twenty-sixth output) in the list of outputs from that transaction that I just listed."
Therefore, this input spends the twenty-sixth output (output number 25) from transaction a2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896.
Every node on the network knows now to go look at the twenty-sixth output of transaction a2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896 when validating this transaction.
Here's a link to that transaction with the fifth output highlighted in yellow:
https://blockchain.info/tx-index/259879311/25You can see there that that output provides a total of 1.0 BTC (100000000 satoshis) in value that this transaction now has available to it to be reassigned.
This input satisfies the output's script requirement with the ECDSA digital signature and the ECDSA public key which is that final string of data above.
We can see that a total of:
0.00674373 + 1.0 = 1.00674373 BTC (100674373 satoshis) of value has been provided by the list of inputs. Next, the list of outputs will assign that value.
I'll break the list of outputs into it's two outputs.
Here's the first output, I've broken its components apart with line breaks (you can compare to the list of outputs above):
cd6f070000000000
1976a914f918ffff345192ae9f3878d49344a7ad99a543f788ac
That first part, "cd6f070000000000" says how many satoshis are being assigned to the output. If we convert from hexadecimal to base
10 (using little-endian byte order) we see those 8 bytes represent a value of 487373 satoshis (0.00487373 BTC).
The second part is the script that encumbers that value with a requirement that must be met by any input in the future that tries to spend this output. In this case, that script effectively says, "Supply an ECDSA public key that hashes to the value of "f918ffff345192ae9f3878d49344a7ad99a543f7", also supply an ECDSA digital signature that can be validated with the public key that you supply". Therefore, when this output is later spent by being referred to by an input in a future transaction, that input will need to supply both the public key and the signature.
Here's the second output, I've broken its components apart with line breaks (you can compare to the list of outputs above):
00e1f50500000000
1976a9149529f2ccd600ccb40fee8d56715839b6ff5d0f0888ac
That first part, "00e1f50500000000" says how many satoshis are being assigned to the output. If we convert from hexadecimal to base
10 (using little-endian byte order) we see those 8 bytes represent a value of 100000000 satoshis (1.0 BTC).
The second part is the script that encumbers that value with a requirement that must be met by any input in the future that tries to spend this output. In this case, that script effectively says, "Supply an ECDSA public key that hashes to the value of "9529f2ccd600ccb40fee8d56715839b6ff5d0f08", also supply an ECDSA digital signature that can be validated with the public key that you supply". Therefore, when this output is later spent by being referred to by an input in a future transaction, that input will need to supply both the public key and the signature.
So, if you followed along, you should see that the list of two inputs provided a total of 1.00674373 BTC (100674373 satoshis) of value to the transaction, and that the transaction created two new outputs assigned with a total of:
487373 + 100000000 = 100487373 satoshis (1.00487373 BTC).
The remaining unassigned value is:
100674373 provided by inputs - 100487373 used by outputs = 187000 satoshis (0.00187 BTC)
When the transaction gets included into a block in the blockchain, the miner that creates that block is allowed to assign that extra 0.00187 BTC to themselves along with the current block subsidy as their block reward. That is how transaction fees are handled by the bitcoin system.
