Bitcoin Forum

By "works" I mean - really works - with all the sha256, difficulty and mining computers operations. :)

As mentioned here (by Korbman):
https://bitcointalk.org/index.php?topic=143992.0
We need something similar to what @hazek did (in the topic I just mentioned) - but from the technical point of view.
And I believe we need it to be easy to understand for everyone.


I would love to show begginers this video - if it exists...
Or maybe somebody has it all explained in PDF or in a Forum Post?

What I think would be perfect is - in way which CGP Grey is doing his youtube videos:
http://www.youtube.com/watch?v=LrObZ_HZZUc The (Secret) City of London, Part 1: History
[He even included Bitcoin logos in this vid!]


Thanks and may the force of Bitcoin be with you ;)

EDIT:
I think problem is solved. Now we would probably need a video with that. :D
Basics by @mpfrank
https://bitcointalk.org/index.php?topic=144642.msg1534348#msg1534348

The "difficult mathematical problem" explanation by @DannyHamilton
https://bitcointalk.org/index.php?topic=144642.msg1534672#msg1534672

The basic explanation is pretty simple.  The technology is based on digital signatures (http://en.wikipedia.org/wiki/Digital_signature (http://en.wikipedia.org/wiki/Digital_signature)).  A bitcoin "account" is essentially just a digital signature keypair, meaning that only the account owner has the private key that's needed to digitally sign messages (similar to bank checks) authorizing the transfer of bitcoins out of their account.  Anyone, however, can verify the authenticity of those messages, or send coins to an account by referring to its address (which is a unique fingerprint of that account's public key).  There's a public database of all the valid transactions that have ever occurred called the "blockchain", which is copied on computers (nodes of the bitcoin network) all over the world; any computer which has an up-to-date copy of the blockchain can use it to calculate the current balance of any account.  A new transaction that you initiate is broadcast to a peer-to-peer network of active bitcoin nodes by your bitcoin client.  The transaction becomes permanent when it is incorporated into a new "block" of transactions which is added to the blockchain by a miner (a computer running mining software).  To create a new block requires solving a difficult mathematical problem, so that new blocks do not get created too often (about one every 10 minutes on average), which ensures that there is only one longest version of the blockchain in existence at any given time, which is then accepted by all nodes on the network as the new state of the bitcoin database.  As a reward for solving the hard problem of creating a new block, the miner that solved it is automatically assigned some new bitcoins (25 BTC) as well as the transaction fees from all the transactions in the block.  Any questions?

here:

http://www.youtube.com/watch?v=tpG8Z-k2koE

Some of the common ones I've seen (and can think of off the top of my head), that your explanation doesn't cover are:

• If I know the private key, how do I calculate the Public Key?
• If I know the private key, how do I calculate the Bitcoin Address?
• If the Bitcoin address is a "unique fingerprint of the account's public key", how is it used to verify the signature?
• What "difficult mathematical problem" is being computed?
• How do all the nodes know that the miner solved the "difficult mathematical problem", without having to spend the time to solve it themselves?
• Why does the blockchain show multiple inputs from the same address?
• Why does my transaction have outputs to an address I didn't specify?
• Why does the total of unspent outputs in the blockchain associated with the addresses in my "Receive Coins" not match my Wallet Balance?

I don't see how your video answers the question presented by the OP?

OK, so you want more technical details.  That doesn't sound like the "easy explanation" the OP was asking for.  But I can answer some of them... 

you show amazing cognizance

The answer to that one is inevitably going to be fairly technical.  It's not a trivial calculation, and you have to get all details of that algorithm exactly right.  Here's the Wikipedia page about the digital-signature system used:

http://en.wikipedia.org/wiki/Elliptic_Curve_DSA (http://en.wikipedia.org/wiki/Elliptic_Curve_DSA)

???

So he wants a detailed explanation of a highly technical subject, but in baby language?

and therein lies the crux of the problem

You calculate the public key and then take the SHA-256 hash of it.

Now you are catching on to why he can't find what he is looking for.  Note, I already know the answers to the questions I posed.  I wasn't looking for answers. I was just pointing out common questions that I see asked by people who are trying to understand the technical details of Bitcoin.

This is incorrect.

Most digital signature systems include the public key used to sign the message as part of the signed message.  You simply hash this, and compare the hash to the Bitcoin address.  If they are equal, then that verifies that the signature on that message corresponds to that account.

OK, then please correct me.  Apparently I'm not the best one to answer his question...

https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

• Calculate the public key using the secp256k1 curve
• Perform SHA-256 hashing on the public key
• Perform RIPEMD-160 hashing on the result of SHA-256
• Add version byte in front of RIPEMD-160 hash
• Perform SHA-256 hash on the extended RIPEMD-160 result
• Perform SHA-256 hash on the result of the previous SHA-256 hash
• Take the first 4 bytes of the second SHA-256 hash. This is the address checksum
• Add the 4 checksum bytes from point 7 at the end of extended RIPEMD-160 hash from point 4. This is the 25-byte binary Bitcoin Address
• Convert the result from a byte string into a base58 string using Base58Check encoding.

Thank you for answering me :)

