I am trying to understand the underlying concept of Bitcoins and could only find the PDF here:http://sourceforge.net/projects/bitcoin/files/Design%20Paper/bitcoin.pdf/bitcoin.pdf/download(and Wikipedia)They detail the system in very general terms. What I don't understand in the money creation: A coin is a chain of transactions. So a „freshly minted“ coin is a coin that only contains a Nonce that Hashes to the goal, which is a Number smaller than a given $target. Where is the incentive for the user to Hash the Block? As I understand it, the incentive basically lies in: „If I calculate the Hash and it Hashes to a Number smaller $target, then I found a new coin“. But if the user wants to create coins, wouldn't it be more efficient to skip the Hashing and concentrate on Number crunching?„By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block.“But by broadcasting this proof of work, anybody could claim the coin because the old Hash + Nonce = new Hash have to be available for the check of the proof of work?

A bitcoin isn't exactly a nonce or hashed block (including the nonce) found by instense number crunching. Instead, think of a bitcoin as just an accounting record, like a number you might type into an excel spreadsheet to represent the amount of money that some account has.

Now, when when people transact bitcoins, they broadcast their transaction to every node on the network. Over time, a few of these transactions will build up. Here's where the computation comes in. All of the node computers will begin processing this "block" of transactions which have occurred since the last proof of work began, looking for a nonce that happens to generate the target when hashed. When a node successfully finds this nonce, there is essentially just a new accounting record that says that node computer gets a 50 bitcoin reward, which can be spent in future transactions.

One of the really weird things is that the number of transactions that need to be "blocked" doesn't actually affect how hard it is to find a nonce for that block. So, there's really no benefit to not including the transactions when searching for a nonce, like you might have thought when you said "...concentrate on the number crunching".

Now, the rewarded bitcoins must go to the node who found the nonce, because along with the transactions and the nonce, the block also includes the node operator's address. So, even though the proof-of-work can be publicly verified, nobody can "claim it as their own" because that nonce is only a solution for the block which includes the successful node's address.

I hope that helps clarify some things. Please continue to ask questions if it's not clear, this thread can be a great resource for other newcomers. Somebody else will have to clarify how bitcoins are divided, I'm not entirely clear on that myself.

So: that big long string of hex at the top is the block header's hash value. Note that it ends with 8 zeroes; that's the proof-of-work (my utility for dumping blocks doesn't bother dumping the Nonce values).

What's hashed in the block header? The Nonce. The block's generation time. The previous block's hash. And a hash of all the transactions in the block. (and probably some stuff I'm forgetting).

This block has three transactions in it. The first is the 50.00 (which is really 5,000,000,000 of the smallest possible units) reward for finding/creating the block. It can only be spent by whoever has the private key that matches the public key in the TxOut (17sdrb1X7qpjPMJortqaNwWtBbtouSoJn2 -- you can think of public keys and bitcoin addresses as equivalent), which will be whoever generated the block.

The second is a payment of 50.0 from.... somebody... to... somebody. How does Bitcoin know that transaction is valid? Well, it: + Looks up the previous transaction. That's the TxIn: prev(580a...e82e:0) stuff-- fetch TxOut zero (which will be a coin generated txn) from previous transaction 580a.... + EVALUATE(TxIn.pubkey + previous transaction TxOut.pubkey) and make sure it evaluates to true. This is where the cryptography happens; the receiver uses the private key known only to them and provides a correct digital signature.

The third is a payment of 150.0 (three 50.0-value in, one 150.0-value out).

Clear as mud?

How often do you get the chance to work on a potentially world-changing project?

Could someone to the best of their ability please explain the transaction scripting language? That's the only thing I still don't fully understand now. I know it's for extensibility and that it will be static for now, but could someone explain how it works?