Topic: [SOLVED] Is there an easy explanation of how Bitcoin works? A video maybe? (Read 3455 times)

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

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.

You know that the first sentence is:

"The basic explanation is pretty simple."

Right?

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

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.

Thanks for this video!

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?

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.

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

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

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.)

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..."  

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.

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.

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.

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;
}

Thank you: mpfrank and DannyHamilton!

It is very understandable now

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 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.

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.

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