One of the most important questions in my opinion is:
I mean not in the "baby language" - but let's say - in understandable way for a so called "non-technical" person. :)

To start with you need to understand (or at least accept) that there are certain mathematical calculations that are very easy&fast to do in one direction and very difficult&slow to do in the opposite direction.

One example of this would be multiplying large prime numbers.

If I give you 2 prime numbers:
9931 and 9803

You can quickly and easily multiply them together and determine that the result is:
97,353,593

On the other hand if I give you a number:
93,603,659

And ask you which two prime numbers it is the product of, you would find it difficult and time consuming to determine that the answer is:
9923 & 9433

Now that we have established that there are mathematical problems that can be easy&fast in one direction and difficult&slow in the other. . .

The particular mathematical problem being solved during mining is called a SHA-256 hash.  This algorithm takes a set of data and calculates a 256 bit number from that data. It is very fast and easy for a computer to calculate a SHA-256 hash from a set of data.  It is extremely slow and difficult to go the other way, finding a set of data that will exactly match a given hash. It is so slow and difficult that it can be considered impossible.

Without performing the SHA-256 algorithm, it isn't possible to know ahead of time (with current mathematics) what the resulting 256 bit number will be, so the result is essentially random.  Changing even a single bit in the original data changes the resulting 256 bit number in an unpredictable way, the entire SHA-256 algorithm must be re-calculated to determine the new result.  If you are given a SHA-256 hash, there is no known fast or easy way to determine what original set of data will result in that particular hash.

The miner packages up all the transactions that they want to include in a block. Then they perform a SHA-256 hashing process on all the transactions and include the resulting number (often referred to as a Merkle Root) in the block header.  Changing any information in any transaction will change this Merkle Root, and therefore change the header of the block.

The miner then calculates a SHA-256 hash of the block header. To force miners to prove that they've done a certain amount of mathematical work, the bitcoin protocol sets a target value for this SHA-256 hash.   If the hash that the miner calculated is less than the target value, then the block is "solved" and ready to be published to the network.  If the hash is greater than the target value, the miner changes a special field in the header called a nonce.  This field exists solely for the purpose of modifying the resulting hash value.  The miner then recalculates the SHA-256 hash of the block header (with this new nonce value).  The miner repeats this process over and over until the resulting hash is less than the target value.  There is no known way to predict what nonce will be needed ahead of time.  The miner has to just keep trying until they get a low enough hash value.

As the numbers (and speeds) of miners working on this hashing problem increases, they begin discovering a hash that is less than the target value faster.  The protocol is then designed to require an even lower target value to make it more difficult to find an appropriate hash.  If miners start turning off their mining systems, discovering a hash that is less than the target value will start taking longer. The protocol is then designed to require a higher target value to make it easier to find an appropriate hash.  The protocol adjusts this target value every 2016 blocks to keep the average amount of time to solve a block at 10 minutes.  This forces the entire network to put "on average" 10 minutes of hashing calculations towards each block.

If someone wanted to change any information in an already solved block, it would change the value of the Merkle Root in the header.  This would change the hash of the header.  The person attempting to modify the block would have to find a hash of their new header that was lower than the necessary target in order to get any of the peers on the network to accept it as valid.

Each new block includes the exact hash of the previous block in its header.  This means that the person attempting to modify data in a solved block has to not only find a low enough hash for the block that they are attempting to modify, but that they have to find low enough hashes for every block that has been created since then.  While the person attempting to change an old block is trying to solve all these hashes of low enough value, the rest of the network is working on a new block.  This means that the person attempting to modify the blockchain history has to catch up with the rest of the honest network that is trudging on ahead of them.  The only way to realistically do this is to have more hashing power than the entire combined honest network.

Note that once a header (with its nonce and resulting hash) is broadcast to the network, it is very fast for each peer to verify that the previous work by the miner was valid.  They only need to calculate a single hash of the broadcast header to see if the resulting hash is the broadcast hash, and then compare that hash to the target value to confirm that it is low enough.

Was that too technical? Or did I manage to describe it in "an understandable way for a so called non-technical person"

Thank you: mpfrank and DannyHamilton! :)

It is very understandable now :)

1) some new bitcoins (25 BTC) >> some new bitcoins (the reward is halved every 4 years and is now 25 BTC)

2) The coins only exist as balances associated with a bitcoin address. What you keep is actually the private key(s) of that addresse(s).

3) The private key and bitcoin address are mathematically bounded like a key and its locker. And importantly you can calculate the bitcoin address of a private key in a few seconds but it would take millions - if not billions - of years to find out the reverse, the private key of a bitcoin address, as you would have to use trial and error and you would need staggering vast amounts of computation to accomplish it.  

