How transactions get added to a ledger?

Question

I just can't seem to understand how bitcoin works. Here is what I understand so far.

• Alice sends 1 Bitcoin to bob's public address
• A new transaction gets created for miners to approve. A transaction will have the following properties
  • Sender's public address
  • Receivers public address
  • Amount
  • Timestamp
• The transaction gets broadcasted to multiple nodes on the bitcoin network
• Miners/Nodes listening for incoming transactions receive Alice's transaction and want to make sure that the transaction is legit and there is not double spending.
• Miners/Nodes start looking up the ledger (block chain) which holds all the transactions that every happened from the beginning of time to find if all the previous transactions by Alice have been completed and if they are, only then execute the new transaction.
• When a miner validates the new transaction it transfers the 1BTC over to Bob's account minus transaction fee.
• And Bob is 1BTC richer and he lives happily ever after.

Please correct me if I am wrong and I honestly don't understand whats the story with the 'n' number of zeros being added to the a string to prove a transaction is valid.

Please help. I'm trying to understand this so that I can contribute to Bitcoin's source code.

Answer 1

The process actually goes like this:

• Alice sends 1BTC to Bob's address. A new transaction gets created with:
  • As many inputs as necessary (unspent outputs from Alice's previously received transactions) formed by:
    • Previous transaction ID (txid, the transaction which sent Alice the coins she's going to spend) and output index (vout, which output of the transaction is being spent)
    • Alice's public key (whose hash(publicKey) must match the hash included in the previous transaction)
    • A signature over the whole transaction, signed with Alice's private key and verifiable with the included public key
  • As many outputs as necessary/wanted pointing to Bob's addresses (remember each address is just a hash, not public key!)
    • This is the hash Bob will have to match with his public key to spend the coins!
• The raw transaction is broadcast
• Miners receive this transaction, verify and validate it (check signatures, check that inputs are valid and unspent, check that hash included in unspent outputs equals hash of the provided public key)

Up til here you got it more or less. Now here's what you didn't get:

• Miners add this transaction to their current block, which holds even more unconfirmed transactions
• The miner keeps hashing the block with an incrementing nonce
  • In each nonce incrementation, the hash is different
  • If hash(block+nonce) < target (target varies with difficulty), the block has been mined and is considered valid
• When block is mined, it's broadcast to the rest of the network, which in turn update their blockchain and start mining from this block (if it's the head of the longest known chain)

Getting a block and nonce whose H(block+nonce) < target is a probabilistic process and you can only get a mined block via trial and error. If you mine a block, you've spent lots of trials and errors (proof of work) but verifying that the block is correct is very cheap.

These mined blocks form a chain. Miners compete to form the longest chain. This is what makes Bitcoin secure: to change the chain you have to mine as many blocks as you'd like to change plus one, before anyone else finds a single block.

Answer 2

The transaction contains a signature created by Alice to prove she owns the coins and Bob's address. The bitcoin node verifies the transaction to make sure the signature is valid and the output has not been spent yet. If the transaction passes verification, it is added to the pool of available transactions. Miners get transactions from the pool to create a block to be mined. If Alice's transaction is included in a block and the block is accepted by the network, then the transaction becomes a permanent part of the block chain.

The number of leading zero bits in the block hash represents the network difficulty. A SHA-256 hash is 32 bytes and cannot be predicted based upon the input data. So you have to keep changing the input data (the nonce) and repeating the hash until you get a result that meets the difficulty requirement. The easiest result is a hash that doesn't require any leading zeros, which means you have to hash the data just once (any result is valid). If you require one zero bit, you have reduced the number of valid hashes by a factor of 2. So it will take longer to find a valid hash since any result with a non-zero first bit has to be discarded (on average, 50% would be discarded). As you keep increasing the number of leading zero bits, you keep reducing the pool of valid results, making it harder and harder to find a result (more and more results are discarded and have to be re-hashed).

The idea is to keep finding a new block once every 10 minutes. As the network hash power increases, the rate of new blocks also increases. So additional zero bits are added to the required result to make it harder to find a block and thus bring the rate back to once every 10 minutes. If the network hash power should decrease, the reverse would happen and the number of zero bits would be reduced to allow blocks to be found more quickly. This adjustment is performed every 2016 blocks.