Bitcoin Forum

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 second question: How are coins subdivided? I thought a coin starts with a certain Nonce and is the smallest unit but gavinandresen
http://bitcointalk.org/index.php?topic=198.0
says a coin can be subdivided again.

Is there an example how bitcoin works on a bit-level?

Richard

Welcome to Bitcoin!!  I'll try to answer some of your questions:

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.

An example of how bitcoin works on a bit-level:  Ok, I'll give it a shot.

Here's what the current best-block (according to my bitcoin client) looks like, dumped in a geek-readable format:

BLOCK 68fa61ac1f55a5787dfa0c75bc83e67376ae8356e6887a2ab74cdb0900000000
Next block: 0000000000000000000000000000000000000000000000000000000000000000
Time: Mon Jul  5 15:51:22 2010
Previous block: c18adb50289393b5a995b3506f039ac75e8de79f511515448811510200000000
3 transactions:
1 tx in, 1 out
['TxIn: COIN GENERATED coinbase:0442310d1c029c00']
['TxOut: value: 50.00 pubkey: 17sdrb1X7qpjPMJortqaNwWtBbtouSoJn2 Script: 65:046d...bb9c CHECKSIG']
1 tx in, 1 out
['TxIn: prev(580a...e82e:0) pubkey: (None) sig: 71:3044...db01']
['TxOut: value: 50.00 pubkey: 1FeFgJRvCYUTCBj1u696eL23xpAdNB4B8p Script: DUP HASH160 20:a09d...6d81 EQUALVERIFY CHECKSIG']
3 tx in, 1 out
['TxIn: prev(c0a0...6bc3:0) pubkey: (None) sig: 73:3046...0f01', 'TxIn: prev(f909...2493:0) pubkey: (None) sig: 73:3046...1601', 'TxIn: prev(bc0a...fe64:0) pubkey: (None) sig: 72:3045...6201']
['TxOut: value: 150.00 pubkey: 1BHxjkqPmtNdmJxLZgneijvGszRxM9hPkz Script: 65:04ee...1d02 CHECKSIG']

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?

Gavin that was very helpful, thanks!

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?

The "scripting language" ("expression evaluator" would be more accurate) is a little stack-based intepreter that looks at lot like Forth.

So, for example, here's an example of a GENERATED coin getting spent:

TxIn:          73:3046...0f01
Prev.TxOut: 65:046d...bb9c CHECKSIG

That's intepreted as:
  PUSH a 73 byte value onto the stack
  PUSH a 65 byte value onto the stack
  call CHECKSIG.  CHECKSIG pops two values off the stack (public key and digital signature), then does the digital signature thing (http://en.wikipedia.org/wiki/Digital_signature) using the OpenSSL ECDSA_Verify() (http://www.openssl.org/docs/crypto/ecdsa.html) function.

Heh, now I'm curious. What happens when you specify a smaller/larger value before the colon? What happens if you just don't call CHECKSIG in the transaction?  :P

This is a great question, I also want to understand the logic for this. Hopefully someone can answer.