not needed, because the first transaction in each block is the one generating 50 coins to the miner, and each miner has a different address.

ok, I re-read your answer carefully, and the article I missed about: https://en.bitcoin.it/wiki/Block_hashing_algorithm, and now I'm educated about the block header and no longer confused (10x!).
However, 1 last try: by constantly changing the current block merkle root, you can't possibly work methodically and cover methodically all the nonces between 0-2^32, increment extra-nonce and then continue to the next 0-2^32 nonces. isn't this a bad thing? you end up shooting in the dark instead of sequentially passing over all the options. or is it irrelevant when what you're looking for hides at a 2^256 space?

thanks!
are you sure about the nonce not being the hash for the entire string of the entire block?!
I thought that the whole point was that the golden nonce is a proof-of-work, AND a seal of approval on the entire block - say a hash of its CRC.
I thought that this is the mechanism to prevent retro-active changes in the block chain history.

let me rephrase what you are saying, tell me if I got it right: the golden nonce is the hash of simply the previous block nonce, and that the block transactions are just a payload.
so what is the protection against someone changing history, and re-writing one of those transactions, if the nonce doesn't seal them off?

thanks! could you be more specific? who re-broadcasts the transactions every 30 minutes - my specific client? or everybody on the network aware of my transaction?
does a miner queue up all the unconfirmed transactions known to him when considering who will enter his next block according to their age?
if not, isn't it possible for my transaction to starve forever?
where can i see the code for this process?

Hey,
What happens if I broadcast a new transaction to the network, but it only gets picked by miners that lost, and the winning miner for the next block did not receive my transaction?
How will it enter the block chain?

Just an idea - even if the minimum block size amendment passed, I could still include transactions from myself to myself to make the block kosher, right?

Can anyone answer? Why indeed???
Also, can you expand on how does the miner decide on when to seal the new block and start working on it = not accept any new transactions? does he wait until the entire block gets filled?
Also, what happens to other transactions that did not enter winning block but to a losing block? How do they enter the next winning block?

Thanks!
so for scrutinizing transactions in a new block, we must reverse trace each of them thru the series of output to input, until we reach a transaction that is acknowledged (sits in an acknowledged block), right?
Where can I see the code for this scrutinizing?

Hey,
Admittedly ultra-noob, but believe me that I've done my research before asking.

1. I understand the cool concept of double-spending prevention by all nodes agreeing on the block (and tx order), but only when it involves discrete, indivisible bitcoins. I fail to understand it when we're talking about fractions of bitcoins. Can you give me an illustration of a double spendning attack with fractions of bitcoins? what does it mean? do I have to spend exactly the same amount? or a fraction of a coin I already spent?

2. Where can I look for the code that scrutinize a newly arrived block? Is it part of the client I downloaded? I want to have a deeper look in it, and maybe that can shed a light on my 1st question.

Thanks, good luck with this amazing technical-economic experiment, Ido