Why include any transactions?

[TierNolan]

Could a miner not just create "blank" blocks which just pay themselves the 50BTC fee and don't contain any other transactions?

This would eliminate the need to verify any transactions (which is apparently a big issue for solo miners vs pooled miners).

This wouldn't actually be useless, since they are verifying the previous block and adding to the proof of work.

Also, they could still include some high value transactions, which would actually act to increase the average transaction fee.  If 25% of miners were solo "blank" miners, then free transactions would be less likely to be included.

[1715233145]

1715233145

[1715233145]

1715233145

[1715233145]

1715233145

[1715233145]

1715233145

[1715233145]

1715233145

[1715233145]

1715233145

[ihadanny]

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?

[bcforum]

Yes, a miner could sign blocks containing only the generation transaction. This would be anti-social, and when the problem got large enough the other miners would update their client to ignore these blocks. You would get nothing for your efforts.

Verifying transactions was only an issue with CPU miners since the CPU was shared between assembling the block and searching for the golden nonce. With GPU mining, the CPU assembles the block (and verifies transactions) and the GPU searches for the nonce.

The block is constantly changing (new transactions being added) until a golden nonce is found. The block is then pushed to the network and a new block is started. There isn't any concept of a 'filled' block though, a block contains all the transactions up to the point the nonce is found.

[ihadanny]

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?

[realnowhereman]

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?

I think you're mixing up the nonce with the block hash.  It is the block hash that seals the entire block, or rather the block header.  The block header also contains a hash (or rather the Merkle root hash) of all the transactions in the block.   So... if any transactions in the block change, the hash in the block header changes, if the block header changes the hash changes.

If that was all there was to it, then the block header would have a fixed hash.  The nonce supplies another way of changing the block header.  The nonce serves no other purpose so may be completely arbitrarily chosen.  Miners try many nonces until the block hash meets the proof-of-work condition.

Given that there is no way of knowing if any particular nonce will be "the one", it doesn't matter if any other fields in the block header change at the same time.  In particular the transaction hash.  Therefore it costs the miner close to zero to allow an additional transaction into the block, since it's effect is exactly the same as changing the nonce.

As to the extra work for additional transactions, bear in mind that we're talking about megahashes per second machines.  The additional work to add a transaction is the recalculation of the Merkle tree, is in the order of say thousands of hashes rather than millions of hashes, then the extra cost is tiny.  Further: if we had a GPU doing the nonce search, the little bit of work that the CPU would have to do to add a transaction comes close to being free.

So while there is no reason for miners to add transactions, there's also no reason not to add them either.

If it really became a problem then sociable miners could add a test that said "if there are a thousand pending transactions and new block X contains none of them, then reject the block".  It'd be dangerous to do though because it would make block acceptance conditional on out-of-block state.

[ihadanny]

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?

[realnowhereman]

There is no need to cover any particular subset fully. The chances of any nonce being "the one" are always the same since there is no way to predict hash from nonce.

It might be easiest for miners to search the nonce-space monotonically, but it doesn't reallymayter.

[JoelKatz]

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?

It makes no difference. Every hash you try, assuming you haven't already tried it, has precisely the same chance of yielding a block.

As a practical matter, a miner will generally try all 2^32 possible nonces for a given work unit until they either mine a block or generate a share. When they request a new work unit, that new work unit will include all valid transactions (or as many fit or meet their criteria) known at that time.

A miner will only abort a nonce scan in progress if a new block is found somewhere on the network. In that case, it's worth disrupting the mining in progress to start working on a longer chain. New transactions have to wait for new work units.

[bcforum]

And as a point of fact 400MH/s only takes 10 seconds to search the whole 2^32 nonce space, so when the miner requests new work the timestamp is updated.

At this stage the only use I see for the extra-nonce field is to give the same mekel root to multiple miners while still providing different data to hash.

[ihadanny]

the extra-nonce field is to give the same mekel root to multiple miners while still providing different data to hash

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.

[JoelKatz]

the extra-nonce field is to give the same mekel root to multiple miners while still providing different data to hash

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.

Not if they're members of the same pool.