4)The limit of 21 million bitcoins results from the accumulation of 50 bitcoins each ten minutes during the first four years(50x6x24x365x4=10 512 000), plus, half, 25 bitcoins each ten minutes during the following four years (5256 000+10 512 000= 15 768 000), plus, half, 12.5 bitcoins each ten minutes during the following four years (2 628 000+5 256 000+10 512 000=18 396 000)... and so on and so forth, till the reward of the fours years before is so that it doesn't add nothing to the total of "almost" 21 million, more precisely: 20999999.97690000 BTC.

Here is the code that imposes this limitation,

//on main.cpp

int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}

Holy crap.. (brain-gasm) ...I just got schooled!

I actually did understand that...and now I do have a better understanding of Bitcoin.

I also see, now, that I have yet much to learn.
..wax on ..wax off?

Thank you DannyHamilton.

No problem.  I you have other specific questions about things you are trying to understand, you'll find that there are many knowledgeable people here at bitcointalk.org that will do their best to explain in terms you can understand.

If you are trying to be that specific about it (and even include the source code that demonstrates it), it would be a good idea to use the correct numbers.  As the code that you included demonstrates, the block subsidy isn't 50 bitcoin each ten minutes during the first four years 50x6x24x365x4=10 512 000.

It is 50 bitcoin each block for the first 210 000 blocks (50x210 000=10 500 000), plus 25 bitcoin each block for the next 210 000 blocks (10 500 000+5 250 000=15 750 000), and so on until the previous for years adds 0.00000001 bitcoin per block for 210 000 blocks (0.0021 + 20999999.9748 = 20999999.9769).

With the current protocol, after the 6 930 000th block (approximately 140 years after bitcoin started) there will no longer be a block subsidy.  At that time all miner rewards will come from transaction fees.

Note that the 20999999.9769 is a theoretical limit.  As it turns out, due to some bugs in some mining software in the first few years of bitcoin, some bitcoins were never issued. The miner put less than the 50 + fees into the coinbase transaction of the block. This means that the actual total number of bitcoins ever created will be less than 20999999.9769.

Thank you; that is very interesting and detailed, although arguably one could sum it up as "you take the public key and hash it using a method based mainly on SHA256..."  :)

You could but the RIPEMD-160 hash is probably more the important hash since it reduces the number of unique addresses from 2²⁵⁶ to 2¹⁶⁰.

Also, the fact that a 4 byte checksum is built into the address is an important fact that many people don't seem to realize.  It means that it is extremely difficult for anyone to make a typo when entering a bitcoin address and still have it accepted as valid.  No need to worry about accidentally mistyping an address and sending the bitcoins to the wrong place. (Of course you could still enter the wrong address if you are given a valid address from someone's address book that isn't the one they intended to give you.)

To top it all off, GizMag posted an article yesterday that breaks Bitcoin down quite a bit further..and in "baby language" :P

If anybody's interested: http://www.gizmag.com/bitcoin-creation-value-overview/26325/

That article was filled with so many errors I don't even know where to start picking it apart.  I certainly won't be suggesting it to anyone who wants to learn more about bitcoin.

I've been looking for a mid-level article/set of articles/videos like the OP is also seeking.  This thread helped me understand parts of it all better.
Thanks DannyHamilton and remotemass - those explanations were very helpful.

I would like to learn more about why counterfeiting isn't possible.  Or more to the point, why couldn't a 51% attacker use his majority network to confirm the creation of larger amounts of bitcoin?

I understand that bitcoins only come into existence as mining rewards and that the amount of reward is hardcoded into the software.  Is this alone enough to prevent the faster creation of bitcoin? If a 51% attacker could modify the client software his nodes run and why couldn't he control difficulty or simply change the block reward protocol?  Would his nodes be completely rejected by the other nework nodes at that point, effectively pushing him off the bitcoin network?

Thanks for this video!

Every full peer validates every single block.  It wouldn't matter if someone had 51% of the mining power or 99% of the mining power on the network.  If they are transmitting a block that has a larger block reward than the protocol allows, then every peer that they connect to would reject their block as invalid and refuse to relay it.  Meanwhile any valid block created by someone else would be accepted, relayed, and added to the public blockchain.

To get their invalid block added to the blockchain, the attacker would have to convince a significant portion of the peers on the network to all run the modified software.


Yes.  Or more specifically, his blocks would be completely rejected since the acceptable difficulty and block reward are calculated by every peer on the network and enforced on every block they receive and relay.  Theoretically his node itself wouldn't be rejected, so he could continue to participate in relaying other people's blocks and transactions, but none of his modified blocks would be accepted as valid blocks.

You know you'd get blank stares from 90% of the population with just this first sentence.

You know that the first sentence is:

"The basic explanation is pretty simple."

Right?

I see nothing wrong with the statements thus far. That first sentence is more than enough to grant blank stares from the general populace here in the US.

:P

haha doh, yea ok - I guess I didn't notice them full stops :]